[jira] [Updated] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1745:
Fix Version/s: proton-c-0.20.0
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
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-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329877#comment-16329877
]
Cliff Jansen commented on PROTON-1745:
--
Try the attached patch and see if that works. If so, we will need more input
as to whether the old/patched behavior should be mandatory, documented and
tested.
Looking at the code, both libuv and win_iocp work the same way as the patch.
For any proactor implementation, I believe that the addrinfo should be
available (or an error generated and never available) by the time a BOUND event
is provided on an incoming connection. So, no objection from me.
Note that this behavior is asymmetric with outgoing connections which may need
to configure some transport property early (SASL?) on BOUND before a final
address (and resulting socket) is successfully opened.
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
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] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen updated PROTON-1745:
-
Attachment: p1745_0.diff
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Priority: Major
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
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-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329559#comment-16329559
]
ASF subversion and git services commented on QPID-8074:
---
Commit af3275e25c1caa20a22b1850eb9bf918428d2edb in qpid-jms-amqp-0-x's branch
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=af3275e ]
QPID-8074: [JMS AMQP 0-x][System Tests] Move more client specific tests from
Broker-J sources
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
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-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329552#comment-16329552 ] ASF subversion and git services commented on QPID-6933: --- Commit 59048193c5df0e74302024b3776c0b84ed13eec0 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=5904819 ] QPID-6933: [System Tests] Move broker system test MessageCompressionTest into MessageContentCompressionRestTest > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- 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-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329548#comment-16329548 ] ASF subversion and git services commented on QPID-6933: --- Commit 9599ec653fa30b18ea65b7c6d9f9ba4c34b7b798 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=9599ec6 ] QPID-6933: [System Tests] Add CompressionTest to JMS 1.1 system tests > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- 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-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329430#comment-16329430
]
Alex Rudyy commented on QPID-8062:
--
Attached a patch changing {{ReceivingDestination}} to throw
{{UnroutableMessageException}}, when message cannot be accepted by
{{ReceivingDestination}}. Method {{ReceivingDestination#send()}} does not
return outcome any more. It is a responsibility of a caller to generate
{{Accepted}} outcome when method {{ReceivingDestination#send()}} does not throw
{{UnroutableMessageException}} or generate a {{Rejected}} outcome when
exception is thrown. It seems that {{Accepted}} and {{Rejected}} outcomes are
the only outcomes applicable to {{ReceivingDestination}}. The rest of outcomes
({{Modified}}, {{Released}}) cannot be really returned by
{{ReceivingDestination#send()}}. As result, there is no need to return an
outcome object from {{ReceivingDestination#send()}} : the message is either
accepted or not by {{ReceivingDestination}}. I believe that attached patch
simplifies the code and removes the some duplication from implementations of
{{ReceivingDestination}}.
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8062-Broker-J-AMQP-1.0-Move-responsibility-to-c.patch
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be routed by a queue/exchange/whatever then have the transactional
> resource
> logically mark the transaction as"rollback only" (i.e. failed)
--
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-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8062:
-
Attachment: 0001-QPID-8062-Broker-J-AMQP-1.0-Move-responsibility-to-c.patch
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8062-Broker-J-AMQP-1.0-Move-responsibility-to-c.patch
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be routed by a queue/exchange/whatever then have the transactional
> resource
> logically mark the transaction as"rollback only" (i.e. failed)
--
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-1746) Add ability to build both Python 2.x and Python 3.x bindings in a single build
[
https://issues.apache.org/jira/browse/PROTON-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329300#comment-16329300
]
Kim van der Riet commented on PROTON-1746:
--
Currently the bindings install in
{{${CMAKE_INSTALL_PREFIX}/lib64/proton/bindings/python}}
and the examples in
\{{${CMAKE_INSTALL_PREFIX}/share/proton-0.20.0/examples/python}}
These paths do not allow for more than one version of Python to be present at
the same time.
> Add ability to build both Python 2.x and Python 3.x bindings in a single build
> --
>
> Key: PROTON-1746
> URL: https://issues.apache.org/jira/browse/PROTON-1746
> Project: Qpid Proton
> Issue Type: Improvement
> Components: build
>Reporter: Kim van der Riet
>Priority: Major
>
> Currently the Cmake build process detects the available Python version and
> builds according to a default if more than one version is available (at
> present 2.7 willl be built even if 3.x is available).
> Add the ability to detect and build for each of the major versions of Python
> in the same build. I suggest that if both Python 2.x and 3.x is available,
> then by default, both are built. However, a switch should be available to
> disable one or the other version if desired.
--
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-1746) Add ability to build both Python 2.x and Python 3.x bindings in a single build
Kim van der Riet created PROTON-1746: Summary: Add ability to build both Python 2.x and Python 3.x bindings in a single build Key: PROTON-1746 URL: https://issues.apache.org/jira/browse/PROTON-1746 Project: Qpid Proton Issue Type: Improvement Components: build Reporter: Kim van der Riet Currently the Cmake build process detects the available Python version and builds according to a default if more than one version is available (at present 2.7 willl be built even if 3.x is available). Add the ability to detect and build for each of the major versions of Python in the same build. I suggest that if both Python 2.x and 3.x is available, then by default, both are built. However, a switch should be available to disable one or the other version if desired. -- 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-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
Chuck Rolke created PROTON-1745:
---
Summary: [proton-c, regression] PN_CONNECTION_BOUND event is
emitted too soon
Key: PROTON-1745
URL: https://issues.apache.org/jira/browse/PROTON-1745
Project: Qpid Proton
Issue Type: Bug
Affects Versions: proton-c-0.20.0
Environment: Fedora 27
Reporter: Chuck Rolke
During a PN_CONNECTION_BOUND event proton socket information is not available.
At PN_CONNECTION_REMOTE_OPEN the info is available.
I instrumented an event loop in qpid-dispatch to log the event names as they
are delivered and to log the result of creating a qd_connection rhost_port
name. The source:
{noformat}
case PN_CONNECTION_BOUND:
on_connection_bound(qd_server, e);
// HACK ALERT
pn_connection_t *pn_conn = pn_event_connection(e);
qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
set_rhost_port(pn_conn, qd_conn);
qd_log(qd_server->log_source, QD_LOG_CRITICAL,
"At end of connection bound the name is: %s",
qd_connection_name(ctx));
// END HACK ALERT
break;
case PN_CONNECTION_REMOTE_OPEN:
{
// HACK ALERT
pn_connection_t *pn_conn = pn_event_connection(e);
qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
set_rhost_port(pn_conn, qd_conn);
qd_log(qd_server->log_source, QD_LOG_CRITICAL,
"At entry to remote open the name is: %s", qd_connection_name(ctx));
/// END HACK ALERT
{noformat}
The log file shows:
{noformat}
2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open the
name is: 127.0.0.1:46722
(/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
'ai_family' not supported. I suspect it's because the returned socket is junk.
The code works correctly in 0.19.0, commit fe3c3
--
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-1700) [cpp] Reconnecting container does not respond to stop
[ https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329183#comment-16329183 ] ASF subversion and git services commented on PROTON-1700: - Commit 7888d43d342a98577d67befde055fd5e8b4d37e1 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7888d43 ] PROTON-1700: [C++ binding] Eliminate (probably benign) race - This should silence some helgrind warnings from some test runs > [cpp] Reconnecting container does not respond to stop > - > > Key: PROTON-1700 > URL: https://issues.apache.org/jira/browse/PROTON-1700 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.1 >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Labels: reproducer > Fix For: proton-c-0.19.0 > > Attachments: reconnect-and-stop.cpp > > > Calling stop from another thread fails to terminate a container when it is > attempting to reconnect. > The attached reproducer never exits (or mostly never exits - I may have seen > it do it once). I believe it should. -- 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] (QPIDIT-109) Add ability to run Proton Python shims under Python 3
[ https://issues.apache.org/jira/browse/QPIDIT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329187#comment-16329187 ] ASF subversion and git services commented on QPIDIT-109: Commit 703daa7196cdac240ad4306ae79ddd46f3d56aa3 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=703daa7 ] QPIDIT-109: Added Python 3 compatibility to Python shims; Added Python 3 shims to tests, but left them commented out for now unitl issues with having both Proton's Python 2 and Python 3 bindings available at the same time. > Add ability to run Proton Python shims under Python 3 > - > > Key: QPIDIT-109 > URL: https://issues.apache.org/jira/browse/QPIDIT-109 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the shims run under Python 2.7, so add Python 3 as additional shim > type. -- 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] (QPIDIT-109) Add ability to run Proton Python shims under Python 3
[ https://issues.apache.org/jira/browse/QPIDIT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-109: Issue Type: Improvement (was: Bug) > Add ability to run Proton Python shims under Python 3 > - > > Key: QPIDIT-109 > URL: https://issues.apache.org/jira/browse/QPIDIT-109 > Project: Apache QPID Interoperability Test Suite > Issue Type: Improvement >Reporter: Kim van der Riet >Assignee: Kim van der Riet >Priority: Major > > Currently the shims run under Python 2.7, so add Python 3 as additional shim > type. -- 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] (QPIDJMS-357) add support for acknowledging individual messages
[ https://issues.apache.org/jira/browse/QPIDJMS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-357: --- Description: The "client acknowledgement" session acknowledgement mode allows for messages to be received by the application and for an explicit acknowledgedment step to then be perfomed later after processing through calling Message#acknowledge(). Confusingly however, this does not acknowledge the specific message it is called on but rather every message received on the same Session as the message since the prior such call. Although this is clearly documented in the API docs, many users are confused by this behaviour and understandably expect that calling message#acknowledge() would only affect that specific message. Several implementations provide a different session ack mode value to instead configure sessions for this expected 'individual acknowledgement' behaviour, such that only the message upon which acknowledge() is called is affected, and this was also under discussion for inclusion in JMS 2.1. We should provide this useful functionality. The integer session acknowledgement mode value used is 101. was:The "client acknowledgement" session acknowledgement mode allows for messages to be received by the application and for an explicit acknowledgedment step to then be perfomed later after processing through calling Message#acknowledge(). Confusingly however, this does not acknowledge the specific message it is called on but rather every message received on the same Session as the message since the prior such call. Although this is clearly documented in the API docs, many users are confused by this behaviour and understandably expect that calling message#acknowledge() would only affect that specific message. Several implementations provide a different session ack mode value to instead configure sessions for this expected 'individual acknowledgement' behaviour, such that only the message upon which acknowledge() is called is affected, and this was also under discussion for inclusion in JMS 2.1. We should provide this useful functionality. > add support for acknowledging individual messages > - > > Key: QPIDJMS-357 > URL: https://issues.apache.org/jira/browse/QPIDJMS-357 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.29.0 > > > The "client acknowledgement" session acknowledgement mode allows for messages > to be received by the application and for an explicit acknowledgedment step > to then be perfomed later after processing through calling > Message#acknowledge(). Confusingly however, this does not acknowledge the > specific message it is called on but rather every message received on the > same Session as the message since the prior such call. Although this is > clearly documented in the API docs, many users are confused by this behaviour > and understandably expect that calling message#acknowledge() would only > affect that specific message. Several implementations provide a different > session ack mode value to instead configure sessions for this expected > 'individual acknowledgement' behaviour, such that only the message upon which > acknowledge() is called is affected, and this was also under discussion for > inclusion in JMS 2.1. We should provide this useful functionality. > The integer session acknowledgement mode value used is 101. -- 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] (QPIDJMS-357) add support for acknowledging individual messages
[ https://issues.apache.org/jira/browse/QPIDJMS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329173#comment-16329173 ] ASF subversion and git services commented on QPIDJMS-357: - Commit 549b04d75bd5695ce75337b04df5cc91c636b354 in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=549b04d ] QPIDJMS-357: add support for acknowledging individual messages enable support for an 'individual acknowledge' session mode with value 101, such that the acknowledge method only applies to the message it is called on. > add support for acknowledging individual messages > - > > Key: QPIDJMS-357 > URL: https://issues.apache.org/jira/browse/QPIDJMS-357 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.29.0 > > > The "client acknowledgement" session acknowledgement mode allows for messages > to be received by the application and for an explicit acknowledgedment step > to then be perfomed later after processing through calling > Message#acknowledge(). Confusingly however, this does not acknowledge the > specific message it is called on but rather every message received on the > same Session as the message since the prior such call. Although this is > clearly documented in the API docs, many users are confused by this behaviour > and understandably expect that calling message#acknowledge() would only > affect that specific message. Several implementations provide a different > session ack mode value to instead configure sessions for this expected > 'individual acknowledgement' behaviour, such that only the message upon which > acknowledge() is called is affected, and this was also under discussion for > inclusion in JMS 2.1. We should provide this useful functionality. -- 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] (QPIDJMS-357) add support for acknowledging individual messages
Robbie Gemmell created QPIDJMS-357: -- Summary: add support for acknowledging individual messages Key: QPIDJMS-357 URL: https://issues.apache.org/jira/browse/QPIDJMS-357 Project: Qpid JMS Issue Type: New Feature Components: qpid-jms-client Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.29.0 The "client acknowledgement" session acknowledgement mode allows for messages to be received by the application and for an explicit acknowledgedment step to then be perfomed later after processing through calling Message#acknowledge(). Confusingly however, this does not acknowledge the specific message it is called on but rather every message received on the same Session as the message since the prior such call. Although this is clearly documented in the API docs, many users are confused by this behaviour and understandably expect that calling message#acknowledge() would only affect that specific message. Several implementations provide a different session ack mode value to instead configure sessions for this expected 'individual acknowledgement' behaviour, such that only the message upon which acknowledge() is called is affected, and this was also under discussion for inclusion in JMS 2.1. We should provide this useful functionality. -- 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] [Resolved] (QPIDJMS-355) Use the new Proton-J SaslListener API to simplify the sasl code
[ https://issues.apache.org/jira/browse/QPIDJMS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-355. -- Resolution: Fixed > Use the new Proton-J SaslListener API to simplify the sasl code > --- > > Key: QPIDJMS-355 > URL: https://issues.apache.org/jira/browse/QPIDJMS-355 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.28.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.29.0 > > > Latest proton-j release provide a SASL event callback that can be used to > simplify the current implementation that must check sasl state on each > inbound read. -- 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] (QPIDJMS-356) Add support for a new session mode to make all consumers presettled
[ https://issues.apache.org/jira/browse/QPIDJMS-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329130#comment-16329130 ] ASF subversion and git services commented on QPIDJMS-356: - Commit ace752e5edb9def89e15a21fd9c73ecd859d63fb in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=ace752e ] QPIDJMS-356 Adds support for presettled session mode Adds support for a no-acknowlge or presettled session mode where the receiver link created for a new JMS MessageConsumer is set to be presettled. Uses the Artemis PRE_ACKNOWLEDGE(100) or the legacy qpid jms client mode (257) mode value to define a session as being in presettled mode. > Add support for a new session mode to make all consumers presettled > --- > > Key: QPIDJMS-356 > URL: https://issues.apache.org/jira/browse/QPIDJMS-356 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.28.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.29.0 > > > Adds support for creating session with a presettled, or no-acknowledge mode > where all consumers created from the session operate as presettled receivers. > The integer session acknowledgement mode values supported are 100 and 257. -- 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] (QPIDJMS-356) Add support for a new session mode to make all consumers presettled
Timothy Bish created QPIDJMS-356: Summary: Add support for a new session mode to make all consumers presettled Key: QPIDJMS-356 URL: https://issues.apache.org/jira/browse/QPIDJMS-356 Project: Qpid JMS Issue Type: New Feature Components: qpid-jms-client Affects Versions: 0.28.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.29.0 Adds support for creating session with a presettled, or no-acknowledge mode where all consumers created from the session operate as presettled receivers. The integer session acknowledgement mode values supported are 100 and 257. -- 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-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8062:
-
Description:
As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
Message Routing Version 1.0":
{quote}
If the source of the link does not support the rejected outcome, or the message
has already been settled by the sender, then the routing node MUST detach the
link with an error. The error sent by the routing node MUST contain the error
which would have been communicated in the detach sent on attempting to link
directly to the address in the message’s to field. Additionally the info field
of error MUST contain an entry with symbolic key delivery-tag and binary value
of the delivery-tag of the message which caused the failure.
{quote}
The Broker-J does not handle the case when message is sent pre-settled and is
rejected by the destination. We need to add the support for this behaviour.
Additionally, if a pre-settled message is published within a transaction and
cannot be routed by a queue/exchange/whatever then have the transactional
resource
logically mark the transaction as"rollback only" (i.e. failed)
was:
As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
Message Routing Version 1.0":
{quote}
If the source of the link does not support the rejected outcome, or the message
has already been settled by the sender, then the routing node MUST detach the
link with an error. The error sent by the routing node MUST contain the error
which would have been communicated in the detach sent on attempting to link
directly to the address in the message’s to field. Additionally the info field
of error MUST contain an entry with symbolic key delivery-tag and binary value
of the delivery-tag of the message which caused the failure.
{quote}
The Broker-J does not handle the case when message is sent pre-settled and is
rejected by the destination. We need to add the support for this behaviour.
Additionally, if a pre-settled message is published within a transaction and
cannot be fully processed by a queue/exchange/whatever then have the
transactional resource (queue / exchange / whatever) logically mark the
transaction as"rollback only" (i.e. failed), and then reject any attempt to
commit such a transaction.
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be routed by a queue/exchange/whatever then have the transactional
> resource
> logically mark the transaction as"rollback only" (i.e. failed)
--
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-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8062:
-
Summary: [Broker-J][AMQP 1.0] Fix handling of routing errors when target
destination cannot route received message (was: [Broker-J][AMQP 1.0] When a
pre-settled message published over "anonymous relay" is rejected by the
destination, the Broker should detach the link for non-transactional case or
mark the publishing transaction as "rollback only")
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional c
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8062:
Assignee: Keith Wall (was: Alex Rudyy)
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional c
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8062:
Assignee: Alex Rudyy (was: Keith Wall)
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional ca
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8062:
-
Status: Reviewable (was: In Progress)
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional c
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-8062:
Assignee: Keith Wall
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional ca
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8062:
-
Affects Version/s: qpid-java-broker-7.0.0
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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-8062) [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous relay" is rejected by the destination, the Broker should detach the link for non-transactional ca
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8062:
-
Fix Version/s: qpid-java-broker-7.0.1
> [Broker-J][AMQP 1.0] When a pre-settled message published over "anonymous
> relay" is rejected by the destination, the Broker should detach the link for
> non-transactional case or mark the publishing transaction as "rollback only"
> ---
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be fully processed by a queue/exchange/whatever then have the
> transactional resource (queue / exchange / whatever) logically mark the
> transaction as"rollback only" (i.e. failed), and then reject any attempt to
> commit such a transaction.
--
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] [Resolved] (QPID-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-8046. -- Resolution: Fixed > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328834#comment-16328834
]
Keith Wall commented on QPID-8017:
--
Merged to 7.0.x branch.
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8017-Broker-J-Propagate-logger-rules-into-JUL-l.patch
>
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is
> required and the ability to change the process's system properties. Use the
> normal JUL system property {{java.util.logging.config.file}}. Set this to
> the location of a logging.properties file with the {{com.sleepycat.je}}
> logger set to the desired level. Once the JVM is restarted, the Broker's log
> files will include the logging.
--
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-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328833#comment-16328833
]
ASF subversion and git services commented on QPID-8017:
---
Commit 0c04fdc9046e58ac5aff43b40288cb1deb141bfb in qpid-broker-j's branch
refs/heads/7.0.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0c04fdc ]
QPID-8017: [Broker-J] [BDB] Add context variable that allows the JUL logging
level of JUL loggers to be overridden.
Cherry picked from 835efa5
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8017-Broker-J-Propagate-logger-rules-into-JUL-l.patch
>
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
> There is a workaround for the functional problem, albeit a restart is
> required and the ability to change the process's system properties. Use the
> normal JUL system property {{java.util.logging.config.file}}. Set this to
> the location of a logging.properties file with the {{com.sleepycat.je}}
> logger set to the desired level. Once the JVM is restarted, the Broker's log
> files will include the logging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit
[
https://issues.apache.org/jira/browse/QPID-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328794#comment-16328794
]
Keith Wall edited comment on QPID-8080 at 1/17/18 1:58 PM:
---
This problem will manifest in a number of places: recovery dequeuing a large
number of messages, large number of async acks arriving on the wire in one go.
The code currently allocates a JDBC connection for each
AsyncAutoCommitTransaction
({{org/apache/qpid/server/txn/AsyncAutoCommitTransaction.java:104}}). This
connection remains open until the
{{org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore#_executor}}
completes the commit and closes the connection. The problem will arise if the
number of jobs queued up on the executor exceeds the maximum number of open
connections allowable by the database. This a race between the executor
committing and closing connections and the arrival of new async auto commit
jobs.
If the user adds BoneCP, this reduces the chances of the problem occurring but
does not eliminate it. If the BoneCP hits its maximum number of open
connections the attempt to get the next connection will block. This will block
Broker-J's IO thread. BoneCP keeps retrying up to 5 * 7000 milliseconds before
giving up. If is gives up a connection exception will result and Qpid will
fail. If a connection is released in time, the blocked thread will get a
connection and the problem won't manifest. Currently it is not possible to tune
{{acquireRetryDelay}} or {{acquireRetryAttempts}} from Qpid.
To me it seems odd that each {{AsyncAutoCommitTransaction}} requires private
use of a connection. We never need to be able to rollback the the work of a
AsyncAutoCommitTransaction so the transaction isolation is needless. We ought
to be using JDBC in a transactional less mode for this work.
LocalTransactiions on the other hand would continue to require an underlying
JDBC transaction.
was (Author: k-wall):
This problem will manifest in a number of places: recovery dequeuing a large
number of messages, large number of async acks arriving on the wire in one go.
The code currently allocates a JDBC connection for each
AsyncAutoCommitTransaction
({{org/apache/qpid/server/txn/AsyncAutoCommitTransaction.java:104}}). This
connection remains open until the
{{org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore#_executor}}
completes the commit and closes the connection. The problem will arise if the
number of jobs queued up on the executor exceeds the maximum number of open
connections allowable by the database. This a race between the executor
committing and closing connections and the arrival of new async auto commit
jobs.
If the user adds BoneCP, this reduces the chances of the problem occurring but
does not eliminate it. If the BoneCP hits its maximum number of open
connections the attempt to get the next connection will block. This will block
Broker-J's IO thread. BoneCP keeps retrying up to 5 * 7000 milliseconds before
giving up. If is gives up a connection exception will result and Qpid will
fail. If a connection is released in time, the blocked thread will get a
connection and the problem won't manifest. Currently it is not possible to tune
{{acquireRetryDelay}} or {{acquireRetryAttempts}} from Qpid.
To me it seems odd that each {{AsyncAutoCommitTransaction}} requires private
use of a connection. We never need to be able to rollback the the work of a
AsyncAutoCommitTransaction so the transaction isolation is needless. We ought
to be using JDBC in a transactional less mode for this work.
LocalTransactiions on the other hand would continue to require an underlying
JDBC transaction.
> [Broker-J] Broker can crash when JDBC message store opens to many SQL
> connections to the RDBMS exceeding the maximum connection limit
> -
>
> Key: QPID-8080
> URL: https://issues.apache.org/jira/browse/QPID-8080
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
> Environment: Broker-J with JDVC message store can crash when
> messaging client(s) consume or publish small messages in non-transactional
> manner (for example, when AUTO_ACK acknowledge mode is used by JMS client).
> The broker creates \{{AsyncAutoCommitTransaction}} per each
> consumed/published message. Each transaction opens a separate connection to
> RDBMS server. The number of concurrent \{{AsyncAutoCommitTransaction}} can
> exceed the maximum connection limit. As result, sql connection establishment
> fails causing broker to crash with the stack trace like the one below:
> {noformat}
>
[jira] [Comment Edited] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit
[
https://issues.apache.org/jira/browse/QPID-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328794#comment-16328794
]
Keith Wall edited comment on QPID-8080 at 1/17/18 1:58 PM:
---
This problem will manifest in a number of places: recovery dequeuing a large
number of messages, large number of async acks arriving on the wire in one go.
The code currently allocates a JDBC connection for each
AsyncAutoCommitTransaction
({{org/apache/qpid/server/txn/AsyncAutoCommitTransaction.java:104}}). This
connection remains open until the
{{org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore#_executor}}
completes the commit and closes the connection. The problem will arise if the
number of jobs queued up on the executor exceeds the maximum number of open
connections allowable by the database. This a race between the executor
committing and closing connections and the arrival of new async auto commit
jobs.
If the user adds BoneCP, this reduces the chances of the problem occurring but
does not eliminate it. If the BoneCP hits its maximum number of open
connections the attempt to get the next connection will block. This will block
Broker-J's IO thread. BoneCP keeps retrying up to 5 * 7000 milliseconds before
giving up. If is gives up a connection exception will result and Qpid will
fail. If a connection is released in time, the blocked thread will get a
connection and the problem won't manifest. Currently it is not possible to tune
{{acquireRetryDelay}} or {{acquireRetryAttempts}} from Qpid.
To me it seems odd that each {{AsyncAutoCommitTransaction}} requires private
use of a connection. We never need to be able to rollback the the work of a
AsyncAutoCommitTransaction so the transaction isolation is needless. We ought
to be using JDBC in a transactional less mode for this work.
LocalTransactiions on the other hand would continue to require an underlying
JDBC transaction.
was (Author: k-wall):
This problem will manifest in a number of places: recovery dequeuing a large
number of messages, large number of async acks arriving on the wire in one go.
The code currently allocates a JDBC connection for each
AsyncAutoCommitTransaction
({{org/apache/qpid/server/txn/AsyncAutoCommitTransaction.java:104}}). This
connection remains open until the
{{org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore#_executor}}
completes the commit and closes the connection. The problem will arise if the
number of jobs queued up on the executed exceeds the maximum number of open
connections allowable by the database. This a race between the executor
committing and closing connections and the arrival of new async auto commit
jobs.
If the user adds BoneCP, this reduces the chances of the problem occurring but
does not eliminate it. If the BoneCP hits its maximum number of open
connections the attempt to get the next connection will block. This will block
Broker-J's IO thread. BoneCP keeps retrying up to 5 * 7000 milliseconds before
giving up. If is gives up a connection exception will result and Qpid will
fail. If a connection is released in time, the blocked thread will get a
connection and the problem won't manifest. Currently it is not possible to tune
{{acquireRetryDelay}} or {{acquireRetryAttempts}} from Qpid.
To me it seems odd that each {{AsyncAutoCommitTransaction}} requires private
use of a connection. We never need to be able to rollback the the work of a
AsyncAutoCommitTransaction so the transaction isolation is needless. We ought
to be using JDBC in a transactional less mode for this work.
LocalTransactiions on the other hand would continue to require an underlying
JDBC transaction.
> [Broker-J] Broker can crash when JDBC message store opens to many SQL
> connections to the RDBMS exceeding the maximum connection limit
> -
>
> Key: QPID-8080
> URL: https://issues.apache.org/jira/browse/QPID-8080
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
> Environment: Broker-J with JDVC message store can crash when
> messaging client(s) consume or publish small messages in non-transactional
> manner (for example, when AUTO_ACK acknowledge mode is used by JMS client).
> The broker creates \{{AsyncAutoCommitTransaction}} per each
> consumed/published message. Each transaction opens a separate connection to
> RDBMS server. The number of concurrent \{{AsyncAutoCommitTransaction}} can
> exceed the maximum connection limit. As result, sql connection establishment
> fails causing broker to crash with the stack trace like the one below:
>
[jira] [Commented] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit
[
https://issues.apache.org/jira/browse/QPID-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328794#comment-16328794
]
Keith Wall commented on QPID-8080:
--
This problem will manifest in a number of places: recovery dequeuing a large
number of messages, large number of async acks arriving on the wire in one go.
The code currently allocates a JDBC connection for each
AsyncAutoCommitTransaction
({{org/apache/qpid/server/txn/AsyncAutoCommitTransaction.java:104}}). This
connection remains open until the
{{org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore#_executor}}
completes the commit and closes the connection. The problem will arise if the
number of jobs queued up on the executed exceeds the maximum number of open
connections allowable by the database. This a race between the executor
committing and closing connections and the arrival of new async auto commit
jobs.
If the user adds BoneCP, this reduces the chances of the problem occurring but
does not eliminate it. If the BoneCP hits its maximum number of open
connections the attempt to get the next connection will block. This will block
Broker-J's IO thread. BoneCP keeps retrying up to 5 * 7000 milliseconds before
giving up. If is gives up a connection exception will result and Qpid will
fail. If a connection is released in time, the blocked thread will get a
connection and the problem won't manifest. Currently it is not possible to tune
{{acquireRetryDelay}} or {{acquireRetryAttempts}} from Qpid.
To me it seems odd that each {{AsyncAutoCommitTransaction}} requires private
use of a connection. We never need to be able to rollback the the work of a
AsyncAutoCommitTransaction so the transaction isolation is needless. We ought
to be using JDBC in a transactional less mode for this work.
LocalTransactiions on the other hand would continue to require an underlying
JDBC transaction.
> [Broker-J] Broker can crash when JDBC message store opens to many SQL
> connections to the RDBMS exceeding the maximum connection limit
> -
>
> Key: QPID-8080
> URL: https://issues.apache.org/jira/browse/QPID-8080
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-broker-7.0.0, qpid-java-6.1.5
> Environment: Broker-J with JDVC message store can crash when
> messaging client(s) consume or publish small messages in non-transactional
> manner (for example, when AUTO_ACK acknowledge mode is used by JMS client).
> The broker creates \{{AsyncAutoCommitTransaction}} per each
> consumed/published message. Each transaction opens a separate connection to
> RDBMS server. The number of concurrent \{{AsyncAutoCommitTransaction}} can
> exceed the maximum connection limit. As result, sql connection establishment
> fails causing broker to crash with the stack trace like the one below:
> {noformat}
>
> #
> # Unhandled Exception
> org.apache.qpid.server.util.ServerScopedRuntimeException:
> org.apache.qpid.server.store.StoreException:
> java.sql.SQLNonTransientConnectionException: Too many connections in Thread
> IO-/127.0.0.1:55228
> #
> # Exiting
> #
>
> org.apache.qpid.server.util.ServerScopedRuntimeException:
> org.apache.qpid.server.store.StoreException:
> java.sql.SQLNonTransientConnectionException: Too many connections
> at
> org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.lambda$received$1(AMQPConnection_0_10Impl.java:157)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.received(AMQPConnection_0_10Impl.java:141)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> 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
>
[jira] [Updated] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit
[
https://issues.apache.org/jira/browse/QPID-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8080:
-
Description:
Broker-J can crash when JDBC message store is configured with a connection pool
NONE and a number of SQL connections created by the message store exceeds the
RDBMS maximum connection limit. For example, this can happen when JMS client
simply consumes or publishes messages using {{AUTO_ACKNOWLEDGE}} sessions and a
number of in-progress published or consumed messages exceeds the RDBMS maximum
connection limit. The underlying broker {{ServerTransaction}} implementations
open a new SQL connection on transaction creation. The SQL connection is closed
when transaction is committed or rollback. As result, the number of concurrent
{{ServerTransaction}} s is limited by RDBMS maximum connection limit. On
exceeding the limit broker crashes with the stack trace like the one below:
{noformat}
#
# Unhandled Exception org.apache.qpid.server.util.ServerScopedRuntimeException:
org.apache.qpid.server.store.StoreException:
java.sql.SQLNonTransientConnectionException: Too many connections in Thread
IO-/127.0.0.1:55228
#
# Exiting
#
org.apache.qpid.server.util.ServerScopedRuntimeException:
org.apache.qpid.server.store.StoreException:
java.sql.SQLNonTransientConnectionException: Too many connections
at
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.lambda$received$1(AMQPConnection_0_10Impl.java:157)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.received(AMQPConnection_0_10Impl.java:141)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
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:
java.sql.SQLNonTransientConnectionException: Too many connections
at
org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1065)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114)
at
org.apache.qpid.server.txn.AsyncAutoCommitTransaction.dequeue(AsyncAutoCommitTransaction.java:104)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.acknowledge(ServerSession.java:1185)
at
org.apache.qpid.server.protocol.v0_10.ConsumerTarget_0_10.acknowledge(ConsumerTarget_0_10.java:401)
at
org.apache.qpid.server.protocol.v0_10.ExplicitAcceptDispositionChangeListener.onAccept(ExplicitAcceptDispositionChangeListener.java:51)
at
org.apache.qpid.server.protocol.v0_10.ServerSession$2.performAction(ServerSession.java:1000)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.dispositionChange(ServerSession.java:1091)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.accept(ServerSession.java:995)
at
org.apache.qpid.server.protocol.v0_10.ServerSessionDelegate.messageAccept(ServerSessionDelegate.java:142)
at
[jira] [Updated] (QPID-8080) [Broker-J] Broker can crash when JDBC message store opens to many SQL connections to the RDBMS exceeding the maximum connection limit
[
https://issues.apache.org/jira/browse/QPID-8080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8080:
-
Description:
Broker-J can crash when JDBC message store is configured with a connection pool
NONE and a number of SQL connections created by the message store exceeds the
RDBMS maximum connection limit. For example, this can happen when JMS client
simply consumes or publishes messages using {{AUTO_ACKNOWLEDGE}} sessions and a
number of in-progress published or consumed messages exceeds the RDBMS maximum
connection limit. The underlying broker {{ServerTransaction}} implementations
open a new SQL connection on transaction creation. The SQL connection is closed
when transaction is committed or rollback. As result, the number of concurrent
{{ServerTransaction}}s is limited by RDBMS maximum connection limit. On
exceeding the limit broker crashes with the stack trace like the one below:
{noformat}
#
# Unhandled Exception org.apache.qpid.server.util.ServerScopedRuntimeException:
org.apache.qpid.server.store.StoreException:
java.sql.SQLNonTransientConnectionException: Too many connections in Thread
IO-/127.0.0.1:55228
#
# Exiting
#
org.apache.qpid.server.util.ServerScopedRuntimeException:
org.apache.qpid.server.store.StoreException:
java.sql.SQLNonTransientConnectionException: Too many connections
at
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.lambda$received$1(AMQPConnection_0_10Impl.java:157)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_10.AMQPConnection_0_10Impl.received(AMQPConnection_0_10Impl.java:141)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
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:
java.sql.SQLNonTransientConnectionException: Too many connections
at
org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$JDBCTransaction.(AbstractJDBCMessageStore.java:1065)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:122)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore$RecordedJDBCTransaction.(GenericAbstractJDBCMessageStore.java:118)
at
org.apache.qpid.server.store.jdbc.GenericAbstractJDBCMessageStore.newTransaction(GenericAbstractJDBCMessageStore.java:114)
at
org.apache.qpid.server.txn.AsyncAutoCommitTransaction.dequeue(AsyncAutoCommitTransaction.java:104)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.acknowledge(ServerSession.java:1185)
at
org.apache.qpid.server.protocol.v0_10.ConsumerTarget_0_10.acknowledge(ConsumerTarget_0_10.java:401)
at
org.apache.qpid.server.protocol.v0_10.ExplicitAcceptDispositionChangeListener.onAccept(ExplicitAcceptDispositionChangeListener.java:51)
at
org.apache.qpid.server.protocol.v0_10.ServerSession$2.performAction(ServerSession.java:1000)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.dispositionChange(ServerSession.java:1091)
at
org.apache.qpid.server.protocol.v0_10.ServerSession.accept(ServerSession.java:995)
at
org.apache.qpid.server.protocol.v0_10.ServerSessionDelegate.messageAccept(ServerSessionDelegate.java:142)
at
[jira] [Commented] (QPID-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328665#comment-16328665 ] ASF subversion and git services commented on QPID-8046: --- Commit de509dd955229a395c086a7cca874dc55306648a in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=de509dd ] QPID-8046: [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response Cherry picked from 4eb2ea6 > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328666#comment-16328666 ] ASF subversion and git services commented on QPID-8046: --- Commit 30ca170c42c400b41340a81c6a69d33aa19bf189 in qpid-broker-j's branch refs/heads/7.0.x from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=30ca170 ] QPID-8046: [Broker-J] Add more tests Cherry picked from ca088c2 > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328667#comment-16328667 ] ASF subversion and git services commented on QPID-8046: --- Commit 4b9fb37abbe882193b16595ed7b8e9d8383f59e1 in qpid-broker-j's branch refs/heads/7.0.x from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=4b9fb37 ] QPID-8046: [Broker-J] [PlainNegotiator] Eliminate redundant UTF-8/UnsupportedEncodingException catch block Cherry picked from fcca9d2 > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328668#comment-16328668 ] Keith Wall commented on QPID-8046: -- Changes looked reasonable to me, ported to 7.0.x, > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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-8046) [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial response
[ https://issues.apache.org/jira/browse/QPID-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328644#comment-16328644 ] ASF subversion and git services commented on QPID-8046: --- Commit fcca9d20a04aa99943dc4ddd8a1bb4502fe0e9f3 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=fcca9d2 ] QPID-8046: [Broker-J] [PlainNegotiator] Eliminate redundant UTF-8/UnsupportedEncodingException catch block > [Broker-J] Allow SASL mechanisms PLAIN and XOAUTH2 to not require initial > response > -- > > Key: QPID-8046 > URL: https://issues.apache.org/jira/browse/QPID-8046 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > The current implementation of SASL mechanisms PLAIN and XOAUTH2 require from > client to provide an initial response. PLAIN and XOAUTH2 sasl mechanism > implementations should send challenge (empty bytes) if initial response is > not provided. See RFC4616. -- 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] [Resolved] (QPID-8061) [Broker-J] [AMQP 0-8..0-9-1] Declaring exchange with not existing alternate binding crashes the Broker
[
https://issues.apache.org/jira/browse/QPID-8061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8061.
--
Resolution: Fixed
> [Broker-J] [AMQP 0-8..0-9-1] Declaring exchange with not existing alternate
> binding crashes the Broker
> --
>
> Key: QPID-8061
> URL: https://issues.apache.org/jira/browse/QPID-8061
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
>
> Declaration of exchange with not existing alternate binding crashes the
> Broker as below:
> {noformat}
> org.apache.qpid.server.configuration.IllegalConfigurationException: Cannot
> create alternate binding for 'test' : Alternate binding destination
> 'not_existing' cannot be found.
> at
> org.apache.qpid.server.exchange.AbstractExchange.validateOrCreateAlternateBinding(AbstractExchange.java:1057)
> at
> org.apache.qpid.server.exchange.AbstractExchange.onCreate(AbstractExchange.java:192)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doCreation(AbstractConfiguredObject.java:1273)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:893)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$6.execute(AbstractConfiguredObject.java:866)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.createAsync(AbstractConfiguredObject.java:865)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.createAsync(AbstractConfiguredObjectTypeFactory.java:75)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.createAsync(ConfiguredObjectFactoryImpl.java:145)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addChildAsync(AbstractConfiguredObject.java:2143)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.addChildAsync(AbstractVirtualHost.java:857)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2100)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$17.execute(AbstractConfiguredObject.java:2095)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:637)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:630)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
> at
> com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:75)
> 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)
> {noformat}
> Client code:
> {code}
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> AMQSession amqSession = (AMQSession)session;
> final Map arguments = new HashMap<>();
> arguments.put("alternateExchange", "not_existing");
> amqSession.sendExchangeDeclare("test",
[jira] [Commented] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs
[ https://issues.apache.org/jira/browse/QPID-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328617#comment-16328617 ] ASF subversion and git services commented on QPID-8025: --- Commit 66faf8edd1fa0bc4be657747e5e1bb07afa91aa7 in qpid-broker-j's branch refs/heads/7.0.x from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=66faf8e ] QPID-8025 : [Java Broker] Improve detach error message on unsubscribing from JMS shared subs Cherry picked from master e3aa40d > [Java Broker] Improve detach error message on unsubscribing from JMS shared > subs > > > Key: QPID-8025 > URL: https://issues.apache.org/jira/browse/QPID-8025 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > > On attempting to unsubscribe from a shared subscription, JMS requires an > error to occur if there exist active subscribers. The error message returned > by the broker in this case currently refers to the queue the broker generates > for the durable subscription, the name of which is in effect an > implementation artefact. > Since the particular implementation of shared subscriptions is essentially > JMS specific, it makes sense for the returned error message to be in terms of > the shared sub name, not the queue -- 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] [Resolved] (QPID-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs
[ https://issues.apache.org/jira/browse/QPID-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-8025. -- Resolution: Fixed > [Java Broker] Improve detach error message on unsubscribing from JMS shared > subs > > > Key: QPID-8025 > URL: https://issues.apache.org/jira/browse/QPID-8025 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > > On attempting to unsubscribe from a shared subscription, JMS requires an > error to occur if there exist active subscribers. The error message returned > by the broker in this case currently refers to the queue the broker generates > for the durable subscription, the name of which is in effect an > implementation artefact. > Since the particular implementation of shared subscriptions is essentially > JMS specific, it makes sense for the returned error message to be in terms of > the shared sub name, not the queue -- 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-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs
[ https://issues.apache.org/jira/browse/QPID-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328555#comment-16328555 ] Keith Wall commented on QPID-8025: -- Change looks reasonable to me. > [Java Broker] Improve detach error message on unsubscribing from JMS shared > subs > > > Key: QPID-8025 > URL: https://issues.apache.org/jira/browse/QPID-8025 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.1 > > > On attempting to unsubscribe from a shared subscription, JMS requires an > error to occur if there exist active subscribers. The error message returned > by the broker in this case currently refers to the queue the broker generates > for the durable subscription, the name of which is in effect an > implementation artefact. > Since the particular implementation of shared subscriptions is essentially > JMS specific, it makes sense for the returned error message to be in terms of > the shared sub name, not the queue -- 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-8025) [Java Broker] Improve detach error message on unsubscribing from JMS shared subs
[ https://issues.apache.org/jira/browse/QPID-8025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8025: - Priority: Minor (was: Major) > [Java Broker] Improve detach error message on unsubscribing from JMS shared > subs > > > Key: QPID-8025 > URL: https://issues.apache.org/jira/browse/QPID-8025 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Rob Godfrey >Priority: Minor > Fix For: qpid-java-broker-7.0.1 > > > On attempting to unsubscribe from a shared subscription, JMS requires an > error to occur if there exist active subscribers. The error message returned > by the broker in this case currently refers to the queue the broker generates > for the durable subscription, the name of which is in effect an > implementation artefact. > Since the particular implementation of shared subscriptions is essentially > JMS specific, it makes sense for the returned error message to be in terms of > the shared sub name, not the queue -- 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] [Resolved] (QPID-8076) [0-91] [Publisher Confirms] basic.ack returned to client before message is sync'd to disk
[
https://issues.apache.org/jira/browse/QPID-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8076.
--
Resolution: Fixed
Changes look reasonable for me
> [0-91] [Publisher Confirms] basic.ack returned to client before message is
> sync'd to disk
> -
>
> Key: QPID-8076
> URL: https://issues.apache.org/jira/browse/QPID-8076
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: 0.32, qpid-java-6.0, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> QPID-6164 added RabbitMQ's publish confirms [1] feature to Broker-J.
> Concerning when the basic.ack is sent back to the client, the feature
> documentation states:
> {quote}
> h3. When will messages be confirmed?
> ..
> For routable messages, the basic.ack is sent when a message has been accepted
> by all the queues. For persistent messages routed to durable queues, this
> *means persisting to disk*.
> {quote}
> Currently, Broker-J does not behave in this way. The {{basic.ack}} is
> returned to the client before the auto-async transaction has confirmed that
> the data is on disk. The code is AMQChannel#deliverCurrentMessageIfComplete.
> It ought to arrange for the acks to be returned once the sync completes.
>
> [1] [https://www.rabbitmq.com/confirms.html]
--
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-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328529#comment-16328529 ] ASF subversion and git services commented on QPID-6933: --- Commit 6f8840aed0466676d86e4c3a78dcdfc929e27a12 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6f8840a ] QPID-6933: [System Tests] Reverted unintentional removal of exclusion for FailoverMethodTest > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- 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-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328440#comment-16328440 ] ASF subversion and git services commented on QPID-6933: --- Commit 59051baa49b668e513f0a78c63f50f914b745289 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=59051ba ] QPID-6933: [System Tests] Move AMQP 0-x client specific test CloseWithBlockingReceiveTest to client suite > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- 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
