[jira] [Commented] (QPIDJMS-283) Pipeline the declare that follows a transaction discharge for quicker processing
[ https://issues.apache.org/jira/browse/QPIDJMS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965064#comment-15965064 ] ASF subversion and git services commented on QPIDJMS-283: - Commit 091aa1df304a2c954593e6a4e418bc40dbd392e9 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=091aa1d ] QPIDJMS-283 Ensure new TX started whenever there is pipelined failure When offline the failover provider allows rollback to complete normally as the TX has been terminated already so the command doesn't need to be held. We need to ensure that when these states happen we still look and begin a new TX which will wait for connection restoration to complete. > Pipeline the declare that follows a transaction discharge for quicker > processing > > > Key: QPIDJMS-283 > URL: https://issues.apache.org/jira/browse/QPIDJMS-283 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.21.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.22.0 > > > For the normal commit / rollback case we can send an immediate Declare of a > new transaction to speed up the message rate when operating inside a > transacted session. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPIDJMS-283) Pipeline the declare that follows a transaction discharge for quicker processing
[ https://issues.apache.org/jira/browse/QPIDJMS-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reopened QPIDJMS-283: -- One intermittent test failure showed an issue with failover handling and recovery. > Pipeline the declare that follows a transaction discharge for quicker > processing > > > Key: QPIDJMS-283 > URL: https://issues.apache.org/jira/browse/QPIDJMS-283 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.21.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.22.0 > > > For the normal commit / rollback case we can send an immediate Declare of a > new transaction to speed up the message rate when operating inside a > transacted session. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-286) Shorten the thread name given to the AmqpProvider executor thread
[ https://issues.apache.org/jira/browse/QPIDJMS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-286. -- Resolution: Fixed > Shorten the thread name given to the AmqpProvider executor thread > - > > Key: QPIDJMS-286 > URL: https://issues.apache.org/jira/browse/QPIDJMS-286 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.21.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.22.0 > > > The executor thread in the AmqpProdiver class creates an overly long thread > name using the URI with all the configuration options. This name really only > needs reflect the host and port the provider was created to connect to. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-286) Shorten the thread name given to the AmqpProvider executor thread
[ https://issues.apache.org/jira/browse/QPIDJMS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964863#comment-15964863 ] ASF subversion and git services commented on QPIDJMS-286: - Commit 6c4abcf468a23132087f87bc2c7ce36acf5d74f5 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=6c4abcf ] QPIDJMS-286 Create a more concise name for the AmqpProvider thread Use only the scheme + host + port values to create the thread name in order to keep the size within reason. > Shorten the thread name given to the AmqpProvider executor thread > - > > Key: QPIDJMS-286 > URL: https://issues.apache.org/jira/browse/QPIDJMS-286 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.21.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.22.0 > > > The executor thread in the AmqpProdiver class creates an overly long thread > name using the URI with all the configuration options. This name really only > needs reflect the host and port the provider was created to connect to. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-286) Shorten the thread name given to the AmqpProvider executor thread
Timothy Bish created QPIDJMS-286: Summary: Shorten the thread name given to the AmqpProvider executor thread Key: QPIDJMS-286 URL: https://issues.apache.org/jira/browse/QPIDJMS-286 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.21.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.22.0 The executor thread in the AmqpProdiver class creates an overly long thread name using the URI with all the configuration options. This name really only needs reflect the host and port the provider was created to connect to. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-742) Assert while passing multicast or presettled anycast msgs across network
[
https://issues.apache.org/jira/browse/DISPATCH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-742.
---
Resolution: Fixed
> Assert while passing multicast or presettled anycast msgs across network
>
>
> Key: DISPATCH-742
> URL: https://issues.apache.org/jira/browse/DISPATCH-742
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.8.0
> Environment: Fedora 25. Two node network. One sender on node A, one
> receiver on node B. Send/recv clients are Proton Cpp simple_send and
> simple_recv.
> All on localhost
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.8.0
>
>
> Node B Assert fail somewhere between 5,000 and 10,000 messages.
> {noformat}
> qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/connections.c:253:
> qdr_connection_process: Assertion `count <= link_work->value' failed.
> {noformat}
> Sender sends 10k, receiver receives 7.2k messages, usually. Reproduces fairly
> easily.
> Node A config:
> {noformat}
> router {
> mode: interior
> id: Router.A
> }
> listener {
> host: 127.0.0.1
> port: 5672
> authenticatePeer: no
> }
> address {
> prefix: q1
> distribution: multicast
> }
> connector {
> name: INTER_ROUTER
> host: 127.0.0.1
> port: 21000
> role: inter-router
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/A.log
> }
> {noformat}
> Node B config:
> {noformat}
> router {
> mode: interior
> id: Router.B
> }
> listener {
> host: 127.0.0.1
> port: 21000
> authenticatePeer: no
> role: inter-router
> }
> listener {
> host: 127.0.0.1
> port: 55672
> authenticatePeer: no
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/B.log
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-742) Assert while passing multicast or presettled anycast msgs across network
[
https://issues.apache.org/jira/browse/DISPATCH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964793#comment-15964793
]
ASF subversion and git services commented on DISPATCH-742:
--
Commit 3c786e14cc2ce316988ae2d7b813ac36332daa20 in qpid-dispatch's branch
refs/heads/master from [~tr...@redhat.com]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3c786e1 ]
DISPATCH-742 - Prevent presettled deliveries from being dropped from a
link-work record that is concurrently being processed by an IO thread.
> Assert while passing multicast or presettled anycast msgs across network
>
>
> Key: DISPATCH-742
> URL: https://issues.apache.org/jira/browse/DISPATCH-742
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.8.0
> Environment: Fedora 25. Two node network. One sender on node A, one
> receiver on node B. Send/recv clients are Proton Cpp simple_send and
> simple_recv.
> All on localhost
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.8.0
>
>
> Node B Assert fail somewhere between 5,000 and 10,000 messages.
> {noformat}
> qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/connections.c:253:
> qdr_connection_process: Assertion `count <= link_work->value' failed.
> {noformat}
> Sender sends 10k, receiver receives 7.2k messages, usually. Reproduces fairly
> easily.
> Node A config:
> {noformat}
> router {
> mode: interior
> id: Router.A
> }
> listener {
> host: 127.0.0.1
> port: 5672
> authenticatePeer: no
> }
> address {
> prefix: q1
> distribution: multicast
> }
> connector {
> name: INTER_ROUTER
> host: 127.0.0.1
> port: 21000
> role: inter-router
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/A.log
> }
> {noformat}
> Node B config:
> {noformat}
> router {
> mode: interior
> id: Router.B
> }
> listener {
> host: 127.0.0.1
> port: 21000
> authenticatePeer: no
> role: inter-router
> }
> listener {
> host: 127.0.0.1
> port: 55672
> authenticatePeer: no
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/B.log
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-742) Assert while passing multicast or presettled anycast msgs across network
[
https://issues.apache.org/jira/browse/DISPATCH-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-742:
--
Fix Version/s: 0.8.0
> Assert while passing multicast or presettled anycast msgs across network
>
>
> Key: DISPATCH-742
> URL: https://issues.apache.org/jira/browse/DISPATCH-742
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.8.0
> Environment: Fedora 25. Two node network. One sender on node A, one
> receiver on node B. Send/recv clients are Proton Cpp simple_send and
> simple_recv.
> All on localhost
>Reporter: Chuck Rolke
>Assignee: Ted Ross
> Fix For: 0.8.0
>
>
> Node B Assert fail somewhere between 5,000 and 10,000 messages.
> {noformat}
> qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/connections.c:253:
> qdr_connection_process: Assertion `count <= link_work->value' failed.
> {noformat}
> Sender sends 10k, receiver receives 7.2k messages, usually. Reproduces fairly
> easily.
> Node A config:
> {noformat}
> router {
> mode: interior
> id: Router.A
> }
> listener {
> host: 127.0.0.1
> port: 5672
> authenticatePeer: no
> }
> address {
> prefix: q1
> distribution: multicast
> }
> connector {
> name: INTER_ROUTER
> host: 127.0.0.1
> port: 21000
> role: inter-router
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/A.log
> }
> {noformat}
> Node B config:
> {noformat}
> router {
> mode: interior
> id: Router.B
> }
> listener {
> host: 127.0.0.1
> port: 21000
> authenticatePeer: no
> role: inter-router
> }
> listener {
> host: 127.0.0.1
> port: 55672
> authenticatePeer: no
> }
> log {
> module: DEFAULT
> enable: info+
> output:
> /home/chug/Research/qdr/message-copy/gen-test-network/2017-04-10_11-41-17_2/B.log
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1408) long-lived connections suffer large performance hit after many messages
[ https://issues.apache.org/jira/browse/PROTON-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish closed PROTON-1408. --- Resolution: Fixed Fix Version/s: 0.18.0 Fixed with checkin d22f124b0534983f6557850e48f13317ec6df0e5 > long-lived connections suffer large performance hit after many messages > --- > > Key: PROTON-1408 > URL: https://issues.apache.org/jira/browse/PROTON-1408 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: michael goulish >Assignee: michael goulish > Fix For: 0.18.0 > > Attachments: jira_proton_1408_reproducer.tar.gz > > > In long-running soak tests, in which connections are never taken down, I am > seeing a sudden & severe performance degradation when the number of messages > over the connection reaches about 6.4 billion. > This is happening in tests with two senders, two receivers & one router > intermediating. > I have tried C libUV clients as well as CPP clients. Behavior is not > identical, but I see sudden performance drop, ie. 8x throughput decrease or > worse, in both cases. > Alan / Ted / Ken see an issue in use of improper comparison logic in > pn_do_disposition(), in transport.c . I am trying to prove this now. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4620) Initial selector implementation
[ https://issues.apache.org/jira/browse/QPID-4620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964070#comment-15964070 ] Alojzij Blatnik commented on QPID-4620: --- Hi. Could you please write a sample how to receive messages from queue so that they get filtered using correlationID. I'm trying to get those revisions, but svn http://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/ doesn't exist anymore, neither https://etp.108.redhat.com/svn/etp/trunk/blaze does (base of migration into git) and it's very hard to find related git commits from history. I wrote a full question here http://stackoverflow.com/questions/43249230/qpid-receive-message-by-correlation-id-using-c-application Thanks. > Initial selector implementation > --- > > Key: QPID-4620 > URL: https://issues.apache.org/jira/browse/QPID-4620 > Project: Qpid > Issue Type: Sub-task > Components: C++ Broker, C++ Client >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.21 > > > This includes all the new files and code "infrastructure" to supports > selectors in the C++ messaging client and broker (see QPID-4558 for details) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7741) [Java Broker] In AMQP 1.0 gracefully handle non-compliant performatives
[
https://issues.apache.org/jira/browse/QPID-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963997#comment-15963997
]
Lorenz Quack commented on QPID-7741:
One idea is to mark mandatory fields with annotations and then process those
annotations automatically on decoding and in case of failure throw a
{{AmqpError.DECODE_ERROR}}.
Furthermore, it might be advantagous to not enforce this in the encoding path
as to make testing of these conditions easier.
> [Java Broker] In AMQP 1.0 gracefully handle non-compliant performatives
> ---
>
> Key: QPID-7741
> URL: https://issues.apache.org/jira/browse/QPID-7741
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the amqp 1.0 codec does not enforce mandatory fields. Often this
> causes problems later in the code like {{NullPointerExceptions}}
> One example is when sending an empty Begin without any of the mandatory
> fields:
> {noformat}
> 2017-04-07 14:46:55,804 DEBUG [IO-/127.0.0.1:39032] (o.a.q.s.p.frame) -
> RECV[/127.0.0.1:39032|37] : Begin{}
> 2017-04-07 14:46:55,805 WARN [IO-/127.0.0.1:39032]
> (o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.(Session_1_0.java:182)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveBegin(AMQPConnection_1_0Impl.java:622)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Begin.invoke(Begin.java:224)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:318)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:167)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$9.run(AMQPConnection_1_0Impl.java:1195)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1168)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:129)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:592)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:482)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:269)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
> 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:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2017-04-07 14:46:55,808 DEBUG [IO-/127.0.0.1:39032] (o.a.q.s.p.frame) -
> SEND[/127.0.0.1:39032|0] :
> Close{error=Error{condition=connection-forced,description=java.lang.NullPointerException}}
> {noformat}
> The correct behaviour would be to close the connection with a {{decode-error}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
