13 Replies Latest reply on May 12, 2014 11:04 AM by Justin Bertram

    Configure time before exception is thrown on full queue

    Yair Ogen Expert

      Is there an option to configure the time the client waits before an exception is thrown when the queue is full?

        • 2. Re: Configure time before exception is thrown on full queue
          Yair Ogen Expert

          Is there a reason why not? Can I open a ticket to request this? Where?

          • 3. Re: Configure time before exception is thrown on full queue
            Andy Taylor Master

            Is there a reason why not?

            because we have never had a use case to do so, why do you want to delay the exception?

            Can I open a ticket to request this?

            you can, but if we think its not a valid use case then we will just close it

            Where?

            in JIRA

            • 4. Re: Configure time before exception is thrown on full queue
              Yair Ogen Expert

              The UseCase is simple: producer is run within a HTTP Server it must reply within 3 seconds or else it's client will timeout. If producer blocks 10 seconds, the exception thrown is worthless as the server doesn't a client it can reply to with the error as it is no longer listening.

              • 5. Re: Configure time before exception is thrown on full queue
                Justin Bertram Master

                Despite your explanation, I still don't understand the use-case here.  A producer should only block if the address-full-policy is BLOCK in which case no exception should be thrown.  An exception should only be thrown if the address-full-policy is FAIL in which case the producer won't block.

                 

                BTW, I recently fixed a problem with FAIL.  See https://issues.jboss.org/browse/HORNETQ-1337.

                • 6. Re: Configure time before exception is thrown on full queue
                  Yair Ogen Expert

                  Thanks. Of course I was refering to a FAIL configuration. However, wouldn't the producer block during the 10 seconds before being released with an exception? From the code review - it looks as if it does.

                  • 7. Re: Configure time before exception is thrown on full queue
                    Andy Taylor Master

                    im not sure where you see 10 seconds, the exception should be thrown straight away, the exception here is of you are sending messages non blocking where obviously you wont receive a replay a warning is logged on the server.

                    • 8. Re: Configure time before exception is thrown on full queue
                      Yair Ogen Expert

                      From ClientsProducerCreditsImpl, wouldn't the producer first wait 10 seconds and if the queue doesn't get free space it will only then throw the exception?

                       

                      if (!tryAcquire)

                            {

                               if (!closed)

                               {

                                  this.blocked = true;

                                  try

                                  {

                                     while (!semaphore.tryAcquire(credits, 10, TimeUnit.SECONDS))

                                     {

                                        // I'm using string concatenation here in case address is null

                                        // better getting a "null" string than a NPE

                                        HornetQClientLogger.LOGGER.outOfCreditOnFlowControl("" + address);

                                     }

                                  }

                                  finally

                                  {

                                     this.blocked = false;

                                  }

                               }

                            }

                       

                       

                       

                       

                            synchronized (this)

                            {

                               pendingCredits -= credits;

                            }

                       

                       

                            // check to see if the blocking mode is FAIL on the server

                            synchronized (this)

                            {

                               if (serverRespondedWithFail)

                               {

                                  serverRespondedWithFail = false;

                       

                       

                                  // remove existing credits to force the client to ask the server for more on the next send

                                  semaphore.drainPermits();

                                  pendingCredits = 0;

                                  arriving = 0;

                       

                       

                                  throw HornetQClientMessageBundle.BUNDLE.addressIsFull(address.toString(), credits);

                               }

                            }

                      • 9. Re: Configure time before exception is thrown on full queue
                        Justin Bertram Master

                        Note, the name of the class in question is org.hornetq.core.client.impl.ClientProducerCreditsImpl.  It is related to credits acquired from the server as part of our flow control implementation for message producers.  The client typically won't need to get credits every time it produces a message.  However, when the client does run out of credits it may block for a short time, but this isn't strictly related to the address being full (although it could be).

                         

                        In any event, I still don't understand your use-case.

                        • 10. Re: Configure time before exception is thrown on full queue
                          Yair Ogen Expert

                          You acknowledge that the producer may block if it runs out of credits and this short time is what I'd like to be able to set configurably. Personally I think that 10 seconds is too much.

                          • 11. Re: Configure time before exception is thrown on full queue
                            Justin Bertram Master

                            Is your application being adversely impacted because of this credit-acquisition blocking when you use the FAIL address-full-policy?  If so, why not simply disable flow control on the client?  Have your read the documentation related to this?

                            • 12. Re: Configure time before exception is thrown on full queue
                              Yair Ogen Expert

                              let's put it this way. I want to verify that in fail mode if the queue is full:

                               

                              1. producer won't block forever.
                              2. time till producer gets an exception is configurable.

                               

                              From my POV as a client - the credits mechanism is not related. it's an internal HornetQ implementation detail. Currently, the credits impl class is the only place I see a reference to a full queue in the code. I think  that raising the credits limit is not sufficient in case the queue is really full. is it?

                               

                              So - should I open a JIRA to meet the above 2 requirements?

                               

                              UPDATE: create: https://issues.jboss.org/browse/HORNETQ-1346

                              • 13. Re: Configure time before exception is thrown on full queue
                                Justin Bertram Master
                                1. producer won't block forever.

                                Why would the producer block forever when using the FAIL address-full-policy?

                                 

                                time till producer gets an exception is configurable.

                                If the queue is full and the address-full-policy is FAIL and the producer sends a durable message (assuming it has enough credits to send) it will receive an exception immediately.  If all that is true but the client doesn't have enough credits to send then it will need to request credits from the server.  If the queue is full then the server will not give the client any credits but instead will trigger the client to throw an exception to the caller.  These are two independent cases.

                                 

                                From my POV as a client - the credits mechanism is not related.

                                The credits mechanism is not directly related, but it's in the mix because every send operation involves flow control.  The possibility exists that between the time the producer runs out of credits and requests more that the address will become full so we have to account for that possibility in the credit acquisition process.  Furthermore, when sending non-durable messages (which are sent asynchronously by default) this is the only time when the client will potentially block and we can trigger an exception so it knows the address is full.

                                 

                                it's an internal HornetQ implementation detail.

                                Flow control is supposed to be apparent to the user.  It's explicitly configurable so you can change the behavior as needed.  I'm not sure what the point here is.

                                 

                                Currently, the credits impl class is the only place I see a reference to a full queue in the code.

                                For overall context see my answer above.  This is only relevant when the producer doesn't have enough credits.  If the producer does have enough credits and sends a message to the server the server will send the exception back directly which will be decoded by the client and thrown to the caller.  See here.

                                 

                                I think  that raising the credits limit is not sufficient in case the queue is really full. is it?

                                You seem concerned that the client will potentially block for up to 10 seconds when requesting credits from the server.  If you wish to avoid that potential condition then you can avoid credit acquisition by tuning the flow control.

                                 

                                So - should I open a JIRA to meet the above 2 requirements?

                                No, I don't think so as I think you've misunderstood the semantics here.

                                1 of 1 people found this helpful