qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPID-7982) [Java Broker] MariaDB backed JDBC virtualhost truncates message content at 64K leading to Broker abnormal shutdown
Date Sun, 22 Oct 2017 14:22:00 GMT

    [ https://issues.apache.org/jira/browse/QPID-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16214325#comment-16214325
] 

Keith Wall edited comment on QPID-7982 at 10/22/17 2:21 PM:
------------------------------------------------------------

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, in a practical sense, 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. “

A MariaDB user who is affected by this problem could change the type of the column from BLOB=>MEDIUMBLOB
(16MB) or LONGBLOB (4GB).   For an existing system, the change could be made at SQL level
with a command such as {{alter table QPID_MESSAGE_CONTENT modify column content mediumblob}}.
  Unfortunately, existing large messages are corrupt  and will need to be removed from the
database.







was (Author: k-wall):
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. “

A MariaDB user who is affected by this problem could change the type of the column from BLOB=>MEDIUMBLOB
(16MB) or LONGBLOB (4GB).   For an existing system, the change could be made at SQL level
with a command such as {{alter table QPID_MESSAGE_CONTENT modify column content mediumblob}}.
  Unfortunately, existing large messages are corrupt  and will need to be removed from the
database.






> [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


Mime
View raw message