[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058541#comment-15058541
]
Robbie Gemmell commented on QPIDJMS-141:
----------------------------------------
Yes, I expected as such based on the description, in which case this isnt a
client bug, but expected based on the broker behaviour.
In JMS send is meant to be synchronous (hence them adding a new async API in
JMS 2.0), so if you send persistent messages the client defaults to doing
exactly that. If you send non-persistent messages then you are kind of saying
you dont mind losing them anyway, and it cheekily defaults to sending them
asynchronously as you already noticed. There is config (jms.forceAsyncSend,
http://qpid.apache.org/releases/qpid-jms-0.6.0/docs/index.html#jms-configuration-options)
so you can use to force it to behave one way or the other with either delivery
mode.
The broker in this case has a sync period where it waits to flush persistent
messages (on durable queues) to disk, and only acknowledges receipt once it has
done that, so the delay here is from the broker not informing the client of
accepting the message. AMQP 0-x clients had functionality to explicitly
synchronously request 'completion' of protocol commands, so clients had a way
to force the sync on demand and the broker relied on that. AMQP 1.0 doesnt use
the same 'command' model and there isnt a direct equivalent of that, so the
broker is jsut waiting for its store flush timeout to expire before doing the
sync to disk. QPID-6730 made that period configurable, so you would drive the
period lower to avoid such lengthy delays but resulting in more frequent disk
syncs.
> Thread sync error can cause long blocking delay after message send
> ------------------------------------------------------------------
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.6.0
> Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
> (!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
