[
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: [email protected]
For additional commands, e-mail: [email protected]
