-
1. Re: Configure time before exception is thrown on full queue
ataylor May 1, 2014 6:57 AM (in response to yairogen)no
-
2. Re: Configure time before exception is thrown on full queue
yairogen May 1, 2014 8:46 AM (in response to ataylor)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
ataylor May 1, 2014 9:00 AM (in response to yairogen)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
yairogen May 1, 2014 10:48 AM (in response to ataylor)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
jbertram May 1, 2014 10:58 AM (in response to yairogen)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
yairogen May 1, 2014 12:33 PM (in response to jbertram)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
ataylor May 1, 2014 1:15 PM (in response to yairogen)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
yairogen May 1, 2014 2:00 PM (in response to ataylor)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
jbertram May 1, 2014 3:23 PM (in response to yairogen)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
yairogen May 1, 2014 4:10 PM (in response to jbertram)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
jbertram May 1, 2014 4:57 PM (in response to yairogen)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
yairogen May 7, 2014 9:35 AM (in response to jbertram)let's put it this way. I want to verify that in fail mode if the queue is full:
- producer won't block forever.
- 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
jbertram May 12, 2014 11:04 AM (in response to yairogen)1 of 1 people found this helpful- 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.