[jira] [Updated] (QPID-8469) [Broker-J][Message Store] The message is already cleaned when the delete listener is called
[ https://issues.apache.org/jira/browse/QPID-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier VERMEULEN updated QPID-8469: Description: We're trying to implement the claim-check pattern on top of the > [Broker-J][Message Store] The message is already cleaned when the delete > listener is called > --- > > Key: QPID-8469 > URL: https://issues.apache.org/jira/browse/QPID-8469 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.0 >Reporter: Olivier VERMEULEN >Priority: Major > > We're trying to implement the claim-check pattern on top of the -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8469) [Broker-J][Message Store] The message is already cleaned when the delete listener is called
[ https://issues.apache.org/jira/browse/QPID-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier VERMEULEN updated QPID-8469: Description: We're trying to implement the claim-check pattern on top of the Broker. So when a big message is sent, we put the payload in a blob store and we just pass the ID in the message headers. The biggest problem is, when do we remove the payload from the blob store, especially in multicast mode ? The message delete listener would be perfect for that except that the message has already been cleaned when it is called and the headers have been removed... was:We're trying to implement the claim-check pattern on top of the > [Broker-J][Message Store] The message is already cleaned when the delete > listener is called > --- > > Key: QPID-8469 > URL: https://issues.apache.org/jira/browse/QPID-8469 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.0 >Reporter: Olivier VERMEULEN >Priority: Major > > We're trying to implement the claim-check pattern on top of the Broker. > So when a big message is sent, we put the payload in a blob store and we just > pass the ID in the message headers. > The biggest problem is, when do we remove the payload from the blob store, > especially in multicast mode ? > The message delete listener would be perfect for that except that the message > has already been cleaned when it is called and the headers have been > removed... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8469) [Broker-J][Message Store] The message is already cleaned when the delete listener is called
Olivier VERMEULEN created QPID-8469: --- Summary: [Broker-J][Message Store] The message is already cleaned when the delete listener is called Key: QPID-8469 URL: https://issues.apache.org/jira/browse/QPID-8469 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-8.0.0 Reporter: Olivier VERMEULEN -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2172) [c] Failure in FdLimitTest.test_fd_limit_broker on Ubuntu Bionic
[
https://issues.apache.org/jira/browse/PROTON-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17041022#comment-17041022
]
Olivier VERMEULEN commented on PROTON-2172:
---
I just experienced the exact same problem on RHEL7 and applying this patch
fixed it.
Is this fix going to be merged in master soon?
Thanks,
Olivier
> [c] Failure in FdLimitTest.test_fd_limit_broker on Ubuntu Bionic
>
>
> Key: PROTON-2172
> URL: https://issues.apache.org/jira/browse/PROTON-2172
> Project: Qpid Proton
> Issue Type: Test
> Components: proton-c
>Affects Versions: proton-c-0.30.0
>Reporter: Jiri Daněk
>Assignee: Jiri Daněk
>Priority: Major
>
> {noformat}
> test 6
> Start 6: c-fdlimit-tests
> 6: Test command: /opt/pyenv/shims/python
> "/home/travis/build/jdanekrh/qpid-proton/scripts/env.py" "--"
> "PATH=/home/travis/build/jdanekrh/qpid-proton/build/c/examples:/home/travis/bin:/home/travis/.local/bin:/usr/local/lib/jvm/openjdk11/bin:/opt/pyenv/shims:/home/travis/.phpenv/shims:/home/travis/perl5/perlbrew/bin:/home/travis/.nvm/versions/node/v13.3.0/bin:/home/travis/.rvm/gems/ruby-2.6.5/bin:/home/travis/.rvm/gems/ruby-2.6.5@global/bin:/home/travis/.rvm/rubies/ruby-2.6.5/bin:/home/travis/gopath/bin:/home/travis/.gimme/versions/go1.11.1.linux.amd64/bin:/usr/local/maven-3.6.3/bin:/usr/local/cmake-3.12.4/bin:/usr/local/clang-7.0.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/home/travis/.rvm/bin:/home/travis/.phpenv/bin:/opt/pyenv/bin:/home/travis/.yarn/bin"
> "PYTHONPATH=/home/travis/build/jdanekrh/qpid-proton/tests/py"
> "UBSAN_OPTIONS=suppressions=/home/travis/build/jdanekrh/qpid-proton/tests/ubsan.supp"
>
> "LSAN_OPTIONS=suppressions=/home/travis/build/jdanekrh/qpid-proton/tests/lsan.supp"
> "TEST_EXE_PREFIX=" "/opt/pyenv/shims/python"
> "/home/travis/build/jdanekrh/qpid-proton/c/tests/fdlimit.py"
> 6: Test timeout computed to be: 1500
> 6: E
> 6: ==
> 6: ERROR: test_fd_limit_broker (__main__.FdLimitTest)
> 6: Check behaviour when running out of file descriptors on accept
> 6: --
> 6: Traceback (most recent call last):
> 6: File "/home/travis/build/jdanekrh/qpid-proton/c/tests/fdlimit.py", line
> 83, in test_fd_limit_broker
> 6: self.assertEqual(sender.wait(), 0)
> 6: File
> "/home/travis/build/jdanekrh/qpid-proton/tests/py/test_subprocess.py", line
> 110, in __exit__
> 6: self.on_exit()
> 6: File
> "/home/travis/build/jdanekrh/qpid-proton/tests/py/test_subprocess.py", line
> 69, in check_wait
> 6: raise TestProcessError(self, "check_wait")
> 6: TestProcessError: ['send', '', '37845', 'x'] pid=12536 exit=1: check_wait
> 6: stderr(12536)
>
> 6: PN_TRANSPORT_CLOSED: amqp:connection:framing-error: Expected AMQP protocol
> header: no protocol header found (connection aborted)
> 6: stderr(12536)
>
> 6:
> 6:
> 6: --
> 6: Ran 1 test in 4.753s
> 6:
> 6: FAILED (errors=1)
> 6/43 Test #6: c-fdlimit-tests ..***Failed4.90 sec
> {noformat}
> https://api.travis-ci.org/v3/job/640518974/log.txt
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8408) JDBC store supports MS SQL Server
Olivier VERMEULEN created QPID-8408: --- Summary: JDBC store supports MS SQL Server Key: QPID-8408 URL: https://issues.apache.org/jira/browse/QPID-8408 Project: Qpid Issue Type: New Feature Components: Broker-J Affects Versions: qpid-java-broker-7.1.7 Reporter: Olivier VERMEULEN -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
[ https://issues.apache.org/jira/browse/QPID-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014250#comment-17014250 ] Olivier VERMEULEN commented on QPID-8401: - If this could be handled at the JDBC level that would be perfect but I don't think that it's possible. If you take Oracle for example, the resiliency is handled by the FCF feature of the UCP connection pool but according to the documentation this requires some retry logic on the client side... I guess I could write my own ConnectionProvider and do some retries if necessary at the level of the getConnection but that would only handle the creation of the connection, what if the DB crashes after getting the connection but before deleting the expired message? Now regarding the current behavior of the broker, note that when the broker dies this way I end up with a message that stays acquired forever (not by any client consumer but by the housekeeping task itself). When I restart the broker this message never gets deleted even though it expired and I can't consume it either... Shouldn't the message be released when rolling back the failed dequeue operation? [https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/queue/AbstractQueue.java#L1852] > [Broker-J] Broker dies when DB connection is lost > - > > Key: QPID-8401 > URL: https://issues.apache.org/jira/browse/QPID-8401 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.6 >Reporter: Olivier VERMEULEN >Priority: Critical > > When using a JDBC message store, if the housekeeping task is triggered while > the DB connection is lost (DB down or network problem) then the Broker dies > with the stack below. > This happens when a message expires and the housekeeping task tries to delete > it from the store while the DB is not accessible. In this case a > StoreException is thrown but this exception is not catched by the > Housekeeping task which is only catching ConnectionScopedRuntimeExceptions. > > 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006: > Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: > Connection is already closed. > at > org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819) > at > org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354) > at > org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236) > at > org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131) > at > org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.sql.SQLException: JZ006: Caught IOException: > com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is > already closed. > at >
[jira] [Updated] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
[ https://issues.apache.org/jira/browse/QPID-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier VERMEULEN updated QPID-8401: Priority: Critical (was: Major) > [Broker-J] Broker dies when DB connection is lost > - > > Key: QPID-8401 > URL: https://issues.apache.org/jira/browse/QPID-8401 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.6 >Reporter: Olivier VERMEULEN >Priority: Critical > > When using a JDBC message store, if the housekeeping task is triggered while > the DB connection is lost (DB down or network problem) then the Broker dies > with the stack below. > This happens when a message expires and the housekeeping task tries to delete > it from the store while the DB is not accessible. In this case a > StoreException is thrown but this exception is not catched by the > Housekeeping task which is only catching ConnectionScopedRuntimeExceptions. > > 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006: > Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: > Connection is already closed. > at > org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819) > at > org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354) > at > org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236) > at > org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131) > at > org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.sql.SQLException: JZ006: Caught IOException: > com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is > already closed. > at > com.sybase.jdbc4.jdbc.ErrorMessage.createIOEKilledConnEx(ErrorMessage.java:1155) > at > com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:1194) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5250) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5195) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
[ https://issues.apache.org/jira/browse/QPID-8401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17012718#comment-17012718 ] Olivier VERMEULEN commented on QPID-8401: - A quick fix would be to catch RuntimeException instead of ConnectionScopedRuntimeException here: [https://github.com/apache/qpid-broker-j/blob/master/broker-core/src/main/java/org/apache/qpid/server/virtualhost/HouseKeepingTask.java#L65] But I don't know what will happen to the message that was being removed. Will the broker automatically try to remove it again the next time the housekeeping task is run? > [Broker-J] Broker dies when DB connection is lost > - > > Key: QPID-8401 > URL: https://issues.apache.org/jira/browse/QPID-8401 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.6 >Reporter: Olivier VERMEULEN >Priority: Major > > When using a JDBC message store, if the housekeeping task is triggered while > the DB connection is lost (DB down or network problem) then the Broker dies > with the stack below. > This happens when a message expires and the housekeeping task tries to delete > it from the store while the DB is not accessible. In this case a > StoreException is thrown but this exception is not catched by the > Housekeeping task which is only catching ConnectionScopedRuntimeExceptions. > > 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) - > Uncaught exception, shutting down. > org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006: > Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: > Connection is already closed. > at > org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118) > at > org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114) > at > org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780) > at > org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775) > at > org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819) > at > org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354) > at > org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236) > at > org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131) > at > org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.sql.SQLException: JZ006: Caught IOException: > com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is > already closed. > at > com.sybase.jdbc4.jdbc.ErrorMessage.createIOEKilledConnEx(ErrorMessage.java:1155) > at > com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:1194) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5250) > at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5195) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8401) [Broker-J] Broker dies when DB connection is lost
Olivier VERMEULEN created QPID-8401: --- Summary: [Broker-J] Broker dies when DB connection is lost Key: QPID-8401 URL: https://issues.apache.org/jira/browse/QPID-8401 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.1.6 Reporter: Olivier VERMEULEN When using a JDBC message store, if the housekeeping task is triggered while the DB connection is lost (DB down or network problem) then the Broker dies with the stack below. This happens when a message expires and the housekeeping task tries to delete it from the store while the DB is not accessible. In this case a StoreException is thrown but this exception is not catched by the Housekeeping task which is only catching ConnectionScopedRuntimeExceptions. 2019-12-12 16:22:40,671 ERROR [virtualhost-default-pool-3] (o.a.q.s.Main) - Uncaught exception, shutting down. org.apache.qpid.server.store.StoreException: java.sql.SQLException: JZ006: Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is already closed. at org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1153) at org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122) at org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118) at org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114) at org.apache.qpid.server.txn.AutoCommitTransaction.dequeue(AutoCommitTransaction.java:87) at org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1780) at org.apache.qpid.server.queue.AbstractQueue.dequeueEntry(AbstractQueue.java:1775) at org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1819) at org.apache.qpid.server.queue.AbstractQueue.expireEntry(AbstractQueue.java:2354) at org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2236) at org.apache.qpid.server.queue.AbstractQueue.access$1800(AbstractQueue.java:131) at org.apache.qpid.server.queue.AbstractQueue$AdvanceConsumersTask.execute(AbstractQueue.java:3712) at org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:56) at java.security.AccessController.doPrivileged(Native Method) at org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:51) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) at java.lang.Thread.run(Thread.java:748) Caused by: java.sql.SQLException: JZ006: Caught IOException: com.sybase.jdbc4.jdbc.SybConnectionDeadException: JZ0C0: Connection is already closed. at com.sybase.jdbc4.jdbc.ErrorMessage.createIOEKilledConnEx(ErrorMessage.java:1155) at com.sybase.jdbc4.jdbc.ErrorMessage.raiseErrorCheckDead(ErrorMessage.java:1194) at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5250) at com.sybase.jdbc4.tds.Tds.handleIOE(Tds.java:5195) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1498) Skip SASL tests if Cyrus library is not available
Olivier VERMEULEN created DISPATCH-1498: --- Summary: Skip SASL tests if Cyrus library is not available Key: DISPATCH-1498 URL: https://issues.apache.org/jira/browse/DISPATCH-1498 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.9.0 Reporter: Olivier VERMEULEN -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16982645#comment-16982645
]
Olivier VERMEULEN commented on DISPATCH-1172:
-
[~gmurthy] sorry for the very late reply.
I managed to reproduce the initial problem (auto links activated on the wrong
connections) on the dispatch-router 1.9.0 but it is indeed fixed on the master.
Thanks!
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946823#comment-16946823
]
Olivier VERMEULEN commented on DISPATCH-1172:
-
Will do and will keep you posted with the results
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946642#comment-16946642
]
Olivier VERMEULEN commented on DISPATCH-1172:
-
Hello [~gmurthy], my team is willing to contribute to fix this bug but would
you be available for a small pairing session? To give us at least the
entrypoints and to put us on the right track?
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8305) [Broker-J][JDBC Message Store] Performance regression when increasing the number of queues linked to a topic
Olivier VERMEULEN created QPID-8305: --- Summary: [Broker-J][JDBC Message Store] Performance regression when increasing the number of queues linked to a topic Key: QPID-8305 URL: https://issues.apache.org/jira/browse/QPID-8305 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-7.1.0 Reporter: Olivier VERMEULEN When sending a message to a topic, if this message is routed to N queues then we will do N+2 database inserts: 1 for the metadata, 1 for the content and 1 for each message/queue mapping (QPID_QUEUE_ENTRIES). The last N inserts could be batched in a single operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8304) [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor
Olivier VERMEULEN created QPID-8304: --- Summary: [Broker-J][JDBC Message Store] Performance bottleneck at the level of the executor Key: QPID-8304 URL: https://issues.apache.org/jira/browse/QPID-8304 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-7.1.0 Reporter: Olivier VERMEULEN -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8303) [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages
Olivier VERMEULEN created QPID-8303: --- Summary: [Broker-J][JDBC Message Store] Batch delete fails when deleting exactly 1000 messages Key: QPID-8303 URL: https://issues.apache.org/jira/browse/QPID-8303 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Olivier VERMEULEN Following QPID-8294, when the batch delete has exactly IN_CLAUSE_MAX_SIZE messages to handle, removeMessagesFromDatabase will be called twice and the second time with an empty list. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8299) [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker
Olivier VERMEULEN created QPID-8299: --- Summary: [Broker-J][JDBC Config Store] Possibility to customize the connection provider for the config of the Broker Key: QPID-8299 URL: https://issues.apache.org/jira/browse/QPID-8299 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-7.1.0 Reporter: Olivier VERMEULEN Where the config of the Broker (not the Virtual Host) should be stored is defined in the command line. Currently in the command line we can define systemConfig.connectionUrl/username/password/tableNamePrefix but not systemConfig.connectionPoolType -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes
[ https://issues.apache.org/jira/browse/QPID-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812279#comment-16812279 ] Olivier VERMEULEN commented on QPID-8297: - Working on a fix... > [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps > growing until it reaches the limit and crashes > - > > Key: QPID-8297 > URL: https://issues.apache.org/jira/browse/QPID-8297 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Olivier VERMEULEN >Priority: Critical > > Under a continuous high load, the Oracle message store crashes because the > reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if > the table itself is empty since we consume as fast as we produce). > This only happens for "big" messages (over 4KB) and comes from the way Oracle > handles the LOB types (content column is declared as a BLOB). For LOB values > over 4KB Oracle reserves some space in the table to handle the value but, by > default, it won't actually release it (even if the value is removed) before a > few hours. > So when we have a high load of big messages that lasts a few hours we end up > reaching the max size of the tablespace and the database crashes... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8297) [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes
Olivier VERMEULEN created QPID-8297: --- Summary: [Broker-J][Oracle Message Store] QPID_MESSAGE_CONTENT reserved space keeps growing until it reaches the limit and crashes Key: QPID-8297 URL: https://issues.apache.org/jira/browse/QPID-8297 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.1.0 Reporter: Olivier VERMEULEN Under a continuous high load, the Oracle message store crashes because the reserved space for the table QPID_MESSAGE_CONTENT keeps on growing (even if the table itself is empty since we consume as fast as we produce). This only happens for "big" messages (over 4KB) and comes from the way Oracle handles the LOB types (content column is declared as a BLOB). For LOB values over 4KB Oracle reserves some space in the table to handle the value but, by default, it won't actually release it (even if the value is removed) before a few hours. So when we have a high load of big messages that lasts a few hours we end up reaching the max size of the tablespace and the database crashes... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages
[ https://issues.apache.org/jira/browse/QPID-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier VERMEULEN updated QPID-8294: Priority: Critical (was: Major) > [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 > messages > --- > > Key: QPID-8294 > URL: https://issues.apache.org/jira/browse/QPID-8294 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Olivier VERMEULEN >Priority: Critical > > When under high load, the Broker-J can end up having to delete more than 1000 > messages in a single batch. But some databases (and Oracle in particular) put > a limit to the number of elements you can have in the IN clause. So we end up > with the following exception: ORA-01795: maximum number of expressions in a > list is 1000 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8294) [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages
Olivier VERMEULEN created QPID-8294: --- Summary: [Broker-J][Oracle Message Store] Batch delete fails for more than 1000 messages Key: QPID-8294 URL: https://issues.apache.org/jira/browse/QPID-8294 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.1.0 Reporter: Olivier VERMEULEN When under high load, the Broker-J can end up having to delete more than 1000 messages in a single batch. But some databases (and Oracle in particular) put a limit to the number of elements you can have in the IN clause. So we end up with the following exception: ORA-01795: maximum number of expressions in a list is 1000 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16724920#comment-16724920
]
Olivier VERMEULEN commented on DISPATCH-1172:
-
[~ganeshmurthy] I confirm that this bug randomly leads to messages going to the
alternate binding even if there is a viable route for the binding key of this
message...
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677851#comment-16677851
]
Olivier VERMEULEN edited comment on DISPATCH-1172 at 11/7/18 1:32 PM:
--
[~ganeshmurthy] In case of multiple route-container connections what kind of
issues could I face?
I'm asking because we are facing a random issue right now where a message sent
to a topic (through a dispatch-router configured with multiple route-container
connections) is being routed to the DLQ instead of the queue matching its
binding-key... Could it come from this?
was (Author: overmeulen):
In case of multiple route-container connections what kind of issues could I
face?
I'm asking because we are facing a random issue right now where a message sent
to a topic (through a dispatch-router configured with **multiple
route-container connections) is being routed to the DLQ instead of the queue
matching its binding-key... Could it come from this?
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1172) Link routes and auto links activated on wrong connections if many route-container conns exist
[
https://issues.apache.org/jira/browse/DISPATCH-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677851#comment-16677851
]
Olivier VERMEULEN commented on DISPATCH-1172:
-
In case of multiple route-container connections what kind of issues could I
face?
I'm asking because we are facing a random issue right now where a message sent
to a topic (through a dispatch-router configured with **multiple
route-container connections) is being routed to the DLQ instead of the queue
matching its binding-key... Could it come from this?
> Link routes and auto links activated on wrong connections if many
> route-container conns exist
> -
>
> Key: DISPATCH-1172
> URL: https://issues.apache.org/jira/browse/DISPATCH-1172
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.4.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
>
> Run the following script
>
> {noformat}
> #!/usr/bin/env bash
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=dest waypoint=true
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.address prefix=sub waypoint=true
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type org.apache.qpid.dispatch.connector
> host=0.0.0.0 port=5672 name=broker_conn${i} role=route-container
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=dest direction=out
> name=auto-link-dest${i} connection=broker_conn${i}
> done
> for i in {1..10}; do
> qdmanage -b 0.0.0.0:5673 create --type
> org.apache.qpid.dispatch.router.config.autoLink addr=sub direction=in
> name=auto-link-sub${i} connection=broker_conn${i}
> done{noformat}
>
> all auto links will be activated against all connections. This happens also
> with link routes.
>
> This problem happens due to the way the connections are aggregated under a
> single container id. The connections should also get their own connection ids.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1173) Exceptions handling
[
https://issues.apache.org/jira/browse/DISPATCH-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier VERMEULEN updated DISPATCH-1173:
Description:
We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
For the same use case, the exception we get from the dispatch-router is much
less explicit than the one we get when we connect to the broker directly.
+For example when sending a message to a topic that does not exist.+
* *Through the broker:*
javax.jms.InvalidDestinationException: Could not find destination for target
'Target
\{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}
' [condition = amqp:not-found]
* *Through the dispatch-router* (defaultDistribution set to unavailable):
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
+Another example when sending a message bigger than the max_message_size set on
the broker:+
* *Through the broker*:
javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
[condition = amqp:link:message-size-exceeded]
* *Through the dispatch-router*:
javax.jms.JMSException: Delivery failed: failure at remote
was:
We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
For the same use case, the exception we get from the dispatch-router is much
less explicit than the one we get when we connect to the broker directly.
+For example when sending a message to a topic that does not exist.+
* *Through the broker:*
javax.jms.InvalidDestinationException: Could not find destination for target
'Target{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}'
[condition = amqp:not-found]
* *Through the dispatch-router* (defaultDistribution set to unavailable):
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
+Another example when sending a message bigger than the max_message_size set on
the broker:+
* *Through the broker*:
javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
[condition = amqp:link:message-size-exceeded]
* *Through the dispatch-router*:
javax.jms.JMSException: Delivery failed: failure at remote
> Exceptions handling
> ---
>
> Key: DISPATCH-1173
> URL: https://issues.apache.org/jira/browse/DISPATCH-1173
> Project: Qpid Dispatch
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Olivier VERMEULEN
>Priority: Major
>
> We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
> For the same use case, the exception we get from the dispatch-router is much
> less explicit than the one we get when we connect to the broker directly.
>
> +For example when sending a message to a topic that does not exist.+
> * *Through the broker:*
> javax.jms.InvalidDestinationException: Could not find destination for target
> 'Target
> \{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}
> ' [condition = amqp:not-found]
> * *Through the dispatch-router* (defaultDistribution set to unavailable):
> javax.jms.InvalidDestinationException: Node not found [condition =
> amqp:not-found]
>
> +Another example when sending a message bigger than the max_message_size set
> on the broker:+
> * *Through the broker*:
> javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
> [condition = amqp:link:message-size-exceeded]
> * *Through the dispatch-router*:
> javax.jms.JMSException: Delivery failed: failure at remote
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1173) Exceptions handling
[
https://issues.apache.org/jira/browse/DISPATCH-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier VERMEULEN updated DISPATCH-1173:
Description:
We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
For the same use case, the exception we get from the dispatch-router is much
less explicit than the one we get when we connect to the broker directly.
+For example when sending a message to a topic that does not exist.+
* *Through the broker:*
javax.jms.InvalidDestinationException: Could not find destination for target
'Target{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}'
[condition = amqp:not-found]
* *Through the dispatch-router* (defaultDistribution set to unavailable):
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
+Another example when sending a message bigger than the max_message_size set on
the broker:+
* *Through the broker*:
javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
[condition = amqp:link:message-size-exceeded]
* *Through the dispatch-router*:
javax.jms.JMSException: Delivery failed: failure at remote
was:
We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
For the same use case, the exception we get from the dispatch-router is much
less explicit than the one we get when we connect to the broker directly.
For example when sending a message to a topic that does not exist.
* Through the broker:
javax.jms.InvalidDestinationException: Could not find destination for target
'Target\{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}'
[condition = amqp:not-found]
* Through the dispatch-router (defaultDistribution set to unavailable):
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
Another example when sending a message bigger than the max_message_size set on
the broker:
* Through the broker:
javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
[condition = amqp:link:message-size-exceeded]
* Through the dispatch-router:
javax.jms.JMSException: Delivery failed: failure at remote
> Exceptions handling
> ---
>
> Key: DISPATCH-1173
> URL: https://issues.apache.org/jira/browse/DISPATCH-1173
> Project: Qpid Dispatch
> Issue Type: Improvement
>Affects Versions: 1.3.0
>Reporter: Olivier VERMEULEN
>Priority: Major
>
> We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
> For the same use case, the exception we get from the dispatch-router is much
> less explicit than the one we get when we connect to the broker directly.
>
> +For example when sending a message to a topic that does not exist.+
> * *Through the broker:*
> javax.jms.InvalidDestinationException: Could not find destination for target
> 'Target{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}'
> [condition = amqp:not-found]
> * *Through the dispatch-router* (defaultDistribution set to unavailable):
> javax.jms.InvalidDestinationException: Node not found [condition =
> amqp:not-found]
>
> +Another example when sending a message bigger than the max_message_size set
> on the broker:+
> * *Through the broker*:
> javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
> [condition = amqp:link:message-size-exceeded]
> * *Through the dispatch-router*:
> javax.jms.JMSException: Delivery failed: failure at remote
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1173) Exceptions handling
Olivier VERMEULEN created DISPATCH-1173:
---
Summary: Exceptions handling
Key: DISPATCH-1173
URL: https://issues.apache.org/jira/browse/DISPATCH-1173
Project: Qpid Dispatch
Issue Type: Improvement
Affects Versions: 1.3.0
Reporter: Olivier VERMEULEN
We are using the Dispatch-Router 1.3.0, Broker-J 7.0.3 and Qpid JMS 0.11.1
For the same use case, the exception we get from the dispatch-router is much
less explicit than the one we get when we connect to the broker directly.
For example when sending a message to a topic that does not exist.
* Through the broker:
javax.jms.InvalidDestinationException: Could not find destination for target
'Target\{address=unknownDestination,durable=none,expiryPolicy=session-end,dynamic=false,capabilities=[topic]}'
[condition = amqp:not-found]
* Through the dispatch-router (defaultDistribution set to unavailable):
javax.jms.InvalidDestinationException: Node not found [condition =
amqp:not-found]
Another example when sending a message bigger than the max_message_size set on
the broker:
* Through the broker:
javax.jms.JMSException: delivery '\x00' exceeds max-message-size 10240
[condition = amqp:link:message-size-exceeded]
* Through the dispatch-router:
javax.jms.JMSException: Delivery failed: failure at remote
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676697#comment-16676697 ] Olivier VERMEULEN commented on QPID-8257: - Changed the fix to "image null" > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676607#comment-16676607 ] Olivier VERMEULEN commented on QPID-8257: - So rather "image null" than the new supportExplicitNullColumn method I added in my last patch? > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676577#comment-16676577 ] Olivier VERMEULEN commented on QPID-8257: - Hello Alex, Here is (part of) the stack we get when sending a message with an empty body: 2018-10-23 14:45:23,927 ERROR [IO-/10.25.1.142:34140] (o.a.q.s.u.ServerScopedRuntimeException) - Error adding content for message 1: Attempt to insert NULL value into column 'content', table 'TPK0002630_321682_01666C53613C.MUREXDB.broker2_QPID_MESSAGE_CONTENT'; column does not allow nulls. Update fails. com.sybase.jdbc4.jdbc.SybSQLException: Attempt to insert NULL value into column 'content', table 'TPK0002630_321682_01666C53613C.MUREXDB.broker2_QPID_MESSAGE_CONTENT'; column does not allow nulls. Update fails. Regarding Derby I saw that and pushed another patch this morning to support both use cases. > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8257) Sybase message store not supporting empty messages
Olivier VERMEULEN created QPID-8257: --- Summary: Sybase message store not supporting empty messages Key: QPID-8257 URL: https://issues.apache.org/jira/browse/QPID-8257 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.3 Reporter: Olivier VERMEULEN Unlike other databases Sybase default nullability for a column is "NOT NULL". And since we don't specify anything when creating the QPID_MESSAGE_CONTENT table, the "content" column defaults to "NOT NULL". So when we send an empty message, this constraint is broken and we receive a SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1862) Idle timeout not working on Linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608919#comment-16608919 ] Olivier VERMEULEN commented on PROTON-1862: --- Hello Zafar, I'll answer for Jeremy who's on vacation right now: feel free to work on this one, we're working on something else right now. Regards, Olivier > Idle timeout not working on Linux > - > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Labels: reproducer > Attachments: proton_1862_tests.txt, test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8214) Reduce the table names size in the JDBC configuration store to fit Oracle's 30 characters limitation
Olivier VERMEULEN created QPID-8214: --- Summary: Reduce the table names size in the JDBC configuration store to fit Oracle's 30 characters limitation Key: QPID-8214 URL: https://issues.apache.org/jira/browse/QPID-8214 Project: Qpid Issue Type: Improvement Components: Broker-J Affects Versions: qpid-java-broker-7.0.4 Reporter: Olivier VERMEULEN 'QPID_CONFIGURED_OBJECT_HIERARCHY' is already 32 characters long. And we should also take into account that users can specify a table name prefix. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8105) broker-core unit tests are failing because of wrong locale
Olivier VERMEULEN created QPID-8105: --- Summary: broker-core unit tests are failing because of wrong locale Key: QPID-8105 URL: https://issues.apache.org/jira/browse/QPID-8105 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: qpid-java-broker-7.0.1 Reporter: Olivier VERMEULEN -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
