[
https://issues.apache.org/jira/browse/QPID-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984789#action_12984789
]
Robbie Gemmell edited comment on QPID-2902 at 1/21/11 2:30 PM:
---------------------------------------------------------------
Whilst investigating another issue I came across QPID-3010, and after applying
the fix for that LargeMessageTest hasn't failed since.
The issue here was not strictly the InputHandler slicing the ByteBuffer, as
only the Java broker was affected; the Java client was known to work ok against
the C++ broker despite use of exactly the same classes suggesting the
underlying cause actually lay elsewhere. The InputHandler is deliberately not
copying the ByteBuffer to prevent the expense of doing so, since the Assembler
is about to copy the frames into the completed command buffer before passing it
on to the connection level. The root cause of the problem was that MINA was not
configured in the expected way on the broker and so was free to reuse the
ByteBuffers at any point following exit from the InputHandler.received() method
due to use of its PooledByteBufferAllocator. It was also free to make use of
DirectByteBuffers instead of HeapByteBuffers and this was the cause of the
issue I started investigating.
As this problem was actually caused by another bug and avoiding the expense of
copying the ByteBuffers on both the client (which worked fine) and broker seems
desirable, I don't believe the attached patch should or needs to be applied.
was (Author: gemmellr):
Whilst investigating another issue I came across QPID-2310, and after
applying the fix for that LargeMessageTest hasn't failed since.
The issue here was not strictly the InputHandler slicing the ByteBuffer, as
only the Java broker was affected; the Java client was known to work ok against
the C++ broker despite use of exactly the same classes suggesting the
underlying cause actually lay elsewhere. The InputHandler is deliberately not
copying the ByteBuffer to prevent the expense of doing so, since the Assembler
is about to copy the frames into the completed command buffer before passing it
on to the connection level. The root cause of the problem was that MINA was not
configured in the expected way on the broker and so was free to reuse the
ByteBuffers at any point following exit from the InputHandler.received() method
due to use of its PooledByteBufferAllocator. It was also free to make use of
DirectByteBuffers instead of HeapByteBuffers and this was the cause of the
issue I started investigating.
As this problem was actually caused by another bug and avoiding the expense of
copying the ByteBuffers on both the client (which worked fine) and broker seems
desirable, I don't believe the attached patch should or needs to be applied.
> LargeMessageTest fails on java.0.10 test profiles
> -------------------------------------------------
>
> Key: QPID-2902
> URL: https://issues.apache.org/jira/browse/QPID-2902
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client
> Reporter: Robbie Gemmell
> Assignee: Andrew Kennedy
> Attachments: QPID-2902.patch
>
>
> LargeMessageTest sporadically fails on the java.0.10 test profiles. It is
> currently excluded.
> eg:
> FAILED
> Excpetion occured:java.nio.charset.MalformedInputException: Input length = 1
> junit.framework.AssertionFailedError: Excpetion
> occured:java.nio.charset.MalformedInputException: Input length = 1
> at
> org.apache.qpid.test.unit.basic.LargeMessageTest.checkLargeMessage(LargeMessageTest.java:159)
> at
> org.apache.qpid.test.unit.basic.LargeMessageTest.test1024k(LargeMessageTest.java:133)
> at
> org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:232)
> at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
