[jira] [Commented] (QPID-7155) [Java Broker] Idle timeout ticker times out connection before heartbeating is negotiated
[
https://issues.apache.org/jira/browse/QPID-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203544#comment-15203544
]
Keith Wall commented on QPID-7155:
--
The ServerIdleReadTimeoutTicker requires that the peer produces bytes. If it
receives nothing then it is required to close the connection. The issue here
is that the broker/client have not yet negotiated heartbeating so the peer
(client) is entitled to let the line fall silent. I think it is unreasonable
for the Broker to have the ServerIdleReadTimeoutTicker installed before
connection tune has agreed the heartbeat parameters.
I think we should have a ticker dedicated to ensuring peers send a protocol
header in a timely manner, then we should rely solely on the
{{SlowConnectionOpenTicker}} to ensure that the connection becomes open with a
second timely period.
> [Java Broker] Idle timeout ticker times out connection before heartbeating is
> negotiated
>
>
> Key: QPID-7155
> URL: https://issues.apache.org/jira/browse/QPID-7155
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Attachments:
> TEST-org.apache.qpid.client.failover.MultipleBrokersFailoverTest.testFailoverOnBrokerStop.txt
>
>
> Recently, {{MultipleBrokersFailoverTest#testFailoverOnBrokerStop}} failed.
> Log attached.
> Analysis has shown the following sequence of events:
> * 01:58:24,044 broker receives connectionStartOk
> * 01:58:25,894 broker sends connectionSecure
> * 01:58:26,010 broker times out the connection
> * 01:58:26,061 client tries to send connectionSecureOk
> The problem seems to be that the ServerIdleReadTimeoutTicker times out the
> connection even though the broker is the one being slow and heartbeating not
> being negotiated yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7156) Possible Java Broker crash if connection is formed whilst virtualhost is stopping
[
https://issues.apache.org/jira/browse/QPID-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203539#comment-15203539
]
Keith Wall commented on QPID-7156:
--
I think {{AbstractVirtualHost#registerConnectionAsync()}} needs to ensure the
state of virtualhost is ACTIVE before registering the connection/assigning the
new scheduler. If the virtualhost is already in an non-ACTIVE state, the
method should close the connection (closeAsync) and return its future. This is
thread safe because all model operations on the virtualhost (including the
registering of connections and the stopping of the virtualhost) take place on
the single vhost executor thread. We need a supporting system test too.
> Possible Java Broker crash if connection is formed whilst virtualhost is
> stopping
> -
>
> Key: QPID-7156
> URL: https://issues.apache.org/jira/browse/QPID-7156
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
> Fix For: qpid-java-6.0.2, qpid-java-6.1
>
>
> As reported here:
> http://qpid.2158936.n2.nabble.com/Java-broker-crashes-after-stopping-vhost-td7640284.html
> A race condition leads to the possibility of a NPE if the virtualhost is
> stopped as a new connection is formed. In the unlucky case, the task to
> associate the connection with the virtualhost gets executed after the virtual
> host's network connection scheduler is shutdown. This leads to a NPE. The
> Broker detects the NPE and shuts itself down.
> {noformat}
> 2016-03-18 06:41:06,748 ERROR [IO-/172.24.102.24:51029] (o.a.q.s.Main) -
> Uncaught exception, shutting down.
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:142)
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:505)
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:338)
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:463)
> ~[qpid-broker-core-6.0.1.jar:6.0.1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) ~[na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_51]
> "
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7156) Possible Java Broker crash if connection is formed whilst virtualhost is stopping
Keith Wall created QPID-7156:
Summary: Possible Java Broker crash if connection is formed whilst
virtualhost is stopping
Key: QPID-7156
URL: https://issues.apache.org/jira/browse/QPID-7156
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-6.0.1, qpid-java-6.0
Reporter: Keith Wall
Fix For: qpid-java-6.0.2, qpid-java-6.1
As reported here:
http://qpid.2158936.n2.nabble.com/Java-broker-crashes-after-stopping-vhost-td7640284.html
A race condition leads to the possibility of a NPE if the virtualhost is
stopped as a new connection is formed. In the unlucky case, the task to
associate the connection with the virtualhost gets executed after the virtual
host's network connection scheduler is shutdown. This leads to a NPE. The
Broker detects the NPE and shuts itself down.
{noformat}
2016-03-18 06:41:06,748 ERROR [IO-/172.24.102.24:51029] (o.a.q.s.Main) -
Uncaught exception, shutting down.
java.lang.NullPointerException: null
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:142)
~[qpid-broker-core-6.0.1.jar:6.0.1]
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:505)
~[qpid-broker-core-6.0.1.jar:6.0.1]
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:338)
~[qpid-broker-core-6.0.1.jar:6.0.1]
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:87)
~[qpid-broker-core-6.0.1.jar:6.0.1]
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:463)
~[qpid-broker-core-6.0.1.jar:6.0.1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) ~[na:1.8.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) ~[na:1.8.0_51]
at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_51]
"
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15197250#comment-15197250
]
Timothy Bish commented on QPIDJMS-154:
--
Great, just glad it's all working now.
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Fix For: 0.9.0
>
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsSessionInfo {} (2)
> {code}
> *_Test code:_*
> {code:java}
> @Test
> public void testScalability
Re: Review Request 44967: Add operator<< to proton::byte_array (and hence to decimal32, decimal64 and decimal128)
> On March 17, 2016, 7:28 p.m., Alan Conway wrote: > > This overlaps a bit with some changes I made in my last commit. I rebased > > onto the latest master and made minor changes: > > - hide implementation of ostream<< op in .cpp file > > - consistent ostream ops in uuid, binary and byte_array: > > - all use of ios_guard to restore state flags > > - all use new printable_byte() function to convert a signed/unsigned char > > value to an unsigned, single-byte integer. > > The current branch is good go go: > > 43cebe1 PROTON-1159: Some improvements for qpid-interop-test: Added > > operator<<() to byte_array and decimal classes. Fixed UUID print bug. I rebased your branch, sorry that was rude. You'll need to `git pull -f kvdr-PROTON-1159` to update your local replica. - Alan --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44967/#review124081 --- On March 17, 2016, 5:34 p.m., Kim van der Riet wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44967/ > --- > > (Updated March 17, 2016, 5:34 p.m.) > > > Review request for qpid and Alan Conway. > > > Bugs: PROTON-1159 > https://issues.apache.org/jira/browse/PROTON-1159 > > > Repository: qpid-proton-git > > > Description > --- > > proton::byte_array currently has no method to stream values. To help with > qpid-interop-test, a basic version of operator<<() which returns a hex > representation of the byte array in the format "0xNN" of the appropriate > length is suggested. The decimal classes use "decimalXX(0x)" as their > format. > > An bug in proton::uuid::operator<<() is also presented in which bytes > 0x80 > within the UUID sequence (negative char values) print as ffnn rather than > nn. > > > Diffs > - > > proton-c/bindings/cpp/include/proton/byte_array.hpp fe3f864 > proton-c/bindings/cpp/src/decimal.cpp 93fe84c > proton-c/bindings/cpp/src/uuid.cpp f224df7 > > Diff: https://reviews.apache.org/r/44967/diff/ > > > Testing > --- > > Works as expected in qpid-interop-test. > > > Thanks, > > Kim van der Riet > >
[jira] [Commented] (DISPATCH-240) qdstat : leading "/" character effects a wrong showed address
[ https://issues.apache.org/jira/browse/DISPATCH-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200381#comment-15200381 ] Ganesh Murthy commented on DISPATCH-240: I verified that this issue was fixed by tross in the tross-DISPATCH-179-1 branch. This fix will be available on master once the merge is complete. We will come back to this issue and verify that it is fixed post-merge. Keep this issue open until then. > qdstat : leading "/" character effects a wrong showed address > - > > Key: DISPATCH-240 > URL: https://issues.apache.org/jira/browse/DISPATCH-240 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.5 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.6 > > > Hello, > it seems that the qdstat tool has some problem with leading "/" character. > If we connect to an address like "/multicast/" it's showed like "ulticast"; > instead removing the leading "/" the name is showed correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7152) [Java Broker, Documentation] Add documentation for OAuth2 authentication
Lorenz Quack created QPID-7152:
--
Summary: [Java Broker, Documentation] Add documentation for OAuth2
authentication
Key: QPID-7152
URL: https://issues.apache.org/jira/browse/QPID-7152
Project: Qpid
Issue Type: Improvement
Components: Documentation, Java Broker
Reporter: Lorenz Quack
We currently do not have documentation covering the OAuth2 Authentication- and
GroupProviders.
We do not need huge amounts of documentation and we certainly do not want to
explain how OAuth2 works but it should be mentioned and some more specific
things (e.g., the {{serviceToManagementGroupMapping}}) should be explained.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7155) [Java Broker] Idle timeout ticker times out connection before heartbeating is negotiated
Lorenz Quack created QPID-7155:
--
Summary: [Java Broker] Idle timeout ticker times out connection
before heartbeating is negotiated
Key: QPID-7155
URL: https://issues.apache.org/jira/browse/QPID-7155
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Lorenz Quack
Recently, {{MultipleBrokersFailoverTest#testFailoverOnBrokerStop}} failed. Log
attached.
Analysis has shown the following sequence of events:
* 01:58:24,044 broker receives connectionStartOk
* 01:58:25,894 broker sends connectionSecure
* 01:58:26,010 broker times out the connection
* 01:58:26,061 client tries to send connectionSecureOk
The problem seems to be that the ServerIdleReadTimeoutTicker times out the
connection even though the broker is the one being slow and heartbeating not
being negotiated yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7153) Allow expired messages to be sent to DLQ
Keith Wall created QPID-7153: Summary: Allow expired messages to be sent to DLQ Key: QPID-7153 URL: https://issues.apache.org/jira/browse/QPID-7153 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Currently the Java Broker simply discards messages that expire (TLL). The behaviour should be configurable and allow for expired messages to be directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-241) Bias "spread" config with leading "/" on address has a "multicast" behavior
[
https://issues.apache.org/jira/browse/DISPATCH-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-241:
--
Fix Version/s: 0.6
> Bias "spread" config with leading "/" on address has a "multicast" behavior
> ---
>
> Key: DISPATCH-241
> URL: https://issues.apache.org/jira/browse/DISPATCH-241
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Paolo Patierno
> Fix For: 0.6
>
>
> I have following config :
> fixedAddress {
> prefix: /spread/
> fanout: single
> bias: spread
> }
> - fanout: single means that only one consumer will receive a message
> published on /spread/ address (in a competing consumers fashion)
> - bias: spread means that the router sends message to only one consumer but
> as documentation says "in an approximately even manner". It sounds to me that
> the router tracks the consumers which receive message on that address and for
> a new message tries to send it to another consumer.
> The problem is following :
> if more consumers attach to "spread/" all works fine (only one of them
> receives message) but if they attach to "/spread/" (with leading "/") then
> all consumers receive the message like a "multicast" configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
