qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Moravec (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (QPID-4524) Java client timeouts after sending huge message to existing durable queue
Date Thu, 10 Jul 2014 06:49:05 GMT

     [ 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message