[
https://issues.apache.org/jira/browse/QPID-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Moravec closed QPID-4524.
-------------------------------
Resolution: Not a Problem
It is expected behaviour. Client timeouts after (default) 60 seconds. It is
recommended either increase -Dqpid.sync_op_timeout option or make store to work
faster.
> Java client timeouts after sending huge message to existing durable queue
> -------------------------------------------------------------------------
>
> Key: QPID-4524
> URL: https://issues.apache.org/jira/browse/QPID-4524
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Affects Versions: 0.18
> Reporter: Pavel Moravec
> Priority: Minor
> Attachments: QPID4524_reproducer.tar.gz
>
>
> Description of problem:
> Having a durable queue created, if one tries to send two huge messages (e.g.
> of 2MiB each), Java client timeouts after sending the first and before
> sending the second.
> Version-Release number of selected component (if applicable):
> 0.18-3
> How reproducible:
> 100%
> Steps to Reproduce:
> Use attached reproducer (that sends one huge message followed by a small one):
> 1. qpid-config add queue test --durable
> 2. java test_00734429
>
> Actual results:
> Exception in thread "main" javax.jms.JMSException: Exception when sending
> message:timed out waiting for completion
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:241)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:511)
> at
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
> at test_00734429.<init>(test_00734429.java:45)
> at test_00734429.main(test_00734429.java:24)
> Caused by: org.apache.qpid.transport.SessionException: timed out waiting for
> completion
> at org.apache.qpid.transport.Session.invoke(Session.java:742)
> at org.apache.qpid.transport.Session.invoke(Session.java:615)
> at
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:93)
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:227)
> ... 4 more
> Expected results:
> No such exception, also 2nd message is sent.
> Additional info:
> - if the queue is _not_ existing before running the reproducer, no issue
> occurs (the reproducer creates the "auto-create" queue, see properties file)
> - the root cause of the bug is that when the client library gets AMQP message
> session.completed with commands = [], it does not notify commandsLock in
> org.apache.qpid.transport.Session.invoke, hence it waits there until timeout;
> proper behavior (similar to the one when getting session.completed with
> non-empty commands) is to notify the lock and send next session.flush
> - jstack from the timing-out reproducer:
> "main" prio=10 tid=0x00007fcee8007800 nid=0x1ebb in Object.wait()
> [0x00007fceedc04000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000f25d1bc0> (a java.lang.Object)
> at org.apache.qpid.transport.util.Waiter.await(Waiter.java:54)
> at org.apache.qpid.transport.Session.invoke(Session.java:716)
> - locked <0x00000000f25d1bc0> (a java.lang.Object)
> at org.apache.qpid.transport.Session.invoke(Session.java:615)
> at
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:93)
> at
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:227)
> at
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:511)
> at
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:309)
> - locked <0x00000000f31fb060> (a java.lang.Object)
> at test_00734429.<init>(test_00734429.java:45)
> at test_00734429.main(test_00734429.java:24)
> - Source code root cause:
> getting session.complete with empty range causes
> org.apache.qpid.transport.SessionDelegate.sessionCompleted does not step into
> this if-branch:
> if (ranges != null)
> {
> if(ranges.size() == 1)
> {
> Range range = ranges.getFirst();
> boolean advanced = ssn.complete(range.getLower(),
> range.getUpper());
> ..
>
> where ssn.complete calls commandsLock.notifyAll(); at its end.
> Therefore, "else" branch of this if command has to either:
> - call the same method (modified such that it works with -1 as its both
> arguments)
> - or call some auxiliary method invoking "commandsLock.notifyAll();"
> I don't know what approach is preferable thus leaving the JIRA without patch.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
