[jira] [Commented] (QPID-8158) [Broker-J] [System Tests] Refactor BDB HA system tests
[
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436404#comment-16436404
]
ASF subversion and git services commented on QPID-8158:
---
Commit b91ddb20ecd3b3178072ef39c08f47cf5ceb7e29 in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b91ddb2 ]
QPID-8158: [Broker-J] [System Tests] Run protocol tests as part of unit tests
> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They
> need to be refactored to run with {{QpidTestRunner}} similar to other system
> tests.
> The BDB HA nodes should be started as spawn brokers using special
> {{BrokerAdmin}} allowing to start broker in a separate JVM.
--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests
[
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436403#comment-16436403
]
ASF subversion and git services commented on QPID-8158:
---
Commit 5b756ecfe4fb9ac5ecd83960b1e033214775025e in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=5b756ec ]
QPID-8158: [Broker-J] [System Tests] Initialize group members before each tetst
> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They
> need to be refactored to run with {{QpidTestRunner}} similar to other system
> tests.
> The BDB HA nodes should be started as spawn brokers using special
> {{BrokerAdmin}} allowing to start broker in a separate JVM.
--
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-1771) [c-proactor] multi-thread race test for proactor
[ https://issues.apache.org/jira/browse/PROTON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436289#comment-16436289 ] ASF subversion and git services commented on PROTON-1771: - Commit 3e2f9b5f8164a6720740b49b72af6471b1081df9 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3e2f9b5 ] PROTON-1771: [c] add missing lock around wake_if_inactive Fixes a race condition discovered by threaderciser.c > [c-proactor] multi-thread race test for proactor > > > Key: PROTON-1771 > URL: https://issues.apache.org/jira/browse/PROTON-1771 > Project: Qpid Proton > Issue Type: Test > Components: proton-c >Affects Versions: proton-c-0.20.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > Crate a new test exe that runs for a (configurable, default short) period of > time, with a single proactor acted on by multiple proactor and user threads. > Run > with helgrind or tsan to detect races. > Exercise potentially racy APIs concurrently: > - making, accepting and closing (from both ends) a connection. > - pn_connection_wake > - pn_proactor_release_connection > - re-use of released pn_connection_t on a new connection > - timeout > - concurrent with some normal use: sending/receiving messages. -- 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-1771) [c-proactor] multi-thread race test for proactor
[ https://issues.apache.org/jira/browse/PROTON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436290#comment-16436290 ] ASF subversion and git services commented on PROTON-1771: - Commit 188ce28066df8f5e965fb63593f419f49c950760 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=188ce28 ] PROTON-1771: [c] locking around epoll_extended_t Add locking for epoll_extended_t structure to fix race conditions revealed by threaderciser.c We pass pointers to this struct between threads via epoll, and epoll does not guarantee that memory writes by one thread will be visible in the next thread that gets the pointer. Since helgrind reports the races, it suggests that epoll is not acting as a memory barrier in practice either. These mutexes will not be contended so they are not expensive. We could use an acquire/release memory barrier, but an un-contended mutex is basically exactly that, and is portable. > [c-proactor] multi-thread race test for proactor > > > Key: PROTON-1771 > URL: https://issues.apache.org/jira/browse/PROTON-1771 > Project: Qpid Proton > Issue Type: Test > Components: proton-c >Affects Versions: proton-c-0.20.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > Crate a new test exe that runs for a (configurable, default short) period of > time, with a single proactor acted on by multiple proactor and user threads. > Run > with helgrind or tsan to detect races. > Exercise potentially racy APIs concurrently: > - making, accepting and closing (from both ends) a connection. > - pn_connection_wake > - pn_proactor_release_connection > - re-use of released pn_connection_t on a new connection > - timeout > - concurrent with some normal use: sending/receiving messages. -- 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-1771) [c-proactor] multi-thread race test for proactor
[ https://issues.apache.org/jira/browse/PROTON-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436288#comment-16436288 ] ASF subversion and git services commented on PROTON-1771: - Commit 8a4fac69fa8442351bb763c4835fc706a273 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8a4fac6 ] PROTON-1771: [c] threaderciser thread race test for C proactor Take random actions in multiple threads, try to provoke race conditions under helgrind or other race checker. Actions can be enabled or disabled on command line to simplify the test. threaderciser.supp has supressions for race conditions detected on Linux with the epoll proactor. > [c-proactor] multi-thread race test for proactor > > > Key: PROTON-1771 > URL: https://issues.apache.org/jira/browse/PROTON-1771 > Project: Qpid Proton > Issue Type: Test > Components: proton-c >Affects Versions: proton-c-0.20.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > Crate a new test exe that runs for a (configurable, default short) period of > time, with a single proactor acted on by multiple proactor and user threads. > Run > with helgrind or tsan to detect races. > Exercise potentially racy APIs concurrently: > - making, accepting and closing (from both ends) a connection. > - pn_connection_wake > - pn_proactor_release_connection > - re-use of released pn_connection_t on a new connection > - timeout > - concurrent with some normal use: sending/receiving messages. -- 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-967) Policy management interface does not forward log warning messages
Chuck Rolke created DISPATCH-967: Summary: Policy management interface does not forward log warning messages Key: DISPATCH-967 URL: https://issues.apache.org/jira/browse/DISPATCH-967 Project: Qpid Dispatch Issue Type: Bug Components: Policy Engine Affects Versions: 1.0.1 Reporter: Chuck Rolke Assignee: Chuck Rolke Some user policies may generate warnings. However, the warnings are unable to be forwarded out of python code to the log code proper because the policy manager does not have an interface to forward warnings. -- 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-957) Unbalanced memory consumption in a 2 routers configuration and specific workload
[ https://issues.apache.org/jira/browse/DISPATCH-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436103#comment-16436103 ] Ken Giusti commented on DISPATCH-957: - Hi Matthieu, I've hacked extra log messages into a branch off of 1.0.1 and pushed it up to my github repo: https://github.com/kgiusti/dispatch/tree/DISPATCH-957-DEBUG This should log qdr_link_t allocations and deallocations. If you can run this under your environment to reproduce the memory growth and send me the resulting router logs I'll see if I can root cause this. thanks > Unbalanced memory consumption in a 2 routers configuration and specific > workload > > > Key: DISPATCH-957 > URL: https://issues.apache.org/jira/browse/DISPATCH-957 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.0.1 > Environment: * At the time I was experimenting, I built the router > from the source and > used 22400df dockerized. It's available in docker hub : > msimonin/qdrouterd:22400df or msimonin/qdrouterd-collectd:22400f > > * ombt version used embeds the following library > oslo.messaging==5.35.0 > pyngus==2.2.2 > python-qpid-proton==0.19.0 > > * I used ombt-orchestrator to deploy all the stack using the g5k provider > (see > https://github.com/msimonin/ombt-orchestrator/) In a local machine setup, > vagrant provider can be used but I'm not sure if it is reasonnable to scale > the > above number of agents. I've attached nevertheless the configuration used. > > * Host Linux distribution is debian9 > > >Reporter: Matthieu Simonin >Assignee: Ken Giusti >Priority: Major > Attachments: call.png, cast.png, conf.yaml, inc-calls.png, > mem_usage.tar.gz > > > After discussion with Ken Giusti we deem appropriate to fill a bug to track > the > following behavior. > Note also that the exact version used in the following description isn't > exactly 1.1.0 but one built from source 22400df (master back in february). > I started two interconnected routers (router0 and router1) > router0 is where all my consumers connect router1 is where all my producers > connect . > The workload is an RPC test using oslo.messaging library using calls > (resp. casts) : clients keep sending message and block for the response > (resp. do not block). > I've attached some observations: > 1) > With 100 consumers and 100 producers and calls I observe a higher memory > consumption of router0 in comparison of the memory consumption of router1 (see > calls.png). Casts seem to less affect the router memory. Calls usually > requires > more ressources because of the return values flowing back to the producer but > I wouldn't expect this big difference. > I've attached a tgz in which, you'll find the results of qdtsat -a,-m,-l > * before the benchmark (start) > * early during the benchmark (during) > * late during the benchmark (during-1) > * after the benchmark completed (after) > 2) I've run a second test increasing incrementaly the (#clients, #servers) : > [50, 100, 200, 500] (calls only) > see inc-calls.png > in this case the difference of the memory consumption between router0 and > router1 is [50MB, 100MB, 300MB, 1.5GB] -- 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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests
[
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435905#comment-16435905
]
ASF subversion and git services commented on QPID-8158:
---
Commit 4c89667b1d83a1cac022c86885cc6f806862afcc in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4c89667 ]
QPID-8158: [Broker-J] [System Tests] Skip running non-protocol integration
tests by default
> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They
> need to be refactored to run with {{QpidTestRunner}} similar to other system
> tests.
> The BDB HA nodes should be started as spawn brokers using special
> {{BrokerAdmin}} allowing to start broker in a separate JVM.
--
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-8163) [Broker-J] [ACL] Owner ACL rules
[
https://issues.apache.org/jira/browse/QPID-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8163:
-
Attachment: 0001-QPID-8163.patch
> [Broker-J] [ACL] Owner ACL rules
>
>
> Key: QPID-8163
> URL: https://issues.apache.org/jira/browse/QPID-8163
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Attachments: 0001-QPID-8163.patch
>
>
> [http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
> The Broker-J's access-control-plugin currently has no way to express rules
> that apply to subject that owns an object. For instance, it is impossible to
> say that only a user can consume from any queue that he created.
> If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
> pseudo subject {{ALL}} it already supports), then it would be possible to
> write such rules.
> {noformat}
> ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
> It is noted that currently the model does not a have notion of object
> ownership (QPID-8162). It does have an immutable {{createdBy}} attribute.
> The first version of this feature will use {{createdBy}}.
--
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] [Assigned] (QPID-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access
[
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-8160:
Assignee: Keith Wall
> [Broker-J] [AMQP 1.0] AccessControlException when creating sending link
> reported as amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.0,
> qpid-java-broker-7.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> If the Broker tries to create a sending link from a source but the user has
> insufficient permissions for that source, I expect the {{detach}} to use
> error {{amqp:unauthorised-access}}. This currently does not happen, the
> Broker sends {{amqp:amqp:internal-error}} instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true,
> error=Error{condition=amqp:internal-error, description='Permission CREATE is
> denied for : Consumer
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
> on Queue 'guestqueue'', info=null}}{noformat}
>
--
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-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access
[
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8160:
-
Fix Version/s: qpid-java-broker-7.1.0
> [Broker-J] [AMQP 1.0] AccessControlException when creating sending link
> reported as amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.0,
> qpid-java-broker-7.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> If the Broker tries to create a sending link from a source but the user has
> insufficient permissions for that source, I expect the {{detach}} to use
> error {{amqp:unauthorised-access}}. This currently does not happen, the
> Broker sends {{amqp:amqp:internal-error}} instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true,
> error=Error{condition=amqp:internal-error, description='Permission CREATE is
> denied for : Consumer
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
> on Queue 'guestqueue'', info=null}}{noformat}
>
--
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-8160) [Broker-J] [AMQP 1.0] AccessControlException when creating sending link reported as amqp:internal-error rather than amqp:unauthorised-access
[
https://issues.apache.org/jira/browse/QPID-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8160:
-
Affects Version/s: qpid-java-broker-7.0.3
qpid-java-broker-7.0.0
> [Broker-J] [AMQP 1.0] AccessControlException when creating sending link
> reported as amqp:internal-error rather than amqp:unauthorised-access
> --
>
> Key: QPID-8160
> URL: https://issues.apache.org/jira/browse/QPID-8160
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.0,
> qpid-java-broker-7.1
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> If the Broker tries to create a sending link from a source but the user has
> insufficient permissions for that source, I expect the {{detach}} to use
> error {{amqp:unauthorised-access}}. This currently does not happen, the
> Broker sends {{amqp:amqp:internal-error}} instead.
> {noformat}
> [511142734:1] <- Detach{handle=1, closed=true,
> error=Error{condition=amqp:internal-error, description='Permission CREATE is
> denied for : Consumer
> '4|1|qpid-jms:receiver:ID:2a653090-1dbc-4433-955d-791b52540128:1:1:1:guestqueue'
> on Queue 'guestqueue'', info=null}}{noformat}
>
--
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-8164) [Broker-J] [AMQP 1.0] [BINDMAP] Dynamic nodes created with the temporary-queue capability do not enforce connection exclusivity
[
https://issues.apache.org/jira/browse/QPID-8164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8164:
-
Summary: [Broker-J] [AMQP 1.0] [BINDMAP] Dynamic nodes created with the
temporary-queue capability do not enforce connection exclusivity (was:
[Broker-J] [AMQP 1.0] [BINDMAP] temporary-queue do not enforce connection
exclusivity)
> [Broker-J] [AMQP 1.0] [BINDMAP] Dynamic nodes created with the
> temporary-queue capability do not enforce connection exclusivity
> ---
>
> Key: QPID-8164
> URL: https://issues.apache.org/jira/browse/QPID-8164
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The JMS 2.0 specification, 6.2.2 Creating temporary destinations, says:
> {quote}Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
> destinations that are system-generated uniquely for their connection. Only
> their own connection is allowed to create consumer objects for them.
> {quote}
> Currently when the Qpid JMS Client is used with Broker-J, the last sentence
> whilst being enforced by the client is not enforced by the *Broker*. This
> means that if the temporary destination were to be passed to another party -
> say as a JMSReplyTo, that client would be able to create a consumer,
> violating the JMS specification.
> I think Broker-J ought to be detecting the terminus capability
> {{temporary-queue}} specified by amqp-bindmap-jms-v1.0-wd09 and then applying
> the correct queue exclusivity policy.
> I think the same problem may apply to the temporary-topics too (but not
> confirmed)
>
>
--
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-8164) [Broker-J] [AMQP 1.0] [BINDMAP] temporary-queue do not enforce connection exclusivity
Keith Wall created QPID-8164:
Summary: [Broker-J] [AMQP 1.0] [BINDMAP] temporary-queue do not
enforce connection exclusivity
Key: QPID-8164
URL: https://issues.apache.org/jira/browse/QPID-8164
Project: Qpid
Issue Type: Bug
Components: Broker-J
Reporter: Keith Wall
The JMS 2.0 specification, 6.2.2 Creating temporary destinations, says:
{quote}Temporary destinations (TemporaryQueue or TemporaryTopic objects) are
destinations that are system-generated uniquely for their connection. Only
their own connection is allowed to create consumer objects for them.
{quote}
Currently when the Qpid JMS Client is used with Broker-J, the last sentence
whilst being enforced by the client is not enforced by the *Broker*. This
means that if the temporary destination were to be passed to another party -
say as a JMSReplyTo, that client would be able to create a consumer, violating
the JMS specification.
I think Broker-J ought to be detecting the terminus capability
{{temporary-queue}} specified by amqp-bindmap-jms-v1.0-wd09 and then applying
the correct queue exclusivity policy.
I think the same problem may apply to the temporary-topics too (but not
confirmed)
--
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-8158) [Broker-J] [System Tests] Refactor BDB HA system tests
[
https://issues.apache.org/jira/browse/QPID-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435804#comment-16435804
]
ASF subversion and git services commented on QPID-8158:
---
Commit 54bc670f0dfa01980f823dbe009f70d1c15b0bd7 in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=54bc670 ]
QPID-8158: [Broker-J] [System Tests] Clean-up maven building scripts
> [Broker-J] [System Tests] Refactor BDB HA system tests
> --
>
> Key: QPID-8158
> URL: https://issues.apache.org/jira/browse/QPID-8158
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>Priority: Major
>
> Currently BDB HA system tests are extended from {{QpidBrokerTestCase}}. They
> need to be refactored to run with {{QpidTestRunner}} similar to other system
> tests.
> The BDB HA nodes should be started as spawn brokers using special
> {{BrokerAdmin}} allowing to start broker in a separate JVM.
--
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] (PROTON-1827) [c test] c-connection-driver-tests fail on windows
Chuck Rolke created PROTON-1827:
---
Summary: [c test] c-connection-driver-tests fail on windows
Key: PROTON-1827
URL: https://issues.apache.org/jira/browse/PROTON-1827
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.23.0
Reporter: Chuck Rolke
A new self test related to PROTON-1809 fails hard.
{{10: ..\..\..\c\tests\connection_driver.c:438: check failed: 'session capacity
1234 is less than frame size 12345' not in 'session capacity 1234 is less than
frame size 140707423596601 (connection aborted)'
[test_session_flow_control()]}}
{{ 10: FAIL: test_session_flow_control() (1 errors)}}
{{ 10/27 Test #10: c-connection-driver-tests ***Failed 0.08 sec}}
The large frame size number varies from run to run but is always in the region
of 10^14.
--
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-1672) Large deliveries comprising many transfers are handled inefficiently
[
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435735#comment-16435735
]
ASF subversion and git services commented on PROTON-1672:
-
Commit 1c62bc2845c336f5b061509a959b699a45344474 in qpid-proton-j's branch
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=1c62bc2 ]
PROTON-1672: replace use of Java 8+ constants in tests
> Large deliveries comprising many transfers are handled inefficiently
>
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0)
> shows that receipt of large messages is very slow in comparison with the send
> of the same message. For instance, sending 300MiB bytes message takes 5
> seconds on my laptop. The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}}
> re-allocates/array copies the entire delivery buffer for ever transfer that
> comprises it. This leads to a non-linear loss of performance. The stack
> include Proton-J 0.23.0, but is looks like this code is unchanged.
--
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-966) Qpid dispatch unstable inter-router connections
[
https://issues.apache.org/jira/browse/DISPATCH-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435640#comment-16435640
]
Ted Ross commented on DISPATCH-966:
---
Can you try a workaround?
Please add:
allowUnsettledMulticast: yes
to the router section of your configuration.
I suspect that this may mask the (very real) issue that is causing this problem.
-Ted
> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Major
> Attachments: qdrouterd.conf, qdrouterd.log, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1
> attached clients and I am seeing some unstable inter-router connections (I am
> sending around 1000 small, less than 1K, messages per second through the
> network). The inter-router connections fail every so many seconds with the
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time
> before the inter router connection is dropped, therw is a rejected
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
> * router-0 -> router-1
> * router-0 -> router-2
> * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google
> compute engine machines (every router on a separate node).
> Attached are:
> * my qdrouter.conf (from one of the routers)
> * a log snippet from router-0 at debug level from connection drop to
> connection re-established to connection drop again.
> * a tcpdump capture of the inter-router connection between router-0 and
> router-1 during which several of the failures occur
> Versions:
> * qpid-dispatch@1.0.1-rc1
> * qpid-proton@0.20.0
>
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]
--
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-1672) Large deliveries comprising many transfers are handled inefficiently
[
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435622#comment-16435622
]
ASF subversion and git services commented on PROTON-1672:
-
Commit 18d2cb369a6d906b2cf8403184c7e35cd00ae7c0 in qpid-proton-j's branch
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=18d2cb3 ]
PROTON-1672: replace use of Java 8+ constants
> Large deliveries comprising many transfers are handled inefficiently
>
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0)
> shows that receipt of large messages is very slow in comparison with the send
> of the same message. For instance, sending 300MiB bytes message takes 5
> seconds on my laptop. The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}}
> re-allocates/array copies the entire delivery buffer for ever transfer that
> comprises it. This leads to a non-linear loss of performance. The stack
> include Proton-J 0.23.0, but is looks like this code is unchanged.
--
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-8163) [Broker-J] [ACL] Owner ACL rules
[
https://issues.apache.org/jira/browse/QPID-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8163:
-
Description:
[http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
The Broker-J's access-control-plugin currently has no way to express rules that
apply to subject that owns an object. For instance, it is impossible to say
that only a user can consume from any queue that he created.
If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
pseudo subject {{ALL}} it already supports), then it would be possible to write
such rules.
{noformat}
ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
It is noted that currently the model does not a have notion of object ownership
(QPID-8162). It does have an immutable {{createdBy}} attribute. The first
version of this feature will use {{createdBy}}.
was:
[http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
The Broker-J's access-control-plugin currently has no way to express rules that
apply to subject that owns an object. For instance, it is impossible to say
that only a user can consume from any queue that he created.
If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
pseudo subject {{ALL}} it already supports), then it would be possible to write
such rules.
{noformat}
ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
It is noted that currently the model does not a have notion of object ownership
(QPID-8162). It does have an immutable {{createdBy}} attribute. The first
version of this feature will use {{createdBy}}.
> [Broker-J] [ACL] Owner ACL rules
>
>
> Key: QPID-8163
> URL: https://issues.apache.org/jira/browse/QPID-8163
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> [http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
> The Broker-J's access-control-plugin currently has no way to express rules
> that apply to subject that owns an object. For instance, it is impossible to
> say that only a user can consume from any queue that he created.
> If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
> pseudo subject {{ALL}} it already supports), then it would be possible to
> write such rules.
> {noformat}
> ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
> It is noted that currently the model does not a have notion of object
> ownership (QPID-8162). It does have an immutable {{createdBy}} attribute.
> The first version of this feature will use {{createdBy}}.
--
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-8163) [Broker-J] [ACL] Owner ACL rules
[
https://issues.apache.org/jira/browse/QPID-8163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8163:
-
Description:
[http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
The Broker-J's access-control-plugin currently has no way to express rules that
apply to subject that owns an object. For instance, it is impossible to say
that only a user can consume from any queue that he created.
If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
pseudo subject {{ALL}} it already supports), then it would be possible to write
such rules.
{noformat}
ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
It is noted that currently the model does not a have notion of object ownership
(QPID-8162). It does have an immutable {{createdBy}} attribute. The first
version of this feature will use {{createdBy}}.
was:
[http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
The Broker-J's access-control-plugin currently has no way to express rules that
apply to subject that owns an object. For instance, it is impossible to say,
only the user who owns a queue can consume from it.
If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
pseudo subject {{ALL}} it already supports), then it would be possible to write
such rules.
{noformat}
ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
It is noted that currently the model does not a have notion of object ownership
(QPID-8162). It does have an immutable {{createdBy}} attribute. The first
version of this feature will use {{createdBy}}.
> [Broker-J] [ACL] Owner ACL rules
>
>
> Key: QPID-8163
> URL: https://issues.apache.org/jira/browse/QPID-8163
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
>
> [http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
> The Broker-J's access-control-plugin currently has no way to express rules
> that apply to subject that owns an object. For instance, it is impossible to
> say that only a user can consume from any queue that he created.
> If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
> pseudo subject {{ALL}} it already supports), then it would be possible to
> write such rules.
> {noformat}
> ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
> It is noted that currently the model does not a have notion of object
> ownership (QPID-8162). It does have an immutable {{createdBy}} attribute.
> The first version of this feature will use {{createdBy}}.
>
>
--
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-8162) [Broker-J] [Model] Configured Object should have a notion of owner
[
https://issues.apache.org/jira/browse/QPID-8162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8162:
-
Description:
Configured objects ought to have an {{owner}} which should be a {{Principal}}.
On configured object creation, the owner should become the principal of the
creating user.
It should also be possible for the owner of an object to reassign the ownership
to to another principal (representing either a user or group). There may be
restrictions: for instance, I may only assign my object to a group that I am
currently a member.
Queues already have {{owner}} which is used for AMQP 0-x queue exclusivity
purposes. Care would need to be taken to avoid colliding with this attribute.
was:
Configured objects ought to have an {{owner}} which should be a {{Principal}}.
On configured object creation, the owner should become the principal of the
creating user.
It should also be possible for the owner of an object to reassign the ownership
to to another principal (representing either a user or group). There may be
restrictions: for instance, I may only assign my object to a group that I am
currently a member.
> [Broker-J] [Model] Configured Object should have a notion of owner
> --
>
> Key: QPID-8162
> URL: https://issues.apache.org/jira/browse/QPID-8162
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: Future
>
>
> Configured objects ought to have an {{owner}} which should be a
> {{Principal}}. On configured object creation, the owner should become the
> principal of the creating user.
> It should also be possible for the owner of an object to reassign the
> ownership to to another principal (representing either a user or group).
> There may be restrictions: for instance, I may only assign my object to a
> group that I am currently a member.
> Queues already have {{owner}} which is used for AMQP 0-x queue exclusivity
> purposes. Care would need to be taken to avoid colliding with this attribute.
>
--
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-8163) [Broker-J] [ACL] Owner ACL rules
Keith Wall created QPID-8163:
Summary: [Broker-J] [ACL] Owner ACL rules
Key: QPID-8163
URL: https://issues.apache.org/jira/browse/QPID-8163
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Keith Wall
[http://qpid.2158936.n2.nabble.com/Java-Broker-Temporary-queues-ACLs-for-multiple-users-td7674630.html]
The Broker-J's access-control-plugin currently has no way to express rules that
apply to subject that owns an object. For instance, it is impossible to say,
only the user who owns a queue can consume from it.
If the ACL system supported a pseudo subject {{OWNER}} (in additional to the
pseudo subject {{ALL}} it already supports), then it would be possible to write
such rules.
{noformat}
ACL ALLOW-LOG OWNER CONSUME QUEUE{noformat}
It is noted that currently the model does not a have notion of object ownership
(QPID-8162). It does have an immutable {{createdBy}} attribute. The first
version of this feature will use {{createdBy}}.
--
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-8162) [Broker-J] [Model] Configured Object should have a notion of owner
Keith Wall created QPID-8162:
Summary: [Broker-J] [Model] Configured Object should have a notion
of owner
Key: QPID-8162
URL: https://issues.apache.org/jira/browse/QPID-8162
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Keith Wall
Fix For: Future
Configured objects ought to have an {{owner}} which should be a {{Principal}}.
On configured object creation, the owner should become the principal of the
creating user.
It should also be possible for the owner of an object to reassign the ownership
to to another principal (representing either a user or group). There may be
restrictions: for instance, I may only assign my object to a group that I am
currently a member.
--
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-962) links established to 'unavailable' addresses are not refused correctly
[
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435523#comment-16435523
]
Robbie Gemmell commented on DISPATCH-962:
-
Thanks Ted. Checked and only the router local terminus gets null'ed now. The
non-null terminus doesnt actually match what the client sent, at least when
creating a producer, but its better than a null and probably ok for now.
> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable
> from DISPATCH-803) the router doesn't refuse the links to it in the manner
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach
> response should contain a null target/source as appropriate, essentially
> indicating to the peer that the detach will follow due to the error,
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
> Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] ->
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <-
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] ->
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <-
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> The links are detached after this, but the non-null
[jira] [Assigned] (DISPATCH-966) Qpid dispatch unstable inter-router connections
[
https://issues.apache.org/jira/browse/DISPATCH-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-966:
-
Assignee: Ted Ross
> Qpid dispatch unstable inter-router connections
> ---
>
> Key: DISPATCH-966
> URL: https://issues.apache.org/jira/browse/DISPATCH-966
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 1.0.1
>Reporter: Marcel Meulemans
>Assignee: Ted Ross
>Priority: Major
> Attachments: qdrouterd.conf, qdrouterd.log, router.dump
>
>
> I am running a three node fully connected mesh of dispatch routers with 1
> attached clients and I am seeing some unstable inter-router connections (I am
> sending around 1000 small, less than 1K, messages per second through the
> network). The inter-router connections fail every so many seconds with the
> message:
> {{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing
> error, expected delivery-id 7, got 6}}
> (the numbers 7 and 6 differ per connection loss)
> In wireshark, using the attached tcpdump capture, I can see that every time
> before the inter router connection is dropped, therw is a rejected
> disposition with the message:
> {{Condition: qd:forbidden}}
> {{Description: Deliveries to a multicast address must be pre-settled}}
> The routers are connected as follows:
> * router-0 -> router-1
> * router-0 -> router-2
> * router-1 -> router-2
> The routers are running as a docker container (debian stretch) on google
> compute engine machines (every router on a separate node).
> Attached are:
> * my qdrouter.conf (from one of the routers)
> * a log snippet from router-0 at debug level from connection drop to
> connection re-established to connection drop again.
> * a tcpdump capture of the inter-router connection between router-0 and
> router-1 during which several of the failures occur
> Versions:
> * qpid-dispatch@1.0.1-rc1
> * qpid-proton@0.20.0
>
> [^qdrouterd.log]
> [^qdrouterd.conf]
> [^router.dump]
--
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-962) links established to 'unavailable' addresses are not refused correctly
[
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435428#comment-16435428
]
ASF subversion and git services commented on DISPATCH-962:
--
Commit 3ce8f4b626f550aa84f53fc12239e2bd50001f60 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=3ce8f4b ]
DISPATCH-962 - Only nullify the terminus that is on the router's side of the
link when a link is rejected.
> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable
> from DISPATCH-803) the router doesn't refuse the links to it in the manner
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach
> response should contain a null target/source as appropriate, essentially
> indicating to the peer that the detach will follow due to the error,
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
> Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] ->
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <-
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] ->
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <-
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null,
[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly
[
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435424#comment-16435424
]
Ted Ross commented on DISPATCH-962:
---
Good point [~gemmellr], I'll make that change.
> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable
> from DISPATCH-803) the router doesn't refuse the links to it in the manner
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach
> response should contain a null target/source as appropriate, essentially
> indicating to the peer that the detach will follow due to the error,
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
> Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] ->
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <-
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] ->
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> amqp:modified:list], capabilities=[queue]}, target=Target{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [59324032:1] <-
> Attach{name='qpid-jms:receiver:ID:30b1b1c9-316b-4be1-9944-15b5822a6500:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> The links are detached after this, but the non-null terminus removes the hint
> to the peer that it is coming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To
[jira] [Commented] (QPID-8161) [Broker-J] [BDB] Broker failed due to lock timeout exception on MESSAGE_METADATA_SEQ
[
https://issues.apache.org/jira/browse/QPID-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435350#comment-16435350
]
Keith Wall commented on QPID-8161:
--
In the case of this problem, the Broker had been up for two hours before the
failure occurred, and had successfully established many AMQP 0-x messaging
connection. I conclude from that the {{MESSAGE_METADATA_SEQ}} sequence must
have been initialised and placed in the CHM. The message store only ever uses
a single sequence value, and this sequence is created and cached on first use,
and then the same sequence value remains in use until the store is closed. In
this case, there is no evidence that the Broker or Virtualhost was being
closed, so I cannot explain how following CHM lookup
{{StandardEnvironmentFacade.java:485 }}can have ever return null, so I cannot
explain why the sequence was being recreated.
{code:java}
Sequence cachedSequence = _cachedSequences.get(sequenceKey);{code}
The sequence caching was done by QPID-5801 (0.30).
> [Broker-J] [BDB] Broker failed due to lock timeout exception on
> MESSAGE_METADATA_SEQ
>
>
> Key: QPID-8161
> URL: https://issues.apache.org/jira/browse/QPID-8161
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3
>Reporter: Keith Wall
>Priority: Major
>
> The following lock timeout exception occur during a connection establishment
> phase (client was an Qpid JMS AMQP 0-x client). The Broker treats this
> exception as fatal, so the Broker shut itself down. No message loss would
> have occurred.
>
>
> {code:java}
> 2018-04-12 04:17:00,412 ERROR [IO-/xxx.xx.xx.xx:54010] (o.a.q.s.Main) -
> Uncaught exception, shutting down.
> org.apache.qpid.server.util.ServerScopedRuntimeException:
> org.apache.qpid.server.store.StoreException: Cannot get sequence value for
> new message
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:269)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
> 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:745)
> Caused by: org.apache.qpid.server.store.StoreException: Cannot get sequence
> value for new message
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.handleDatabaseException(StandardEnvironmentFacade.java:447)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.getNextMessageId(AbstractBDBMessageStore.java:158)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.addMessage(AbstractBDBMessageStore.java:128)
> at
> org.apache.qpid.server.message.internal.InternalMessage.createMessage(InternalMessage.java:165)
> at
> org.apache.qpid.server.message.internal.InternalMessage.createBytesMessage(InternalMessage.java:209)
> at
>
[jira] [Comment Edited] (QPID-8161) [Broker-J] [BDB] Broker failed due to lock timeout exception on MESSAGE_METADATA_SEQ
[
https://issues.apache.org/jira/browse/QPID-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435350#comment-16435350
]
Keith Wall edited comment on QPID-8161 at 4/12/18 11:01 AM:
In the case of this problem, the Broker had been up for two hours before the
failure occurred, and had successfully established many AMQP 0-x messaging
connection. I conclude from that the {{MESSAGE_METADATA_SEQ}} sequence must
have been initialised and placed in the CHM. The message store only ever uses
a single sequence value, and this sequence is created and cached on first use,
and then the same sequence value remains in use until the store is closed. In
this case, there is no evidence that the Broker or Virtualhost was being
closed, so I cannot explain how following CHM lookup
\{{StandardEnvironmentFacade.java:485}} can have ever return null, so I cannot
explain why the sequence was being recreated.
{code:java}
Sequence cachedSequence = _cachedSequences.get(sequenceKey);{code}
The sequence caching was done by QPID-5801 (0.30).
was (Author: k-wall):
In the case of this problem, the Broker had been up for two hours before the
failure occurred, and had successfully established many AMQP 0-x messaging
connection. I conclude from that the {{MESSAGE_METADATA_SEQ}} sequence must
have been initialised and placed in the CHM. The message store only ever uses
a single sequence value, and this sequence is created and cached on first use,
and then the same sequence value remains in use until the store is closed. In
this case, there is no evidence that the Broker or Virtualhost was being
closed, so I cannot explain how following CHM lookup
{{StandardEnvironmentFacade.java:485 }}can have ever return null, so I cannot
explain why the sequence was being recreated.
{code:java}
Sequence cachedSequence = _cachedSequences.get(sequenceKey);{code}
The sequence caching was done by QPID-5801 (0.30).
> [Broker-J] [BDB] Broker failed due to lock timeout exception on
> MESSAGE_METADATA_SEQ
>
>
> Key: QPID-8161
> URL: https://issues.apache.org/jira/browse/QPID-8161
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3
>Reporter: Keith Wall
>Priority: Major
>
> The following lock timeout exception occur during a connection establishment
> phase (client was an Qpid JMS AMQP 0-x client). The Broker treats this
> exception as fatal, so the Broker shut itself down. No message loss would
> have occurred.
>
>
> {code:java}
> 2018-04-12 04:17:00,412 ERROR [IO-/xxx.xx.xx.xx:54010] (o.a.q.s.Main) -
> Uncaught exception, shutting down.
> org.apache.qpid.server.util.ServerScopedRuntimeException:
> org.apache.qpid.server.store.StoreException: Cannot get sequence value for
> new message
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:269)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
>
[jira] [Commented] (DISPATCH-962) links established to 'unavailable' addresses are not refused correctly
[
https://issues.apache.org/jira/browse/DISPATCH-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435311#comment-16435311
]
Robbie Gemmell commented on DISPATCH-962:
-
Thanks for the change. I tried it out and it gets things failing in the way
expected for the JMS client, throwing an exception from calls to create the
producer/consumer as its now known the attach represents a failure and imminent
detach.
I did note that the change now nulls both source and target though, whereas I'd
only expect one of them to be null (the source when clients establish a
consumer, and target when they establish a producer) if both were non-null in
the initial attach, since the router only defines one. The JMS client doesn't
care about that behaviour currently, but some peers could.
{noformat}
Attach{name='qpid-jms:receiver:ID:6cae704e-93f6-4313-801c-8c797615f00a:1:1:1:queue',
handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='queue', durable=NONE, expiryPolicy=LINK_DETACH,
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
filter=null, defaultOutcome=Modified{deliveryFailed=true,
undeliverableHere=null, messageAnnotations=null}, outcomes=[amqp:accepted:list,
amqp:rejected:list, amqp:released:list, amqp:modified:list],
capabilities=[queue]}, target=Target{address='null', durable=NONE,
expiryPolicy=SESSION_END, timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=null}, unsettled=null, incompleteUnsettled=false,
initialDeliveryCount=null, maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[750316387:1] <-
Attach{name='qpid-jms:receiver:ID:6cae704e-93f6-4313-801c-8c797615f00a:1:1:1:queue',
handle=0, role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST, source=null,
target=null, unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
{noformat}
> links established to 'unavailable' addresses are not refused correctly
> --
>
> Key: DISPATCH-962
> URL: https://issues.apache.org/jira/browse/DISPATCH-962
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.0.0, 1.0.1, 1.1.0
>Reporter: Robbie Gemmell
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.1.0
>
>
> When setting an address as unavailable (via defaultDistribution: unavailable
> from DISPATCH-803) the router doesn't refuse the links to it in the manner
> the spec indicates it should.
> To indicate a link is being refused, the spec describes that the attach
> response should contain a null target/source as appropriate, essentially
> indicating to the peer that the detach will follow due to the error,
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#doc-idp315568],
> Figure 2.33: Refusing a Link.
> Currently this does not happen, e.g:
> Creating a sending link, response attach with non-null Target:
> {noformat}
> [750316387:1] ->
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=[amqp:accepted:list, amqp:rejected:list,
> amqp:released:list, amqp:modified:list], capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=[queue]},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null,
> desiredCapabilities=[DELAYED_DELIVERY], properties=null}
> [750316387:1] <-
> Attach{name='qpid-jms:sender:ID:07e5feb4-d047-4d55-90e4-e67887f9a06a:1:1:1:queue',
> handle=0, role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
> source=Source{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> {noformat}
> Creating a receiving link, response attach with non-null Source:
> {noformat}
> [59324032:1] ->
>
[jira] [Created] (QPID-8161) [Broker-J] [BDB] Broker failed due to lock timeout exception on MESSAGE_METADATA_SEQ
Keith Wall created QPID-8161:
Summary: [Broker-J] [BDB] Broker failed due to lock timeout
exception on MESSAGE_METADATA_SEQ
Key: QPID-8161
URL: https://issues.apache.org/jira/browse/QPID-8161
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-7.0.3
Reporter: Keith Wall
The following lock timeout exception occur during a connection establishment
phase (client was an Qpid JMS AMQP 0-x client). The Broker treats this
exception as fatal, so the Broker shut itself down. No message loss would have
occurred.
{code:java}
2018-04-12 04:17:00,412 ERROR [IO-/xxx.xx.xx.xx:54010] (o.a.q.s.Main) -
Uncaught exception, shutting down.
org.apache.qpid.server.util.ServerScopedRuntimeException:
org.apache.qpid.server.store.StoreException: Cannot get sequence value for new
message
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:269)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
at
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
at
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
at
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
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:745)
Caused by: org.apache.qpid.server.store.StoreException: Cannot get sequence
value for new message
at
org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.handleDatabaseException(StandardEnvironmentFacade.java:447)
at
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.getNextMessageId(AbstractBDBMessageStore.java:158)
at
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.addMessage(AbstractBDBMessageStore.java:128)
at
org.apache.qpid.server.message.internal.InternalMessage.createMessage(InternalMessage.java:165)
at
org.apache.qpid.server.message.internal.InternalMessage.createBytesMessage(InternalMessage.java:209)
at
org.apache.qpid.server.message.internal.InternalMessage.createBytesMessage(InternalMessage.java:203)
at
org.apache.qpid.server.virtualhost.VirtualHostPropertiesNode.createMessage(VirtualHostPropertiesNode.java:89)
at
org.apache.qpid.server.virtualhost.VirtualHostPropertiesNode.addConsumer(VirtualHostPropertiesNode.java:59)
at
org.apache.qpid.server.virtualhost.VirtualHostPropertiesNode.addConsumer(VirtualHostPropertiesNode.java:37)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.consumeFromSource(AMQChannel.java:683)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveBasicConsume(AMQChannel.java:1796)
at
org.apache.qpid.server.protocol.v0_8.transport.BasicConsumeBody.process(BasicConsumeBody.java:208)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:182)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at
[jira] [Created] (DISPATCH-966) Qpid dispatch unstable inter-router connections
Marcel Meulemans created DISPATCH-966:
-
Summary: Qpid dispatch unstable inter-router connections
Key: DISPATCH-966
URL: https://issues.apache.org/jira/browse/DISPATCH-966
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 1.0.1
Reporter: Marcel Meulemans
Attachments: qdrouterd.conf, qdrouterd.log, router.dump
I am running a three node fully connected mesh of dispatch routers with 1
attached clients and I am seeing some unstable inter-router connections (I am
sending around 1000 small, less than 1K, messages per second through the
network). The inter-router connections fail every so many seconds with the
message:
{{Connection to router-2:55672 failed: amqp:session:invalid-field sequencing
error, expected delivery-id 7, got 6}}
(the numbers 7 and 6 differ per connection loss)
In wireshark, using the attached tcpdump capture, I can see that every time
before the inter router connection is dropped, therw is a rejected disposition
with the message:
{{Condition: qd:forbidden}}
{{Description: Deliveries to a multicast address must be pre-settled}}
The routers are connected as follows:
* router-0 -> router-1
* router-0 -> router-2
* router-1 -> router-2
The routers are running as a docker container (debian stretch) on google
compute engine machines (every router on a separate node).
Attached are:
* my qdrouter.conf (from one of the routers)
* a log snippet from router-0 at debug level from connection drop to
connection re-established to connection drop again.
* a tcpdump capture of the inter-router connection between router-0 and
router-1 during which several of the failures occur
Versions:
* qpid-dispatch@1.0.1-rc1
* qpid-proton@0.20.0
[^qdrouterd.log]
[^qdrouterd.conf]
[^router.dump]
--
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
