You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2017/10/22 14:11:00 UTC
[jira] [Commented] (QPID-7982) [Java Broker] MariaDB backed JDBC
virtualhost truncates message content at 64K leading to Broker abnormal
shutdown
[ https://issues.apache.org/jira/browse/QPID-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16214325#comment-16214325 ]
Keith Wall commented on QPID-7982:
----------------------------------
I expect this is a long standing issue and will be present on 6.0 and 6.1 too. The root cause of this problem is QPID-6766. It is not reasonable for the Broker to expect the JDBC providers to cope with a message of any size in one go. The Broker should really chunk the data within the store. This would also allow large messages to be streamed in and out of the database, avoiding the need for large messages to materialise all at once in memory or in network buffers between the Broker and DB.
Currently, the problem I have highlighted above affects only MariaDB and MySQL. Their BLOB type is limited to 64K. This is so low users could hit it. Other providers, Postgres, Oracle, Sybase, Derby have much more generous limits (see links).
* https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits001.htm#i287903
* http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36271.1572/html/blocks/X39672.htm
* https://wiki.postgresql.org/wiki/BinaryFilesInDB
* https://db.apache.org/derby/docs/10.1/ref/rrefblob.html
* https://dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
* https://mariadb.com/kb/en/library/blob/
The MySQL docs point out to The maximum size of a BLOB or TEXT object is determined by its type, but the largest value you actually can transmit between the client and server is determined by the amount of available memory and the size of the communications buffers. “
> [Java Broker] MariaDB backed JDBC virtualhost truncates message content at 64K leading to Broker abnormal shutdown
> ------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7982
> URL: https://issues.apache.org/jira/browse/QPID-7982
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
>
> When using the Qpid Broker-J with a JDBC backed virtualhost using MariaDB, the database silently truncates message content at 64KB. This means if the Broker needs to recover a message from disk (i.e. after a restart or after message content has been flowed to disk), it will fail to retrieve the expected number of message bytes and will fail as it tries to deliver the message to the consumer. The failure also manifests if the message is viewed from Management.
> {noformat}
> ########################################################################
> #
> # Unhandled Exception java.lang.IllegalArgumentException: offset: 0, length: 262152, remaining: 65535 in Thread IO-/127.0.0.1:56942
> #
> # Exiting
> #
> ########################################################################
> java.lang.IllegalArgumentException: offset: 0, length: 262152, remaining: 65535
> at org.apache.qpid.server.bytebuffer.QpidByteBuffer.view(QpidByteBuffer.java:1003)
> at org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$StoredJDBCMessage.getContent(AbstractJDBCMessageStore.java:1443)
> at org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:191)
> at org.apache.qpid.server.protocol.v1_0.Message_1_0.getContent(Message_1_0.java:215)
> at org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:181)
> at org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:154)
> at org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:227)
> at org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:280)
> at org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:162)
> at org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:394)
> at org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator.lambda$next$2(AMQPConnection_1_0Impl.java:1814)
> at org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
> at org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
> at org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Inspecting the db you see:
> {noformat}
> MariaDB [qpid]> select octet_length(content) from QPID_MESSAGE_CONTENT
> -> ;
> +-----------------------+
> | octet_length(content) |
> +-----------------------+
> | 65535 |
> +-----------------------+
> 1 row in set (0.01 sec)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org