[jira] [Commented] (DISPATCH-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107415#comment-17107415
]
Keith Wall commented on DISPATCH-1656:
--
As the AMQP open field properties is of type fields[1] it feels odd that the
router configuration property restrict it to only string pairings. Would it
be possible if the openProperties string was stringified JSON that must be a
map? That way the user would be free to make use of other types. It would
mean you could lean on the well defined JSON parsing rule, escape syntax
(rather than having Dispatch having special parsing rules for this
configuration item).
That said, I am anticipating the EnMasse use-case will be name/string value
pairs.
[~lulf] any thoughts?
[1]
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is type string and is optional.
> If supplied it will consist of a series of one or more field entries
> separated by commas. A field entry is text in the form "key: value", where
> "key" that can be encoded as a valid AMQP 1.0 Symbol type. Value will be
> encoded as an AMQP 1.0 String type.
> The key or value text may contain spaces, colons or commas but must be
> enclosed in single quotes (see example below) if it does.
> Duplicate keys are NOT allowed.
> Key values that start with *qd.* or *x-opt-qd.* are reserved and must not be
> used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: "foo: bar,baz:foo, bar: 'Hello: you big, wonderful
> world!'"*}}
> {{}}}
>
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(baz): String(foo),}}
> {{Symbol(bar): String(Hello: you big, wonderful world!)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1656) Allow user-configured connection properties in the Open performative
[
https://issues.apache.org/jira/browse/DISPATCH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17107415#comment-17107415
]
Keith Wall edited comment on DISPATCH-1656 at 5/14/20, 3:40 PM:
As the AMQP open field properties is of type fields[1] it feels odd that the
router configuration property restrict it to only string pairings. Would it
be possible if the openProperties string was stringified JSON that must be a
map? That way the user would be free to make use of other types. It would
mean you could lean on the well defined JSON parsing rule, escape syntax
(rather than having Dispatch having special parsing rules for this
configuration item).
That said, I am anticipating the EnMasse use-case will be name/string value
pairs, so the proposed solution would suffice.
[~lulf] any thoughts?
[1]
[http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open]
was (Author: k-wall):
As the AMQP open field properties is of type fields[1] it feels odd that the
router configuration property restrict it to only string pairings. Would it
be possible if the openProperties string was stringified JSON that must be a
map? That way the user would be free to make use of other types. It would
mean you could lean on the well defined JSON parsing rule, escape syntax
(rather than having Dispatch having special parsing rules for this
configuration item).
That said, I am anticipating the EnMasse use-case will be name/string value
pairs.
[~lulf] any thoughts?
[1]
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#type-open
> Allow user-configured connection properties in the Open performative
>
>
> Key: DISPATCH-1656
> URL: https://issues.apache.org/jira/browse/DISPATCH-1656
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Fix For: 1.13.0
>
>
> This feature would add a new "openProperties" attribute to the
> org.apache.qpid.dispatch.connector and org.apache.qpid.dispatch.listener
> management entities. This new attribute is type string and is optional.
> If supplied it will consist of a series of one or more field entries
> separated by commas. A field entry is text in the form "key: value", where
> "key" that can be encoded as a valid AMQP 1.0 Symbol type. Value will be
> encoded as an AMQP 1.0 String type.
> The key or value text may contain spaces, colons or commas but must be
> enclosed in single quotes (see example below) if it does.
> Duplicate keys are NOT allowed.
> Key values that start with *qd.* or *x-opt-qd.* are reserved and must not be
> used.
> In addition, the following keys are reserved and must not be used:
> product
> version
> failover-server-list
> network-host
> port
> scheme
> hostname
> The openProperties keys and values will be merged into the connection
> properties field of the outgoing Open performative when establishing or
> accepting connections.
> The openProperties attribute is NOT allowed on connector or listener entities
> with roles of either "inter-router" or "edge".
> The openProperties attribute is NOT allowed on listener entities than enable
> http, i.e. http: true.
> Example:
> {{connector {}}
> {{ name: broker}}
> {{ role: route-container}}
> {{ host: 127.0.0.1}}
> {{ port: 22180}}
> {{ saslMechanisms: ANONYMOUS}}
> {{ *openProperties: "foo: bar,baz:foo, bar: 'Hello: you big, wonderful
> world!'"*}}
> {{}}}
>
> The resulting connection properties in the outgoing Open performative would
> include the following map entries:
> {{Symbol(foo): String(bar),}}
> {{Symbol(baz): String(foo),}}
> {{Symbol(bar): String(Hello: you big, wonderful world!)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1635) Allow listener to specify an optional request for TLS client auth
[ https://issues.apache.org/jira/browse/DISPATCH-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095331#comment-17095331 ] Keith Wall commented on DISPATCH-1635: -- I *think* delivering this might invoke a Proton API change (pn_ssl_domain_set_peer_authentication) as it currently has responsibilities for setting the client CA and putting OpenSSL into SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT mode. > Allow listener to specify an optional request for TLS client auth > - > > Key: DISPATCH-1635 > URL: https://issues.apache.org/jira/browse/DISPATCH-1635 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Minor > > Dispatch Router currently allows the user to configure a *mandatory > requirement* that TLS client authentication must be used for connections to a > TLS port. > For some use-cases it is desirable for some clients to use TLS client-auth > and some clients to authenticate via other means. In Java parlance this mode > of operation is describing as > [Wanting|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setWantClientAuth(boolean)] > TLS client auth rather than > [Needing|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setNeedClientAuth(boolean)]. > It would be convenient if the configuration of TLS client auth in Dispatch > Router permitted the Want semantics. > Currently with Dispatch Router to achieve this you need to configure two TLS > listeners, one with authenticatePeer: yes set true and the other not. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1635) Allow listener to specify an optional request for TLS client auth
Keith Wall created DISPATCH-1635: Summary: Allow listener to specify an optional request for TLS client auth Key: DISPATCH-1635 URL: https://issues.apache.org/jira/browse/DISPATCH-1635 Project: Qpid Dispatch Issue Type: Improvement Reporter: Keith Wall Dispatch Router currently allows the user to configure a *mandatory requirement* that TLS client authentication must be used for connections to a TLS port. For some use-cases it is desirable for some clients to use TLS client-auth and some clients to authenticate via other means. In Java parlance this mode of operation is describing as [Wanting|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setWantClientAuth(boolean)] TLS client auth rather than [Needing|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/javax/net/ssl/SSLServerSocket.html#setNeedClientAuth(boolean)]. It would be convenient if the configuration of TLS client auth in Dispatch Router permitted the Want semantics. Currently with Dispatch Router to achieve this you need to configure two TLS listeners, one with authenticatePeer: yes set true and the other not. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1634) Expose client X509 certificate identity (TLS client auth) to the auth service delegate
[ https://issues.apache.org/jira/browse/DISPATCH-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095275#comment-17095275 ] Keith Wall edited comment on DISPATCH-1634 at 4/29/20, 9:20 AM: In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert.. The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the Dispatch Router has no means to verify that user is entitled to impersonate that user, it should preemptively end the SASL negotiation negatively. [1] https://tools.ietf.org/html/rfc4422#page-29 was (Author: k-wall): In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert.. The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively. [1] https://tools.ietf.org/html/rfc4422#page-29 > Expose client X509 certificate identity (TLS client auth) to the auth service > delegate > -- > > Key: DISPATCH-1634 > URL: https://issues.apache.org/jira/browse/DISPATCH-1634 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > For the use-case where Dispatch Router is configured to require the client > use TLS client auth (authenticatePeer: yes) and the authServicePlugin is in > use, there needs to be a mechanism to expose the X509 certificate identity of > the client to the auth service so it can be used to control the`address-authz > response. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1634) Expose client X509 certificate identity (TLS client auth) to the auth service delegate
[ https://issues.apache.org/jira/browse/DISPATCH-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095275#comment-17095275 ] Keith Wall edited comment on DISPATCH-1634 at 4/29/20, 9:18 AM: In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert.. The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively. [1] https://tools.ietf.org/html/rfc4422#page-29 was (Author: k-wall): In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert.. The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively. [1] https://tools.ietf.org/html/rfc4422#page-29 If the authenticated identity that the client supplies is identical to the one we would form from the client cert, then there is no need to reject... but otherwise (absent any other form of verification/validation) it's a way of trying to impersonate and potentially a security hole > Expose client X509 certificate identity (TLS client auth) to the auth service > delegate > -- > > Key: DISPATCH-1634 > URL: https://issues.apache.org/jira/browse/DISPATCH-1634 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > For the use-case where Dispatch Router is configured to require the client > use TLS client auth (authenticatePeer: yes) and the authServicePlugin is in > use, there needs to be a mechanism to expose the X509 certificate identity of > the client to the auth service so it can be used to control the`address-authz > response. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1634) Expose client X509 certificate identity (TLS client auth) to the auth service delegate
[ https://issues.apache.org/jira/browse/DISPATCH-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095275#comment-17095275 ] Keith Wall commented on DISPATCH-1634: -- In the case where the SASL EXTERNAL mechanism is selected by the client, the router's authplugin SASL relay should be able to prepare to rewrite the authorization identity within response of the SASL-INIT (or SASL-RESPONSE) and insert the identity from the client cert.. The SASL EXTERNAL specification[1] allows the for the authorization identity to be empty (the client is requesting to act as the identity the server has associated with the client's credentials) or non empty (the client is requesting to act as the identity represented by the string). In the latter case, if the identity provided by the authorization string doesn't match the identity from the client cert, as the router has no means to verify that user is entitled to impersonate that user, it should end the SASL negotiation negatively. [1] https://tools.ietf.org/html/rfc4422#page-29 If the authenticated identity that the client supplies is identical to the one we would form from the client cert, then there is no need to reject... but otherwise (absent any other form of verification/validation) it's a way of trying to impersonate and potentially a security hole > Expose client X509 certificate identity (TLS client auth) to the auth service > delegate > -- > > Key: DISPATCH-1634 > URL: https://issues.apache.org/jira/browse/DISPATCH-1634 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > For the use-case where Dispatch Router is configured to require the client > use TLS client auth (authenticatePeer: yes) and the authServicePlugin is in > use, there needs to be a mechanism to expose the X509 certificate identity of > the client to the auth service so it can be used to control the`address-authz > response. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1634) Expose client X509 certificate identity (TLS client auth) to the auth service delegate
Keith Wall created DISPATCH-1634: Summary: Expose client X509 certificate identity (TLS client auth) to the auth service delegate Key: DISPATCH-1634 URL: https://issues.apache.org/jira/browse/DISPATCH-1634 Project: Qpid Dispatch Issue Type: Improvement Reporter: Keith Wall For the use-case where Dispatch Router is configured to require the client use TLS client auth (authenticatePeer: yes) and the authServicePlugin is in use, there needs to be a mechanism to expose the X509 certificate identity of the client to the auth service so it can be used to control the`address-authz response. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
[ https://issues.apache.org/jira/browse/DISPATCH-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16962089#comment-16962089 ] Keith Wall commented on DISPATCH-1439: -- [~tross] seconds since connection creation and seconds since last transfer would suffice. As the caller, we could use the seconds since values back into absolute time values, if we wished. [~lulf]? For background - the initial use case would be as connection statistics to be displayed in a Console application. > Expose create time/last transfer time through the Connection management entity > -- > > Key: DISPATCH-1439 > URL: https://issues.apache.org/jira/browse/DISPATCH-1439 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > Having these two additional attributes: > * connection create time > * connection last transfer time > would aid fault finding activities. > It would also serve as useful input to external tooling wishing to say, > balance connections to a router network. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1409) Update qdstat -l output to include the current credit
[ https://issues.apache.org/jira/browse/DISPATCH-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16960877#comment-16960877 ] Keith Wall commented on DISPATCH-1409: -- I think a zero credit reached timestamp would need to be exposed. That way, tools consuming the output can distinguish those links that have languished with zero credit for a long time and may signify a problem in either application or router network itself. > Update qdstat -l output to include the current credit > - > > Key: DISPATCH-1409 > URL: https://issues.apache.org/jira/browse/DISPATCH-1409 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node, Tools >Affects Versions: 1.8.0 >Reporter: Ken Giusti >Priority: Major > Labels: troubleshooting > > The (cap) field in the output of qdstat -l shows the configured capacity for > the link, not the current credit available/outstanding. > In order to easily detect credit stalls it would be useful to provide the > current credit for the link. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1439) Expose create time/last transfer time through the Connection management entity
Keith Wall created DISPATCH-1439: Summary: Expose create time/last transfer time through the Connection management entity Key: DISPATCH-1439 URL: https://issues.apache.org/jira/browse/DISPATCH-1439 Project: Qpid Dispatch Issue Type: Improvement Reporter: Keith Wall Having these two additional attributes: * connection create time * connection last transfer time would aid fault finding activities. It would also serve as useful input to external tooling wishing to say, balance connections to a router network. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[
https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926379#comment-16926379
]
Keith Wall edited comment on DISPATCH-1414 at 9/10/19 7:24 AM:
---
Sorry - my error. I thought that '' was the link name. I see now that I
am wrong. It would of course, be nice to see the link name in the message too
:).
was (Author: k-wall):
Sorry - my error. I thought that '' was the link name. I see now that I
am wrong,
> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address. This
> impedes the diagnosis of policy misconfigurations. Currently the message
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u',
> rhost '10.128.6.1', vhost 'vv' based on link target name}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[
https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16926379#comment-16926379
]
Keith Wall commented on DISPATCH-1414:
--
Sorry - my error. I thought that '' was the link name. I see now that I
am wrong,
> Include source/target address in the policy DENY info messages
> --
>
> Key: DISPATCH-1414
> URL: https://issues.apache.org/jira/browse/DISPATCH-1414
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Chuck Rolke
>Priority: Major
> Attachments: DISPATCH-1414.txt
>
>
> The policy DENY info message currently omits the source/target address. This
> impedes the diagnosis of policy misconfigurations. Currently the message
> looks like this:
> {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u',
> rhost '10.128.6.1', vhost 'vv' based on link target name}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1414) Include source/target address in the policy DENY info messages
Keith Wall created DISPATCH-1414:
Summary: Include source/target address in the policy DENY info
messages
Key: DISPATCH-1414
URL: https://issues.apache.org/jira/browse/DISPATCH-1414
Project: Qpid Dispatch
Issue Type: Improvement
Reporter: Keith Wall
The policy DENY info message currently omits the source/target address. This
impedes the diagnosis of policy misconfigurations. Currently the message looks
like this:
{{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u',
rhost '10.128.6.1', vhost 'vv' based on link target name}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1998) [Proton-J] Add SASL protocol trace
[
https://issues.apache.org/jira/browse/PROTON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1998:
---
Summary: [Proton-J] Add SASL protocol trace (was: [Proton-J] Add SASL
proton trace)
> [Proton-J] Add SASL protocol trace
> --
>
> Key: PROTON-1998
> URL: https://issues.apache.org/jira/browse/PROTON-1998
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Reporter: Keith Wall
>Priority: Minor
>
> Unlike Proton, Proton-J does not provide SASL frame trace if environment
> variable PN_TRACE_FRM is set. It would be useful if Proton-J had this
> ability too to help diagnose SASL negotiation problem.
> Proton's SASL frame trace looks like this:
> {code:java}
> [0x7fc112c03a00]: -> SASL
> [0x7fc112c03a00]: <- SASL
> [0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"guest@Oslo.local"]
> [0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
> [0x7fc112c03a00]: -> AMQP
> [0x7fc112c03a00]:0 -> @open(16)
> [container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
> channel-max=32767]{code}
--
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-1998) [Proton-J] Add SASL proton trace
Keith Wall created PROTON-1998:
--
Summary: [Proton-J] Add SASL proton trace
Key: PROTON-1998
URL: https://issues.apache.org/jira/browse/PROTON-1998
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Reporter: Keith Wall
Unlike Proton, Proton-J does not provide SASL frame trace if environment
variable PN_TRACE_FRM is set. It would be useful if Proton-J had this ability
too to help diagnose SASL negotiation problem.
Proton's SASL frame trace looks like this:
{code:java}
[0x7fc112c03a00]: -> SASL
[0x7fc112c03a00]: <- SASL
[0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"guest@Oslo.local"]
[0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
[0x7fc112c03a00]: -> AMQP
[0x7fc112c03a00]:0 -> @open(16)
[container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
channel-max=32767]{code}
--
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-8269) [Broker-J] Enforce password complexity in authentication providers managing credentials
[ https://issues.apache.org/jira/browse/QPID-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733407#comment-16733407 ] Keith Wall commented on QPID-8269: -- I think for production use-cases, Broker-J users ought to be delegating authentication to an enterprise authentication system (such as one exposing an LDAP or Kerberos API). These systems are far better positioned to enforce password complexity/reuse rules /lock out. I wouldn't recommend that an enterprise user uses the built in file/config base authentication system for anything other development use-cases. > [Broker-J] Enforce password complexity in authentication providers managing > credentials > --- > > Key: QPID-8269 > URL: https://issues.apache.org/jira/browse/QPID-8269 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0 > > > Validate the password credentials in Qpid authentication providers managing > credentials to meet the following requirements: > * Password length must be greater than predefined minimum password length > limit (8 or 16 characters, by default) > * Passwords included in the predefined blacklist must not be allowed > * Passwords must not include repetitive or sequential patterns of more than 3 > characters > * Passwords must not include the account username > * Password must be comprised of 3 out of the following 4 elements: > ** Lowercase characters (a through z) > ** Uppercase characters (A through Z) > ** Base 10 digits (0 through 9) > ** Special or non-alphanumeric characters (@,#,+,etc) > * Passwords must not be reused the last 12 times > The different password complexity policies can be applied for interactive and > non interactive accounts. -- 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-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8245: - Summary: [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand (was: [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand) > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0005-QPID-8245-Split-field-table-into-2-implementations.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- 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-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16611738#comment-16611738
]
Keith Wall commented on QPID-8238:
--
Hi Alex
I think separating the work in separate JIRAs would help.
I would have thought an immutable {{FieldTable}} implementations would be less
code, so should be simpler to reason about and review for correctness, but I
have not tried it.
With BasicContentHeaderProperties, it is not the replacement of AMQShortString
with String that I think would help, I was actually pondering whether decoding
on the short-string fields could be made on demand. For many use-cases (those
without selectors, message user-id validation is off) the the Broker does not
need messageId/correlationId/type/userId etc, so any effort put into decoding
these strings is for nought. Admittedly, the short string caching it already
has should already be preventing most of the waste. I think any change here
should be separated.
Ok, so I understand that the Exchange changes should be just a refactoring
with no functional changes. I'll try to have a quick look.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It seems adding caching here can improve the performance.
--
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-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610224#comment-16610224
]
Keith Wall commented on QPID-8238:
--
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It seems adding caching here can improve the
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610224#comment-16610224
]
Keith Wall edited comment on QPID-8238 at 9/11/18 7:52 AM:
---
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
was (Author: k-wall):
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP
[jira] [Resolved] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-8233. -- Resolution: Fixed > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- 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-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609815#comment-16609815 ] Keith Wall commented on QPID-8233: -- Looks reasonable to me. > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- 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-8231) [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from queue having attribute 'messageGroupKeyOverride' set to an empty string
[
https://issues.apache.org/jira/browse/QPID-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8231.
--
Resolution: Fixed
> [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from
> queue having attribute 'messageGroupKeyOverride' set to an empty string
> -
>
> Key: QPID-8231
> URL: https://issues.apache.org/jira/browse/QPID-8231
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Broker crashes on consumption of messages from queue having attribute
> 'messageGroupKeyOverride' set to an empty string. The following stack trace
> is generated:
> {noformat}
>
> #
> # Unhandled Exception java.lang.IllegalArgumentException: Property name must
> not be the empty string in Thread IO-/127.0.0.1:63421
> #
> # Exiting
> #
>
> java.lang.IllegalArgumentException: Property name must not be the empty string
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.checkPropertyName(FieldTable.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getProperty(FieldTable.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getObject(FieldTable.java:428)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1055)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1050)
> at
> org.apache.qpid.server.protocol.v0_8.MessageMetaData$MessageHeaderAdapter.getHeader(MessageMetaData.java:283)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.getGroupValue(AssignedConsumerMessageGroupManager.java:83)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.mightAssign(AssignedConsumerMessageGroupManager.java:61)
> at
> org.apache.qpid.server.queue.AbstractQueue.mightAssign(AbstractQueue.java:1335)
> at
> org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2087)
> at
> org.apache.qpid.server.queue.AbstractQueue.consumerHasAvailableMessages(AbstractQueue.java:2234)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.setNotifyWorkDesired(AbstractQueue.java:2245)
> at
> org.apache.qpid.server.queue.QueueConsumerImpl.setNotifyWorkDesired(QueueConsumerImpl.java:356)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.setNotifyWorkDesired(AbstractConsumerTarget.java:130)
> at
> org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8.updateNotifyWorkDesired(ConsumerTarget_0_8.java:320)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.updateAllConsumerNotifyWorkDesired(AMQChannel.java:1495)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelFlow(AMQChannel.java:2319)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelFlowBody.process(ChannelFlowBody.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:126)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
>
[jira] [Commented] (QPID-8231) [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from queue having attribute 'messageGroupKeyOverride' set to an empty string
[
https://issues.apache.org/jira/browse/QPID-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609806#comment-16609806
]
Keith Wall commented on QPID-8231:
--
Looks reasonable to me.
> [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from
> queue having attribute 'messageGroupKeyOverride' set to an empty string
> -
>
> Key: QPID-8231
> URL: https://issues.apache.org/jira/browse/QPID-8231
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Broker crashes on consumption of messages from queue having attribute
> 'messageGroupKeyOverride' set to an empty string. The following stack trace
> is generated:
> {noformat}
>
> #
> # Unhandled Exception java.lang.IllegalArgumentException: Property name must
> not be the empty string in Thread IO-/127.0.0.1:63421
> #
> # Exiting
> #
>
> java.lang.IllegalArgumentException: Property name must not be the empty string
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.checkPropertyName(FieldTable.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getProperty(FieldTable.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getObject(FieldTable.java:428)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1055)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1050)
> at
> org.apache.qpid.server.protocol.v0_8.MessageMetaData$MessageHeaderAdapter.getHeader(MessageMetaData.java:283)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.getGroupValue(AssignedConsumerMessageGroupManager.java:83)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.mightAssign(AssignedConsumerMessageGroupManager.java:61)
> at
> org.apache.qpid.server.queue.AbstractQueue.mightAssign(AbstractQueue.java:1335)
> at
> org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2087)
> at
> org.apache.qpid.server.queue.AbstractQueue.consumerHasAvailableMessages(AbstractQueue.java:2234)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.setNotifyWorkDesired(AbstractQueue.java:2245)
> at
> org.apache.qpid.server.queue.QueueConsumerImpl.setNotifyWorkDesired(QueueConsumerImpl.java:356)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.setNotifyWorkDesired(AbstractConsumerTarget.java:130)
> at
> org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8.updateNotifyWorkDesired(ConsumerTarget_0_8.java:320)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.updateAllConsumerNotifyWorkDesired(AMQChannel.java:1495)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelFlow(AMQChannel.java:2319)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelFlowBody.process(ChannelFlowBody.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:126)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
>
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598574#comment-16598574
]
Keith Wall edited comment on QPID-8238 at 8/31/18 10:50 AM:
Your comments made me remember a investigation I made a few months ago.
Just out of interest, is the in your use-case selector filtering on application
headers (those from.
{{org.apache.qpid.framing.BasicContentHeaderProperties#_headers}}) or in terms
of items that appear in content header properties (correlation id etc). If the
former, what performance do you see when testing selectors that don't hit
application headers?
The reason I ask that is that I remember the {{BasicContentHeaderProperties}}
is *unconditionally* decoded for all messages (this is where expiration is
carried, so the Broker always needs this information regardless of what
consumers are doing with selectors). The application headers OTOH are decoded
on demand. My memory is that the performance of AMQP 0-91 for v7.0 was similar
to 0.32, so that makes me think that the direct -> heap is not that impactful
in terms of performance for those test cases, so it makes me wonder why your
test case is so different.
How big are the application headers?
was (Author: k-wall):
Your comments made me remember a investigation I made a few months ago.
Just out of interest, is the in your use-case selector filtering on application
headers (those from.
{{org.apache.qpid.framing.BasicContentHeaderProperties#_headers}}) or in terms
of items that appear in content header properties (correlation id etc). If the
former, what performance do you see when testing selectors that don't hit
application headers?
The reason I ask that is that I remember the {{BasicContentHeaderProperties}}
is *unconditionally* decoded for all messages (this is where expiration is
carried, so the Broker always needs this information regardless of what
consumers are doing with selectors). The application headers OTOH are decoded
on demand. My memory is that the performance of AMQP 0-91 for v7.0 was similar
to 0.32, so that makes me think that the direct -> heap is not that impactful
in terms of performance.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598574#comment-16598574
]
Keith Wall commented on QPID-8238:
--
Your comments made me remember a investigation I made a few months ago.
Just out of interest, is the in your use-case selector filtering on application
headers (those from.
{{org.apache.qpid.framing.BasicContentHeaderProperties#_headers}}) or in terms
of items that appear in content header properties (correlation id etc). If the
former, what performance do you see when testing selectors that don't hit
application headers?
The reason I ask that is that I remember the {{BasicContentHeaderProperties}}
is *unconditionally* decoded for all messages (this is where expiration is
carried, so the Broker always needs this information regardless of what
consumers are doing with selectors). The application headers OTOH are decoded
on demand. My memory is that the performance of AMQP 0-91 for v7.0 was similar
to 0.32, so that makes me think that the direct -> heap is not that impactful
in terms of performance.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It seems adding caching here can improve the performance.
--
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-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598574#comment-16598574
]
Keith Wall edited comment on QPID-8238 at 8/31/18 10:49 AM:
Your comments made me remember a investigation I made a few months ago.
Just out of interest, is the in your use-case selector filtering on application
headers (those from.
{{org.apache.qpid.framing.BasicContentHeaderProperties#_headers}}) or in terms
of items that appear in content header properties (correlation id etc). If the
former, what performance do you see when testing selectors that don't hit
application headers?
The reason I ask that is that I remember the {{BasicContentHeaderProperties}}
is *unconditionally* decoded for all messages (this is where expiration is
carried, so the Broker always needs this information regardless of what
consumers are doing with selectors). The application headers OTOH are decoded
on demand. My memory is that the performance of AMQP 0-91 for v7.0 was similar
to 0.32, so that makes me think that the direct -> heap is not that impactful
in terms of performance.
was (Author: k-wall):
Your comments made me remember a investigation I made a few months ago.
Just out of interest, is the in your use-case selector filtering on application
headers (those from.
{{org.apache.qpid.framing.BasicContentHeaderProperties#_headers}}) or in terms
of items that appear in content header properties (correlation id etc). If the
former, what performance do you see when testing selectors that don't hit
application headers?
The reason I ask that is that I remember the {{BasicContentHeaderProperties}}
is *unconditionally* decoded for all messages (this is where expiration is
carried, so the Broker always needs this information regardless of what
consumers are doing with selectors). The application headers OTOH are decoded
on demand. My memory is that the performance of AMQP 0-91 for v7.0 was similar
to 0.32, so that makes me think that the direct -> heap is not that impactful
in terms of performance.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It
[jira] [Resolved] (QPID-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8229.
--
Resolution: Fixed
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
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-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597162#comment-16597162
]
Keith Wall commented on QPID-8229:
--
Seems okay to me.
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
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-8236) [Broker-J] Changing of group name, address or node name in BDB HA virtual host node should be disallowed
[
https://issues.apache.org/jira/browse/QPID-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8236.
--
Resolution: Fixed
> [Broker-J] Changing of group name, address or node name in BDB HA virtual
> host node should be disallowed
> -
>
> Key: QPID-8236
> URL: https://issues.apache.org/jira/browse/QPID-8236
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.7
>
>
> The BDB HA Virtual Host Node group name, address or node name can be changed
> using management interfaces, for example REST API. However, the change of
> this attributes is not reflected in the underlying BDB JE infrastructure. In
> fact, the change of group name, address or node name is unsupported by BDB
> JE. The only way any of them can be changed is by resetting the group
> information using BDB JE utility {{DbResetRepGroup}} which resets the group
> to a single node.
> The Qpid Broker should not allow to change group name, address or node name
> attributes in BDB HA Virtual Host node via management API.
> If group is changed, on next broker restart the impacted {{VHN}} fails to
> start with the following error logged into broker logs:
> {noformat}
> ERROR [qtp699327636-161] (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected
> exception in servlet '/api/latest/virtualhostnode/node1':
> java.lang.RuntimeException: Unexpected exception on environment creation
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironmentInSeparateThread(ReplicatedEnvironmentFacade.java:1578)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironment(ReplicatedEnvironmentFacade.java:1526)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.(ReplicatedEnvironmentFacade.java:288)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacadeFactory.createEnvironmentFacade(ReplicatedEnvironmentFacadeFactory.java:130)
> at
> org.apache.qpid.server.store.berkeleydb.BDBConfigurationStore.init(BDBConfigurationStore.java:120)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.activate(BDBHAVirtualHostNodeImpl.java:338)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1526)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1505)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfOpenedOrReopenFailed(AbstractConfiguredObject.java:1489)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$1700(AbstractConfiguredObject.java:97)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1716)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1678)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> 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
>
[jira] [Commented] (QPID-8236) [Broker-J] Changing of group name, address or node name in BDB HA virtual host node should be disallowed
[
https://issues.apache.org/jira/browse/QPID-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597154#comment-16597154
]
Keith Wall commented on QPID-8236:
--
Change looks reasonable to me.
> [Broker-J] Changing of group name, address or node name in BDB HA virtual
> host node should be disallowed
> -
>
> Key: QPID-8236
> URL: https://issues.apache.org/jira/browse/QPID-8236
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.7
>
>
> The BDB HA Virtual Host Node group name, address or node name can be changed
> using management interfaces, for example REST API. However, the change of
> this attributes is not reflected in the underlying BDB JE infrastructure. In
> fact, the change of group name, address or node name is unsupported by BDB
> JE. The only way any of them can be changed is by resetting the group
> information using BDB JE utility {{DbResetRepGroup}} which resets the group
> to a single node.
> The Qpid Broker should not allow to change group name, address or node name
> attributes in BDB HA Virtual Host node via management API.
> If group is changed, on next broker restart the impacted {{VHN}} fails to
> start with the following error logged into broker logs:
> {noformat}
> ERROR [qtp699327636-161] (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected
> exception in servlet '/api/latest/virtualhostnode/node1':
> java.lang.RuntimeException: Unexpected exception on environment creation
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironmentInSeparateThread(ReplicatedEnvironmentFacade.java:1578)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironment(ReplicatedEnvironmentFacade.java:1526)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.(ReplicatedEnvironmentFacade.java:288)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacadeFactory.createEnvironmentFacade(ReplicatedEnvironmentFacadeFactory.java:130)
> at
> org.apache.qpid.server.store.berkeleydb.BDBConfigurationStore.init(BDBConfigurationStore.java:120)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.activate(BDBHAVirtualHostNodeImpl.java:338)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1526)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1505)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfOpenedOrReopenFailed(AbstractConfiguredObject.java:1489)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$1700(AbstractConfiguredObject.java:97)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1716)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1678)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> 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
>
[jira] [Updated] (QPID-8231) [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from queue having attribute 'messageGroupKeyOverride' set to an empty string
[
https://issues.apache.org/jira/browse/QPID-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8231:
-
Summary: [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of
messages from queue having attribute 'messageGroupKeyOverride' set to an empty
string (was: [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on consumption of
messages from queue having attribute 'messageGroupKeyOverride' set to an empty
string)
> [Broker-J] [AMQP 0-8...0-9-1] Broker crashes on delivery of messages from
> queue having attribute 'messageGroupKeyOverride' set to an empty string
> -
>
> Key: QPID-8231
> URL: https://issues.apache.org/jira/browse/QPID-8231
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
>
> Broker crashes on consumption of messages from queue having attribute
> 'messageGroupKeyOverride' set to an empty string. The following stack trace
> is generated:
> {noformat}
>
> #
> # Unhandled Exception java.lang.IllegalArgumentException: Property name must
> not be the empty string in Thread IO-/127.0.0.1:63421
> #
> # Exiting
> #
>
> java.lang.IllegalArgumentException: Property name must not be the empty string
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.checkPropertyName(FieldTable.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getProperty(FieldTable.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.getObject(FieldTable.java:428)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1055)
> at
> org.apache.qpid.server.protocol.v0_8.FieldTable.get(FieldTable.java:1050)
> at
> org.apache.qpid.server.protocol.v0_8.MessageMetaData$MessageHeaderAdapter.getHeader(MessageMetaData.java:283)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.getGroupValue(AssignedConsumerMessageGroupManager.java:83)
> at
> org.apache.qpid.server.queue.AssignedConsumerMessageGroupManager.mightAssign(AssignedConsumerMessageGroupManager.java:61)
> at
> org.apache.qpid.server.queue.AbstractQueue.mightAssign(AbstractQueue.java:1335)
> at
> org.apache.qpid.server.queue.AbstractQueue.getNextAvailableEntry(AbstractQueue.java:2087)
> at
> org.apache.qpid.server.queue.AbstractQueue.consumerHasAvailableMessages(AbstractQueue.java:2234)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.setNotifyWorkDesired(AbstractQueue.java:2245)
> at
> org.apache.qpid.server.queue.QueueConsumerImpl.setNotifyWorkDesired(QueueConsumerImpl.java:356)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.setNotifyWorkDesired(AbstractConsumerTarget.java:130)
> at
> org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8.updateNotifyWorkDesired(ConsumerTarget_0_8.java:320)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.updateAllConsumerNotifyWorkDesired(AMQChannel.java:1495)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelFlow(AMQChannel.java:2319)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelFlowBody.process(ChannelFlowBody.java:98)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:126)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
>
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
message with an illegally encoded _properties_ section..
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primitive type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primitive type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] ->
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primitive type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to send illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to sent illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
This means the library allows the caller to sent illegally encoded AMQP 1.0
annotated messages.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
{{message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id {{
message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null,
[jira] [Commented] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16579462#comment-16579462
]
Keith Wall commented on PROTON-1915:
>From a brief look at Proton-C, I would say Proton-C is unaffected by this
>issue.
> [Proton-J] Message codec encodes messageId values with types other than those
> permitted
> ---
>
> Key: PROTON-1915
> URL: https://issues.apache.org/jira/browse/PROTON-1915
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Reporter: Keith Wall
>Priority: Major
>
> The message codec (message format 0) codec of Proton-J is prepared to send
> {{message-id}} (and {{correlation-id}}) values with types other than those
> permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
> Here's a trace from the Proton-J example
> {{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
> {{ message.setMessageId(256);}} on the transmitted message.
> The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
> the type code of the primate type {{int}}.
> {noformat}
> [250421012:0] -> Open{ containerId='', hostname='localhost',
> maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
> desiredCapabilities=null, properties=null}
> [250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
> hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
> outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
> sole-connection-for-container], desiredCapabilities=null,
> properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
> qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
> [250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null,
> capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
> incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
> DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
> [250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192,
> nextOutgoingId=0, outgoingWindow=2048, handle=0, deliveryCount=0,
> linkCredit=2, available=null, drain=false, echo=false, properties=null}
> [250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (34)
> "\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
> World!"
> [250421012:0] -> Detach{handle=0, closed=true, error=null}
> [250421012:0] -> End{error=null}
> [250421012:0] -> Close{error=null}
> [250421012:0] <- Detach{handle=0, closed=true, error=null}
> [250421012:0] <- End{error=null}
> [250421012:0] <- Close{error=null}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Summary: [Proton-J] Message codec encodes messageId values with types other
than those permitted (was: [Proton-J] Message codec encodes messageId values
with types other than permitted)
> [Proton-J] Message codec encodes messageId values with types other than those
> permitted
> ---
>
> Key: PROTON-1915
> URL: https://issues.apache.org/jira/browse/PROTON-1915
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Reporter: Keith Wall
>Priority: Major
>
> The message codec (message format 0) codec of Proton-J is prepared to send
> {{message-id}} (and {{correlation-id}} values with types other than those
> permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
> Here's a trace from the Proton-J example
> {{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id
> {{ message.setMessageId(256);}} on the transmitted message.
> The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
> the type code of the primate type {{int}}.
> {noformat}
> [250421012:0] -> Open{ containerId='', hostname='localhost',
> maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
> desiredCapabilities=null, properties=null}
> [250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
> hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
> outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
> sole-connection-for-container], desiredCapabilities=null,
> properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
> qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
> [250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null,
> capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
> incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
> DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
> [250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192,
> nextOutgoingId=0, outgoingWindow=2048, handle=0, deliveryCount=0,
> linkCredit=2, available=null, drain=false, echo=false, properties=null}
> [250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
> messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (34)
> "\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
> World!"
> [250421012:0] -> Detach{handle=0, closed=true, error=null}
> [250421012:0] -> End{error=null}
> [250421012:0] -> Close{error=null}
> [250421012:0] <- Detach{handle=0, closed=true, error=null}
> [250421012:0] <- End{error=null}
> [250421012:0] <- Close{error=null}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than those permitted
[
https://issues.apache.org/jira/browse/PROTON-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1915:
---
Description:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}}) values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id {{
message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
was:
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}} values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id {{
message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
[jira] [Created] (PROTON-1915) [Proton-J] Message codec encodes messageId values with types other than permitted
Keith Wall created PROTON-1915:
--
Summary: [Proton-J] Message codec encodes messageId values with
types other than permitted
Key: PROTON-1915
URL: https://issues.apache.org/jira/browse/PROTON-1915
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Reporter: Keith Wall
The message codec (message format 0) codec of Proton-J is prepared to send
{{message-id}} (and {{correlation-id}} values with types other than those
permitted by sections 3.2.1.1 through 3.2.14 of the AMQP 1.0 specification.
Here's a trace from the Proton-J example
{{org.apache.qpid.proton.example.reactor.Send}} modified to set a message id {{
message.setMessageId(256);}} on the transmitted message.
The {{q\x00\x00\x01\x00}} corresponds to the message id, with q (0x71) being
the type code of the primate type {{int}}.
{noformat}
[250421012:0] -> Open{ containerId='', hostname='localhost',
maxFrameSize=4294967295, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[250421012:0] -> Attach{name='sender', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[250421012:0] <- Open{ containerId='14dd72ea-f2c1-44d6-bd04-8d5cb3fea97d',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=unknown, version=7.1.0-SNAPSHOT, qpid.build=unknown,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true}}
[250421012:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[250421012:0] <- Attach{name='sender', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='mysource',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='queue', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[REJECT_UNROUTABLE, DELAYED_DELIVERY]}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=10, offeredCapabilities=[REJECT_UNROUTABLE,
DELAYED_DELIVERY], desiredCapabilities=null, properties={}}
[250421012:0] <- Flow{nextIncomingId=1, incomingWindow=8192, nextOutgoingId=0,
outgoingWindow=2048, handle=0, deliveryCount=0, linkCredit=2,
available=null, drain=false, echo=false, properties=null}
[250421012:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=0,
messageFormat=0, settled=true, more=false, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (34)
"\x00Ss\xd0\x00\x00\x00\x09\x00\x00\x00\x01q\x00\x00\x01\x00\x00Sw\xa1\x0cHello
World!"
[250421012:0] -> Detach{handle=0, closed=true, error=null}
[250421012:0] -> End{error=null}
[250421012:0] -> Close{error=null}
[250421012:0] <- Detach{handle=0, closed=true, error=null}
[250421012:0] <- End{error=null}
[250421012:0] <- Close{error=null}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8227) [Broker-J] Replace qpidbrokerversion.properties with jar metadata
[ https://issues.apache.org/jira/browse/QPID-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574426#comment-16574426 ] Keith Wall commented on QPID-8227: -- It is used when running Broker-J from classes rather than jars, as would typically happen when running inside of an IDE. My motivation was to avoid receiving logs (attached to defect reports etc) without identifying version information. > [Broker-J] Replace qpidbrokerversion.properties with jar metadata > - > > Key: QPID-8227 > URL: https://issues.apache.org/jira/browse/QPID-8227 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Historically, the released qpid broker version was stored in file > qpidbrokerversion.properties. jar metadata can be used to get implementation > version information -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1086) Dispatch Router sporadically goes into a state where TLS connections to the auth service fail
[
https://issues.apache.org/jira/browse/DISPATCH-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568067#comment-16568067
]
Keith Wall commented on DISPATCH-1086:
--
I've spent considerable time trying to reproduce this error, so far without
success, using both 1.2.0 and the 1.1.0 derivative
(enmasseproject/qdrouterd-base:1.1.0_proton-0.23.0-http-DISPATCH-1034-1039)
that was in use at the time. Unfortunately, the original test environment that
brought out this issue (many times), is not currently available.
I've raised a PR against Proton (PROTON-1886) to make the contents of the SSL
error queue available via the Proton transport tracer. Hopefully this will
shed more light.
> Dispatch Router sporadically goes into a state where TLS connections to the
> auth service fail
> -
>
> Key: DISPATCH-1086
> URL: https://issues.apache.org/jira/browse/DISPATCH-1086
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Keith Wall
>Priority: Major
>
> Whilst running performance tests against Enmasse, we periodically see a
> problem where Dispatch Router (1.1.0) goes into a state where fails to form
> TLS connections to the authservice. When this occurs, the router needs to be
> restarted to restore service. There does not seem to be a pattern to when the
> issue occurs, but in all cases where it has been seen, the test case included
> tens or hundreds of concurrently formed connections.
> The following message is written to the log:
>
> {noformat}
> 2018-07-06 10:38:45.543519 + AUTHSERVICE (warning) Cannot initialise
> SSL{noformat}
> Unfortunately turning up the router logging (using the following command)
> reveal no more useful information. This Proton improvement JIRA was raised to
> include the diagnostics from OpenSSL.
>
--
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] (PROTON-1886) Expose diagnostic information from the openssl error queue when SSL_new fails.
[
https://issues.apache.org/jira/browse/PROTON-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568060#comment-16568060
]
Keith Wall edited comment on PROTON-1886 at 8/3/18 10:25 AM:
-
Currently if {{SSL_new}} fails, Proton does not record the contents of the
thread's SSL error queue. This PR resolves this issue by directing the
contents of the error queue to the transport's tracer. The lack of this
information is hampering investigation of DISPATCH-1086. This change is likely
to have general utility too.
To see this is action, I made a throw-away change to helloworld to enable SSL
and then hacked a situation where SSL_new would fail. Running with
PN_TRACE_DRV set then gives this detail:
{noformat}
$ ./cpp/examples/helloworld_ssl
[0x7fc1cc403a00]:SSL socket setup failure.
[0x7fc1cc403a00]:error:140BA0C3:SSL routines:SSL_new:null ssl ctx
client SSL/TLS initialization error
{noformat}
was (Author: k-wall):
Currently if {{SSL_new}} fails, Proton does not record the contents of the
thread's SSL error queue. This PR resolves this issue by directing the
contents of the error queue to the transport's tracer. The lack of this
information is hampering investigation of DISPATCH-1086. This change is likely
to have general utility too.
To see this is action, I made a throw-away change to helloworld to enable SSL
and then hacked a situation where SSL_new would fail. Setting PN_TRACE_DRV
then gives this detail:
{noformat}
$ ./cpp/examples/helloworld_ssl
[0x7fc1cc403a00]:SSL socket setup failure.
[0x7fc1cc403a00]:error:140BA0C3:SSL routines:SSL_new:null ssl ctx
client SSL/TLS initialization error
{noformat}
> Expose diagnostic information from the openssl error queue when SSL_new fails.
> --
>
> Key: PROTON-1886
> URL: https://issues.apache.org/jira/browse/PROTON-1886
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Reporter: Keith Wall
>Priority: Major
>
> If Proton C's call to
> [SSL_new()|https://github.com/apache/qpid-proton/blob/3cb7a5c672d9f817a498684ac7057b713eda/c/src/ssl/openssl.c#L1235]
> fails currently proton logs only "SSL socket setup failure.". It would aid
> diagnostics if the logged information revealed the underlying reason(s) why
> the failure occurred from the openssl error queue/stack. This approach is
> suggested by the openssl SSL_new documentation.
> [https://www.openssl.org/docs/man1.0.2/ssl/SSL_new.html]
> [https://www.openssl.org/docs/manmaster/man3/ERR_get_error.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] (PROTON-1886) Expose diagnostic information from the openssl error queue when SSL_new fails.
[
https://issues.apache.org/jira/browse/PROTON-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568060#comment-16568060
]
Keith Wall commented on PROTON-1886:
Currently if {{SSL_new}} fails, Proton does not record the contents of the
thread's SSL error queue. This PR resolves this issue by directing the
contents of the error queue to the transport's tracer. The lack of this
information is hampering investigation of DISPATCH-1086. This change is likely
to have general utility too.
To see this is action, I made a throw-away change to helloworld to enable SSL
and then hacked a situation where SSL_new would fail. Setting PN_TRACE_DRV
then gives this detail:
{noformat}
$ ./cpp/examples/helloworld_ssl
[0x7fc1cc403a00]:SSL socket setup failure.
[0x7fc1cc403a00]:error:140BA0C3:SSL routines:SSL_new:null ssl ctx
client SSL/TLS initialization error
{noformat}
> Expose diagnostic information from the openssl error queue when SSL_new fails.
> --
>
> Key: PROTON-1886
> URL: https://issues.apache.org/jira/browse/PROTON-1886
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Reporter: Keith Wall
>Priority: Major
>
> If Proton C's call to
> [SSL_new()|https://github.com/apache/qpid-proton/blob/3cb7a5c672d9f817a498684ac7057b713eda/c/src/ssl/openssl.c#L1235]
> fails currently proton logs only "SSL socket setup failure.". It would aid
> diagnostics if the logged information revealed the underlying reason(s) why
> the failure occurred from the openssl error queue/stack. This approach is
> suggested by the openssl SSL_new documentation.
> [https://www.openssl.org/docs/man1.0.2/ssl/SSL_new.html]
> [https://www.openssl.org/docs/manmaster/man3/ERR_get_error.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] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Description:
Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
{{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE with
Proton-J's application code.I realised later my shell had the
{{PN_TRACE_FRM=true}} environment variable set. Unsetting the variable allows
the test to pass. The regression was introduced at 0.27.0.
{noformat}
proton_tests.engine.CreditTest.testDrainOrder
...[1346009488:0] -> Open{ containerId='',
hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
channelMax=65535, idleTimeOut=null, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
linkCredit=10, available=null, drain=false, echo=false, properties=null}
[1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (1) "A"
fail
Error during test: Traceback (most recent call last):
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
line 362, in run
phase()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 1556, in testDrainOrder
self.pump()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 112, in pump
pump(t1, t2, buffer_size)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 113, in pump
while (pump_uni(transport1, transport2, buffer_size) or
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 86, in pump_uni
p = src.pending()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
line 2764, in pending
p = pn_transport_pending(self._impl)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
line 936, in pn_transport_pending
return trans.impl.pending()
NullPointerException: java.lang.NullPointerException
org.apache.qpid.proton.codec.CompositeReadableBuffer.(CompositeReadableBuffer.java:69)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:474)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:35)
org.apache.qpid.proton.amqp.Binary.create(Binary.java:181)
org.apache.qpid.proton.engine.impl.FrameWriter.logFrame(FrameWriter.java:200)
org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:168)
[jira] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE during frame logging
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Summary: CompositeReadableBuffer.duplicate seen to throw a NPE during frame
logging (was: CompositeReadableBuffer.duplicate seen to throw a NPE)
> CompositeReadableBuffer.duplicate seen to throw a NPE during frame logging
> --
>
> Key: PROTON-1905
> URL: https://issues.apache.org/jira/browse/PROTON-1905
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.27.0, proton-j-0.28.0
>Reporter: Keith Wall
>Priority: Major
>
> Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
> {{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE
> with Proton-J's application code.I realised later my shell had the
> {{PN_TRACE_FRM=true}} environment variable set. Unsetting the variable allows
> the test to pass. The regression was introduced at 0.27.0.
> {noformat}
> proton_tests.engine.CreditTest.testDrainOrder
> ...[1346009488:0] -> Open{ containerId='',
> hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
> desiredCapabilities=null, properties=null}
> [1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
> channelMax=65535, idleTimeOut=null, outgoingLocales=null,
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=10, available=null, drain=false, echo=false, properties=null}
> [1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
> messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (1) "A"
> fail
> Error during test: Traceback (most recent call last):
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
> line 362, in run
> phase()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 1556, in testDrainOrder
> self.pump()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 112, in pump
> pump(t1, t2, buffer_size)
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 113, in pump
> while (pump_uni(transport1, transport2, buffer_size) or
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 86, in pump_uni
> p = src.pending()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
> line 2764, in pending
> p = pn_transport_pending(self._impl)
> File
>
[jira] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Affects Version/s: (was: proton-j-0.27.3)
> CompositeReadableBuffer.duplicate seen to throw a NPE
> -
>
> Key: PROTON-1905
> URL: https://issues.apache.org/jira/browse/PROTON-1905
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.27.0, proton-j-0.28.0
>Reporter: Keith Wall
>Priority: Major
>
> Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
> {{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE
> with Proton-J's application code.I realised later my shell had the
> {{PN_TRACE_FRM=true}} environment variable set. Unsetting the variable allows
> the test to pass.
> {noformat}
> proton_tests.engine.CreditTest.testDrainOrder
> ...[1346009488:0] -> Open{ containerId='',
> hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
> desiredCapabilities=null, properties=null}
> [1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
> channelMax=65535, idleTimeOut=null, outgoingLocales=null,
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=10, available=null, drain=false, echo=false, properties=null}
> [1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
> messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (1) "A"
> fail
> Error during test: Traceback (most recent call last):
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
> line 362, in run
> phase()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 1556, in testDrainOrder
> self.pump()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 112, in pump
> pump(t1, t2, buffer_size)
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 113, in pump
> while (pump_uni(transport1, transport2, buffer_size) or
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 86, in pump_uni
> p = src.pending()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
> line 2764, in pending
> p = pn_transport_pending(self._impl)
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
> line 936, in pn_transport_pending
> return trans.impl.pending()
>
[jira] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Affects Version/s: proton-j-0.27.0
proton-j-0.28.0
> CompositeReadableBuffer.duplicate seen to throw a NPE
> -
>
> Key: PROTON-1905
> URL: https://issues.apache.org/jira/browse/PROTON-1905
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.27.0, proton-j-0.28.0, proton-j-0.27.3
>Reporter: Keith Wall
>Priority: Major
>
> Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
> {{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE
> with Proton-J's application code.I realised later my shell had the
> {{PN_TRACE_FRM=true}} environment variable set. Unsetting the variable allows
> the test to pass.
> {noformat}
> proton_tests.engine.CreditTest.testDrainOrder
> ...[1346009488:0] -> Open{ containerId='',
> hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
> outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
> desiredCapabilities=null, properties=null}
> [1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
> channelMax=65535, idleTimeOut=null, outgoingLocales=null,
> incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
> incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
> sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, distributionMode=null, filter=null,
> defaultOutcome=null, outcomes=null, capabilities=null},
> target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
> timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
> unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
> maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
> properties=null}
> [1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=10, available=null, drain=false, echo=false, properties=null}
> [1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
> messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (1) "A"
> fail
> Error during test: Traceback (most recent call last):
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
> line 362, in run
> phase()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 1556, in testDrainOrder
> self.pump()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
> line 112, in pump
> pump(t1, t2, buffer_size)
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 113, in pump
> while (pump_uni(transport1, transport2, buffer_size) or
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
> line 86, in pump_uni
> p = src.pending()
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
> line 2764, in pending
> p = pn_transport_pending(self._impl)
> File
> "/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
> line 936, in pn_transport_pending
> return
[jira] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Description:
Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
{{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE with
Proton-J's application code.I realised later my shell had the
{{PN_TRACE_FRM=true}} environment variable set. Unsetting the variable allows
the test to pass.
{noformat}
proton_tests.engine.CreditTest.testDrainOrder
...[1346009488:0] -> Open{ containerId='',
hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
channelMax=65535, idleTimeOut=null, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
linkCredit=10, available=null, drain=false, echo=false, properties=null}
[1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (1) "A"
fail
Error during test: Traceback (most recent call last):
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
line 362, in run
phase()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 1556, in testDrainOrder
self.pump()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 112, in pump
pump(t1, t2, buffer_size)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 113, in pump
while (pump_uni(transport1, transport2, buffer_size) or
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 86, in pump_uni
p = src.pending()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
line 2764, in pending
p = pn_transport_pending(self._impl)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
line 936, in pn_transport_pending
return trans.impl.pending()
NullPointerException: java.lang.NullPointerException
org.apache.qpid.proton.codec.CompositeReadableBuffer.(CompositeReadableBuffer.java:69)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:474)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:35)
org.apache.qpid.proton.amqp.Binary.create(Binary.java:181)
org.apache.qpid.proton.engine.impl.FrameWriter.logFrame(FrameWriter.java:200)
org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:168)
[jira] [Updated] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
[
https://issues.apache.org/jira/browse/PROTON-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1905:
---
Description:
Whilst verifying the RC1 candidate for the 0.27.3 RC1, the
{{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE with
Proton-J's application code.I realised later my shell had the
{{PN_TRACE_FRM=true}} environment variable set.
{noformat}
proton_tests.engine.CreditTest.testDrainOrder
...[1346009488:0] -> Open{ containerId='',
hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
channelMax=65535, idleTimeOut=null, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
linkCredit=10, available=null, drain=false, echo=false, properties=null}
[1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (1) "A"
fail
Error during test: Traceback (most recent call last):
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
line 362, in run
phase()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 1556, in testDrainOrder
self.pump()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 112, in pump
pump(t1, t2, buffer_size)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 113, in pump
while (pump_uni(transport1, transport2, buffer_size) or
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 86, in pump_uni
p = src.pending()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
line 2764, in pending
p = pn_transport_pending(self._impl)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
line 936, in pn_transport_pending
return trans.impl.pending()
NullPointerException: java.lang.NullPointerException
org.apache.qpid.proton.codec.CompositeReadableBuffer.(CompositeReadableBuffer.java:69)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:474)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:35)
org.apache.qpid.proton.amqp.Binary.create(Binary.java:181)
org.apache.qpid.proton.engine.impl.FrameWriter.logFrame(FrameWriter.java:200)
org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:168)
org.apache.qpid.proton.engine.impl.TransportImpl.writeFrame(TransportImpl.java:1081)
[jira] [Created] (PROTON-1905) CompositeReadableBuffer.duplicate seen to throw a NPE
Keith Wall created PROTON-1905:
--
Summary: CompositeReadableBuffer.duplicate seen to throw a NPE
Key: PROTON-1905
URL: https://issues.apache.org/jira/browse/PROTON-1905
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: proton-j-0.27.3
Reporter: Keith Wall
Whilst verify the RC1 candidate for the 0.27.3 RC1, the
{{proton_tests.engine.CreditTest.testDrainOrder}} Jython test caused a NPE with
Proton-J's application code.
{noformat}
proton_tests.engine.CreditTest.testDrainOrder
...[1346009488:0] -> Open{ containerId='',
hostname='null', maxFrameSize=16384, channelMax=65535, idleTimeOut=null,
outgoingLocales=null, incomingLocales=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[1346009488:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Open{ containerId='', hostname='null', maxFrameSize=16384,
channelMax=65535, idleTimeOut=null, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] <- Begin{remoteChannel=0, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[1346009488:0] -> Attach{name='test-link', handle=0, role=SENDER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Attach{name='test-link', handle=0, role=RECEIVER,
sndSettleMode=MIXED, rcvSettleMode=FIRST, source=Source{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=null, outcomes=null, capabilities=null},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[1346009488:0] <- Flow{nextIncomingId=1, incomingWindow=2147483647,
nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
linkCredit=10, available=null, drain=false, echo=false, properties=null}
[1346009488:0] -> Transfer{handle=0, deliveryId=0, deliveryTag=tagA,
messageFormat=0, settled=null, more=true, rcvSettleMode=null, state=null,
resume=false, aborted=false, batchable=false} (1) "A"
fail
Error during test: Traceback (most recent call last):
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton-test",
line 362, in run
phase()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 1556, in testDrainOrder
self.pump()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/engine.py",
line 112, in pump
pump(t1, t2, buffer_size)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 113, in pump
while (pump_uni(transport1, transport2, buffer_size) or
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/python/proton_tests/common.py",
line 86, in pump_uni
p = src.pending()
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/binding/proton/__init__.py",
line 2764, in pending
p = pn_transport_pending(self._impl)
File
"/Users/keith/releases/0273/apache-qpid-proton-j-0.27.3-src/tests/java/shim/cengine.py",
line 936, in pn_transport_pending
return trans.impl.pending()
NullPointerException: java.lang.NullPointerException
org.apache.qpid.proton.codec.CompositeReadableBuffer.(CompositeReadableBuffer.java:69)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:474)
org.apache.qpid.proton.codec.CompositeReadableBuffer.duplicate(CompositeReadableBuffer.java:35)
org.apache.qpid.proton.amqp.Binary.create(Binary.java:181)
org.apache.qpid.proton.engine.impl.FrameWriter.logFrame(FrameWriter.java:200)
org.apache.qpid.proton.engine.impl.FrameWriter.writeFrame(FrameWriter.java:168)
[jira] [Commented] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559985#comment-16559985
]
Keith Wall commented on DISPATCH-1090:
--
It seems that in the case where there is no other application connected to the
same link, then the Dispatch Router should be depriving Broker of credit.I
believe [~gemmellr] suggestion was to use drain flag in this case.
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Version 1.3.0-SNAPSHOT
> (30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
> Protocol trace attached to this issue demonstrates the problem.
> Dispatch Router was configured by the following commands:
> {noformat}
> qdmanage create --type org.apache.qpid.dispatch.connector host=oslo.local
> port=5672 name=artemis-broker role=route-container
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=in connection=artemis-broker
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=out connection=artemis-broker
> qdmanage create --type=org.apache.qpid.dispatch.router.config.address
> pattern=queue waypoint=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated DISPATCH-1090:
-
Description:
I have configured a single Dispatch Router instance to route messages through a
broker queue (i.e. following section 7.2.5 of the
[docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
The application does the following:
# Forms a sending links to the queue, sends a single message then disconnects.
# Forms a receiving link to the same queue, receives the message without
settling then abruptly terminates the program.
Inspecting the protocol trace, I see that after the Dispatch Router has sent a
{{Disposition state=modified}} for the message that was held by the application
when it terminated, a {{Transfer}}/{{Disposition state=release}} loop forms
between the Dispatch Router and Broker until the link credit is exhausted.
Protocol trace attached to this issue demonstrates the problem.
Dispatch Router was configured by the following commands:
{noformat}
qdmanage create --type org.apache.qpid.dispatch.connector host=oslo.local
port=5672 name=artemis-broker role=route-container
qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
addr=queue direction=in connection=artemis-broker
qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
addr=queue direction=out connection=artemis-broker
qdmanage create --type=org.apache.qpid.dispatch.router.config.address
pattern=queue waypoint=true
{noformat}
was:
I have configured a single Dispatch Router instance to route messages through a
broker queue (i.e. following section 7.2.5 of the
[docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
The application does the following:
# Forms a sending links to the queue, sends a single message then disconnects.
# Forms a receiving link to the same queue, receives the message without
settling then abruptly terminates the program.
Inspecting the protocol trace, I see that after the Dispatch Router has sent a
{{Disposition state=modified}} for the message that was held by the application
when it terminated, a {{Transfer}}/{{Disposition state=release}} loop forms
between the Dispatch Router and Broker until the link credit is exhausted.
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Version 1.3.0-SNAPSHOT
> (30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
> Protocol trace attached to this issue demonstrates the problem.
> Dispatch Router was configured by the following commands:
> {noformat}
> qdmanage create --type org.apache.qpid.dispatch.connector host=oslo.local
> port=5672 name=artemis-broker role=route-container
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=in connection=artemis-broker
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=out connection=artemis-broker
> qdmanage create --type=org.apache.qpid.dispatch.router.config.address
> pattern=queue waypoint=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated DISPATCH-1090:
-
Environment:
Version 1.3.0-SNAPSHOT
(30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Version 1.3.0-SNAPSHOT
> (30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated DISPATCH-1090:
-
Description:
I have configured a single Dispatch Router instance to route messages through a
broker queue (i.e. following section 7.2.5 of the
[docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
The application does the following:
# Forms a sending links to the queue, sends a single message then disconnects.
# Forms a receiving link to the same queue, receives the message without
settling then abruptly terminates the program.
Inspecting the protocol trace, I see that after the Dispatch Router has sent a
{{Disposition state=modified}} for the message that was held by the application
when it terminated, a {{Transfer}}/{{Disposition state=release}} loop forms
between the Dispatch Router and Broker until the link credit is exhausted.
was:
I have configured a single Dispatch Router instance to route messages through a
broker queue (i.e. following section 7.2.5 of the
[docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
The application does the following:
# Forms a sending links to the queue, sends a single message then disconnects.
# Forms a receiving link to the same queue, receives the message without
settling then abruptly terminates the program.
Inspecting the protocol trace, I see that after the Dispatch Router has sent a
{{Disposition state=modified}} for the message that was held by the application
when it terminated, a {{Transfer}}/{{Disposition state=release}} loop forms
between the Dispatch Router and Broker until the link credit is exhausted.
The application connects sends to the queue via the router, disconnects and the
then connects a second time
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated DISPATCH-1090:
-
Attachment: DISPATCH-1090_dispatch_server.log
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Keith Wall
>Priority: Major
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
> The application connects sends to the queue via the router, disconnects and
> the then connects a second time
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
Keith Wall created DISPATCH-1090:
Summary: Transfer/Disposition(state=release) loop forms when
application disconnects abruptly from brokered queue until link credit is
exhausted.
Key: DISPATCH-1090
URL: https://issues.apache.org/jira/browse/DISPATCH-1090
Project: Qpid Dispatch
Issue Type: Bug
Reporter: Keith Wall
I have configured a single Dispatch Router instance to route messages through a
broker queue (i.e. following section 7.2.5 of the
[docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
The application does the following:
# Forms a sending links to the queue, sends a single message then disconnects.
# Forms a receiving link to the same queue, receives the message without
settling then abruptly terminates the program.
Inspecting the protocol trace, I see that after the Dispatch Router has sent a
{{Disposition state=modified}} for the message that was held by the application
when it terminated, a {{Transfer}}/{{Disposition state=release}} loop forms
between the Dispatch Router and Broker until the link credit is exhausted.
The application connects sends to the queue via the router, disconnects and the
then connects a second time
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1086) Dispatch Router sporadically goes into a state where TLS connections to the auth service fail
Keith Wall created DISPATCH-1086:
Summary: Dispatch Router sporadically goes into a state where TLS
connections to the auth service fail
Key: DISPATCH-1086
URL: https://issues.apache.org/jira/browse/DISPATCH-1086
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Keith Wall
Whilst running performance tests against Enmasse, we periodically see a problem
where Dispatch Router (1.1.0) goes into a state where fails to form TLS
connections to the authservice. When this occurs, the router needs to be
restarted to restore service. There does not seem to be a pattern to when the
issue occurs, but in all cases where it has been seen, the test case included
tens or hundreds of concurrently formed connections.
The following message is written to the log:
{noformat}
2018-07-06 10:38:45.543519 + AUTHSERVICE (warning) Cannot initialise
SSL{noformat}
Unfortunately turning up the router logging (using the following command)
reveal no more useful information. This Proton improvement JIRA was raised to
include the diagnostics from OpenSSL.
--
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-8219) [Broker-J] Authentication results are cached in SimpleLdap Authentication provider per connection basis
[ https://issues.apache.org/jira/browse/QPID-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546328#comment-16546328 ] Keith Wall commented on QPID-8219: -- Wouldn't this problem also affect OAuth2AuthenticationProvider which IIRC uses the same scheme? > [Broker-J] Authentication results are cached in SimpleLdap Authentication > provider per connection basis > --- > > Key: QPID-8219 > URL: https://issues.apache.org/jira/browse/QPID-8219 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5, > qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0, > qpid-java-broker-7.0.7 > > > SimpleLdap authentication provider was supposed to cache authentication > results per remote host basis. Thus, when connections are made from the same > host using the same credentials, the cached authentication results should be > reused. The current caching approach takes into consideration an ephemeral > port of the connection. As result, a new connection from the same host with > the same credentials cannot reuse previous authentication results due to a > different ephemeral port. -- 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-8212) [JMS AMQP 0-x][AMQP 0-8..0-91] Consumer close can block for 60 seconds and endup in time-out exception
[
https://issues.apache.org/jira/browse/QPID-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16534863#comment-16534863
]
Keith Wall commented on QPID-8212:
--
I can't say that addition of the new method to AMQSession#isSessionClosed()
seems like the ideal approach, but I don't see an alternative without making a
deeper change, which would not be wanted given the stage of life of this client.
> [JMS AMQP 0-x][AMQP 0-8..0-91] Consumer close can block for 60 seconds and
> endup in time-out exception
> --
>
> Key: QPID-8212
> URL: https://issues.apache.org/jira/browse/QPID-8212
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Blocker
> Fix For: qpid-java-client-0-x-6.3.2
>
>
> When method {{MessageConsumer#close()}} is invoked in one thread and method
> {{Connection#close()}} is invoked in another thread, the incoming
> {{BasicCancelOk}} frame can be ignored due to {{true}} being returned from
> {{Session#isClosed()}} because of {{Connection#_closed}} flag being set to
> true on connection close. As result, the call to {{MessageConsumer#close()}}
> can block for 60 seconds and end up in exception due to not being able to
> receive {{BasicCancelOk}}. Invocation of {{Connection#close()}} also gets
> blocked as message delivery lock being hold on consumer close.
> The defect was introduced as part of changes made against QPID-8185 in commit
>
> [f89f6c2f45d11fc63551d0d61c17eceedd6bd247|https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=f89f6c2]
> Method {{AMQProtocolSession#isClosedForInput}} checks whether session is
> closed for input by calling {{AMQSession#isClosed()}}. The latter returns
> true when either {{AMQSession#_closed}} or {{AMQConnection#_closed}} holds
> {{true}}. Only {{AMQSession#_closed}} should be checked in
> {{AMQProtocolSession#isClosedForInput}}.
--
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-1886) Expose diagnostic information from the openssl error queue when SSL_new fails.
Keith Wall created PROTON-1886: -- Summary: Expose diagnostic information from the openssl error queue when SSL_new fails. Key: PROTON-1886 URL: https://issues.apache.org/jira/browse/PROTON-1886 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Keith Wall If Proton C's call to [SSL_new()|https://github.com/apache/qpid-proton/blob/3cb7a5c672d9f817a498684ac7057b713eda/c/src/ssl/openssl.c#L1235] fails currently proton logs only "SSL socket setup failure.". It would aid diagnostics if the logged information revealed the underlying reason(s) why the failure occurred from the openssl error queue/stack. This approach is suggested by the openssl SSL_new documentation. [https://www.openssl.org/docs/man1.0.2/ssl/SSL_new.html] [https://www.openssl.org/docs/manmaster/man3/ERR_get_error.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] [Updated] (QPID-8213) [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
[
https://issues.apache.org/jira/browse/QPID-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8213:
-
Priority: Minor (was: Major)
> [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
> --
>
> Key: QPID-8213
> URL: https://issues.apache.org/jira/browse/QPID-8213
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1,
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7,
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0,
> qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> A redundant InputStream is opened and not closed in
> {{SSLUtil#readCertificates(URL)}}
--
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-8213) [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
[
https://issues.apache.org/jira/browse/QPID-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8213.
--
Resolution: Fixed
Fix Version/s: qpid-java-broker-7.1.0
> [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
> --
>
> Key: QPID-8213
> URL: https://issues.apache.org/jira/browse/QPID-8213
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1,
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7,
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0,
> qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> A redundant InputStream is opened and not closed in
> {{SSLUtil#readCertificates(URL)}}
--
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-8213) [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
[
https://issues.apache.org/jira/browse/QPID-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524951#comment-16524951
]
Keith Wall commented on QPID-8213:
--
Change looks good to me. I noticed qpid-jms-amqp-0-x had the same code, albeit
unused,I removed it with a NO-JIRA commit
([https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=7f67f82ec04a8a346cc64ec1cd824022c9082da0)]
> [Broker-J] InputStream is not closed in SSLUtil#readCertificates(URL)
> --
>
> Key: QPID-8213
> URL: https://issues.apache.org/jira/browse/QPID-8213
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1,
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7,
> qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0,
> qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5, qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> A redundant InputStream is opened and not closed in
> {{SSLUtil#readCertificates(URL)}}
--
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-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517872#comment-16517872
]
Keith Wall commented on QPID-8210:
--
Changes look good.
> [Broker-J] Consumer attach when message is being released and requeued can
> end-up in broker crash due to unhandled NullPointerException
>
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
>
[jira] [Commented] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517867#comment-16517867
]
Keith Wall commented on QPID-8210:
--
In addition the following cherry picks into 7.0.x are missing from the JIRAs
history:
commit c5bf4260a0da733a048b9949ca0ccaf6f9bae158
Author: Alex Rudyy
Date: Tue Jun 19 17:38:29 2018 +0100
QPID-8210: [Broker-J] Make field QueueConsumerImpl#_queueConsumerNode volatile
(cherry picked from commit a07e8fd80ea11f0458c0fcfe4bc7a0ec31b4a7bb)
commit ca118c933e4ad74375d056f694fbbb367cfa33a6
Author: Alex Rudyy
Date: Mon Jun 18 17:51:47 2018 +0100
QPID-8210: [Broker-J] Set queue consumer node before adding consumer into queue
consumer manager
(cherry picked from commit 0c4e41829d3f97eaa171fd1276e85e1685021cfc)
> [Broker-J] Consumer attach when message is being released and requeued can
> end-up in broker crash due to unhandled NullPointerException
>
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
>
[jira] [Resolved] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8210.
--
Resolution: Fixed
> [Broker-J] Consumer attach when message is being released and requeued can
> end-up in broker crash due to unhandled NullPointerException
>
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
>
[jira] [Updated] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8210:
-
Description:
The consumer node is currently set after consumer is added into queue consumer
manager. When released message is requeued all consumers in consumer manager
are iterated and AbstractQueue#updateSubRequeueEntry is invoke for every of
them to update the released entry in consumer queue context if required. The
notification of consumer without a consumer node can result in
NullPointerException:
{noformat}
java.lang.NullPointerException
at
org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
at
org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
at
org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
at
org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
at
org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
at
org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
at
org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
at
org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
at
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
at
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
at
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The issue can happen in the following scenarios:
* when previously acquired message is released due to
consumer/session/connection close and another consumer is attached to the queue
at the same time.
* when transaction is rolled back or message is released (for example, JMS
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 6:00 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed. The
Jira title should also be updated to reflect the problem, rather than the
solution.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
>
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 5:57 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 5:56 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
>
[jira] [Commented] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517377#comment-16517377
]
Keith Wall commented on QPID-8210:
--
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
>
[jira] [Commented] (QPID-8208) [Broker-J] Improve unexpected exception handling for LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508312#comment-16508312
]
Keith Wall commented on QPID-8208:
--
Alex
That looks to me to be a Java platform defect rather than a Broker-J issue.
{{InitialDirContext}} is defined by its API as throwing a {{NamingException}}
only. It cannot legitimately throw a {{NullPointerException}}.
You haven't stated the version of the JVM that produced this defect, but I
notice looking at the sources for LdapClient 1.8.0_171, there is appears to be
race condition in the implementation. If an "Notice of Disconnection"
(1.3.6.1.4.1.1466.20036) arrives from the LDAP peer this causes the
{{com.sun.jndi.ldap.LdapClient#conn}} ref to be nulled (look at
{{processUnsolicited()}} invokes {{forcedClosed()}} - which doesn't take the
mutex). If this occurs whilst a thread is executing
{{LdapClient.authenticate}}, then the NPE will occur.
I think this defect should be closed as not a defect.
> [Broker-J] Improve unexpected exception handling for LDAP connections in
> SimpleLDAPAuthenticationProvider
> -
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.5
>
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> The establishment of connection with LDAP using default
> {{com.sun.jndi.ldap.LdapCtxFactory}} can end-up in unexpected exception
> thrown from {{com.sun.jndi.ldap.LdapClient}}. Thought, it looks like a defect
> in {{LdapClient}}, the unexpected exceptions should be handled appropriately.
> The exception should be logged and the authentication failure error should be
> returned back to the client.
--
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-8207) [Broker-J] Flow to disk might not be triggered in some circumstances
[ https://issues.apache.org/jira/browse/QPID-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16507795#comment-16507795 ] Keith Wall commented on QPID-8207: -- Alex, the algebraic refactoring look good to me. > [Broker-J] Flow to disk might not be triggered in some circumstances > > > Key: QPID-8207 > URL: https://issues.apache.org/jira/browse/QPID-8207 > Project: Qpid > Issue Type: Task > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, > qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, > qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0, > qpid-java-6.1.5, qpid-java-broker-7.0.1, qpid-java-6.1.7, qpid-java-6.0.9, > qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8207-Broker-J-Fix-evaluation-of-flow-to-disk-th.patch > > > An evaluation of Virtual Host flow to disk threshold can overflow and yield > incorrect value. As result, the flow of messages to disk might not be > triggered and Broker can ran out of direct memory. -- 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-8202) [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[ https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504619#comment-16504619 ] Keith Wall commented on QPID-8202: -- Changes look reasonable to me. > [Broker-J][AMQP 0-8...0-91] Large flowed to disk message can be re-loaded > from store for every content chunk sent to the client > --- > > Key: QPID-8202 > URL: https://issues.apache.org/jira/browse/QPID-8202 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, > qpid-java-broker-7.0.2, qpid-java-6.1, qpid-java-6.1.1, qpid-java-6.1.2, > qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-broker-7.0.0, qpid-java-6.1.5, > qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > When large message cannot fit in one frame it is sent in multiple frames. > Currently, the flowed to disk message is repeatedly loaded from store and > evicted from memory on sending every content chunk. As result, the message > consumption performance is very slow. Only AMQP protocols 0-8..0-91 are > affected by the issue -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[ https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504610#comment-16504610 ] Keith Wall commented on QPID-8204: -- Changes look reasonable to me. > [Broker-J] Add statistics to report the maximum size of incoming messages > - > > Key: QPID-8204 > URL: https://issues.apache.org/jira/browse/QPID-8204 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > Attachments: > 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch > > > Add statistics to report the maximum size of incoming messages on Broker and > Virtual Hosts. Add a switch to enable/disable collection of statistics for > message maximum size . By default, collection of maximum size statistics > should be disabled -- 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-8203) [Broker-J][AMQP 0-9] Improve maximum message size check
[ https://issues.apache.org/jira/browse/QPID-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503972#comment-16503972 ] Keith Wall edited comment on QPID-8203 at 6/7/18 7:43 AM: -- Production code change (master.7.0.x) looked reasonable. The new protocol test file didn't follow the naming conventions demanded by the configuration of the maven-surefire-plugin, so wasn't being run when invoked from Maven. I fixed that and added a 0-10 protocol test. I noted that an equivalent AMQP 1.0 test already existed. was (Author: k-wall): Production code change (master.7.0.x) looked reasonable. The new protocol test file didn't follow the naming conventions demanded by the configuration of the maven-surefire-plugin, so wasn't being run when invoked from Maven. I fixed that and added a 0-10 protocol test. I noted that a AMQP 1.0 already existed. > [Broker-J][AMQP 0-9] Improve maximum message size check > --- > > Key: QPID-8203 > URL: https://issues.apache.org/jira/browse/QPID-8203 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > Maximum message size check needs to be improved -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[
https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504040#comment-16504040
]
Keith Wall edited comment on QPID-8204 at 6/7/18 7:42 AM:
--
Is the {{maxMessageSizeStatisticsEnabled}} switch really justifiable? I prefer
to avoid a proliferation of switches because they just bewilder. My guess
would be the additional CAS would have no noticeable effect on performance.
was (Author: k-wall):
Is the {{maxMessageSizeStatisticsEnabled}} switch really justifiable? I prefer
to avoid a proliferation of switches because they just bewilder. I guess would
be the additional CAS would have no noticeable effect on performance.
> [Broker-J] Add statistics to report the maximum size of incoming messages
> -
>
> Key: QPID-8204
> URL: https://issues.apache.org/jira/browse/QPID-8204
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5
>
> Attachments:
> 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch
>
>
> Add statistics to report the maximum size of incoming messages on Broker and
> Virtual Hosts. Add a switch to enable/disable collection of statistics for
> message maximum size . By default, collection of maximum size statistics
> should be disabled
--
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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[
https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504040#comment-16504040
]
Keith Wall commented on QPID-8204:
--
Is the {{maxMessageSizeStatisticsEnabled}} switch really justifiable? I prefer
to avoid a proliferation of switches because they just bewilder. I guess would
be the additional CAS would have no noticeable effect on performance.
> [Broker-J] Add statistics to report the maximum size of incoming messages
> -
>
> Key: QPID-8204
> URL: https://issues.apache.org/jira/browse/QPID-8204
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5
>
> Attachments:
> 0001-QPID-8204-Broker-J-Rename-new-statistics-into-inboun.patch
>
>
> Add statistics to report the maximum size of incoming messages on Broker and
> Virtual Hosts. Add a switch to enable/disable collection of statistics for
> message maximum size . By default, collection of maximum size statistics
> should be disabled
--
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-8202) [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store for every content chunk sent to the client
[
https://issues.apache.org/jira/browse/QPID-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504028#comment-16504028
]
Keith Wall commented on QPID-8202:
--
Isn't 6.1 affected by this problem too? I haven't run the code but it looks
like this problem has been with Broker-J since QPID-6953.
Your code change looks functionally correct to me, but the code remains less
than obvious.
# It seems odd to give the {{MessageContentSourceBody}} all the {{content}},
{{offset}} and {{length}} only then to have {{#writePayload}} take a view a few
moments later. Passing {{MessageContentSourceBody}} the view it needs would
be an improvement. Or perhaps replace {{MessageContentSourceBody}} with a
{{ContentBody}} (and remember to call dispose)?
# The calculation of {{capacity}} (which would be better named
{{contentChunkSize}}) is weird and could be expressed more clearly.
> [Broker-J][AMQP 0-9] Large flowed to disk message can be re-loaded from store
> for every content chunk sent to the client
>
>
> Key: QPID-8202
> URL: https://issues.apache.org/jira/browse/QPID-8202
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5
>
>
> When large message cannot fit in one frame it is sent in multiple blocks.
> Currently, the flowed to disk message is reloaded from store and evicted from
> memory on sending every block. As result, the message consumption performance
> is very slow. Only AMQP protocols 0-8..0-91 are affected by the issue
--
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-8203) [Broker-J][AMQP 0-9] Improve maximum message size check
[ https://issues.apache.org/jira/browse/QPID-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503972#comment-16503972 ] Keith Wall commented on QPID-8203: -- Production code change (master.7.0.x) looked reasonable. The new protocol test file didn't follow the naming conventions demanded by the configuration of the maven-surefire-plugin, so wasn't being run when invoked from Maven. I fixed that and added a 0-10 protocol test. I noted that a AMQP 1.0 already existed. > [Broker-J][AMQP 0-9] Improve maximum message size check > --- > > Key: QPID-8203 > URL: https://issues.apache.org/jira/browse/QPID-8203 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > Maximum message size check needs to be improved -- 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-8203) [Broker-J][AMQP 0-9] Improve maximum message size check
[ https://issues.apache.org/jira/browse/QPID-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-8203. -- Resolution: Fixed > [Broker-J][AMQP 0-9] Improve maximum message size check > --- > > Key: QPID-8203 > URL: https://issues.apache.org/jira/browse/QPID-8203 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Critical > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5 > > > Maximum message size check needs to be improved -- 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-8204) [Broker-J] Add statistics to report the maximum size of incoming messages
[
https://issues.apache.org/jira/browse/QPID-8204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503478#comment-16503478
]
Keith Wall commented on QPID-8204:
--
I am curious to understand the use-case for these new statistics. What problem
is being solved? Separately, I remember we already had an established naming
convention for these types of values: {{HighWatermark}}
> [Broker-J] Add statistics to report the maximum size of incoming messages
> -
>
> Key: QPID-8204
> URL: https://issues.apache.org/jira/browse/QPID-8204
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.5
>
>
> Add statistics to report the maximum size of incoming messages on Broker and
> Virtual Hosts. Add a switch to enable/disable collection of statistics for
> message maximum size . By default, collection of maximum size statistics
> should be disabled
--
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-8201) [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted twice during link close
[
https://issues.apache.org/jira/browse/QPID-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8201:
-
Description:
Running the following code using the Qpid JMS Client (I am using master) that
creates a temporary topic subscription and then immediately closes the
consumer, exposes a defect in the Broker-J. Internally Broker-J is cleaning
up the queue backing the temporary subscription twice. The second attempt
fails, which causes the detach performative to carry a spurious {{error
amqp:not-found.}}
The Qpid JMS Client appears to ignore the error, so there may not be an impact
to applications using this client. I have not checked other AMQP 1.0 clients.
{code:java}
Context context = new InitialContext();
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
Destination topic = (Destination) context.lookup("myTopicLookup");
Connection connection = factory.createConnection(System.getProperty("USER"),
System.getProperty("PASSWORD"));
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer messageConsumer = session.createConsumer(topic);
messageConsumer.close();{code}
{noformat}
[154612396:0] -> Open{ containerId='ID:29fbab21-96a9-45a9-ba6d-05b1744b9ce3:1',
hostname='localhost', maxFrameSize=1048576, channelMax=32767,
idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container,
DELAYED_DELIVERY, ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
version=0.33.0-SNAPSHOT, platform=JVM: 1.8.0_171, 25.171-b10, Oracle
Corporation, OS: Linux, 4.16.8-300.fc28.x86_64, amd64}}
[154612396:0] <- Open{ containerId='a73d8803-f5bd-46c8-90d3-b3ae6754e681',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=qpid, version=7.1.0-SNAPSHOT, qpid.build=,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true,
sole-connection-detection-policy=0}}
[154612396:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] ->
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=[topic]},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[154612396:1] <-
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=copy, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:released:list,
amqp:rejected:list], capabilities=[topic]}, target=Target{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=[SHARED-SUBS], desiredCapabilities=null, properties={}}
[154612396:1] -> Flow{nextIncomingId=0, incomingWindow=2047, nextOutgoingId=1,
outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=1000,
available=null, drain=false, echo=false, properties=null}
[154612396:1] -> Detach{handle=0, closed=true, error=null}
[154612396:1] <-
[jira] [Updated] (QPID-8201) [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted twice during link close
[
https://issues.apache.org/jira/browse/QPID-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8201:
-
Affects Version/s: qpid-java-broker-7.0.4
> [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted twice
> during link close
> -
>
> Key: QPID-8201
> URL: https://issues.apache.org/jira/browse/QPID-8201
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.4
>Reporter: Keith Wall
>Priority: Major
>
> Running the following code using the Qpid JMS Client (I am using master) that
> creates a temporary topic subscription, exposes a defect in the Broker-J.
> Internally Broker-J is cleaning up the queue backing the temporary
> subscription twice. The second attempt fails, which causes the detach
> performative to carry a spurious {{error amqp:not-found.}}
> The Qpid JMS Client appears to ignore the error, so there may not be an
> impact to applications using this client. I have not checked other AMQP 1.0
> clients.
>
> {code:java}
> Context context = new InitialContext();
> ConnectionFactory factory = (ConnectionFactory)
> context.lookup("myFactoryLookup");
> Destination topic = (Destination) context.lookup("myTopicLookup");
> Connection connection = factory.createConnection(System.getProperty("USER"),
> System.getProperty("PASSWORD"));
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(topic);
> messageConsumer.close();{code}
>
> {noformat}
> [154612396:0] -> Open{
> containerId='ID:29fbab21-96a9-45a9-ba6d-05b1744b9ce3:1',
> hostname='localhost', maxFrameSize=1048576, channelMax=32767,
> idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container,
> DELAYED_DELIVERY, ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
> version=0.33.0-SNAPSHOT, platform=JVM: 1.8.0_171, 25.171-b10, Oracle
> Corporation, OS: Linux, 4.16.8-300.fc28.x86_64, amd64}}
> [154612396:0] <- Open{ containerId='a73d8803-f5bd-46c8-90d3-b3ae6754e681',
> hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
> outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
> sole-connection-for-container], desiredCapabilities=null,
> properties={product=qpid, version=7.1.0-SNAPSHOT, qpid.build=,
> qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true,
> sole-connection-detection-policy=0}}
> [154612396:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] ->
> Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
> handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> amqp:modified:list], capabilities=[topic]}, target=Target{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] <-
> Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=copy,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:released:list, amqp:rejected:list],
>
[jira] [Updated] (QPID-8201) [Broker-J] Queue backing temporary subscription deleted twice during link close
[
https://issues.apache.org/jira/browse/QPID-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8201:
-
Description:
Running the following code using the Qpid JMS Client (I am using master) that
creates a temporary topic subscription, exposes a defect in the Broker-J.
Internally Broker-J is cleaning up the queue backing the temporary subscription
twice. The second attempt fails, which causes the detach performative to carry
a spurious {{error amqp:not-found.}}
The Qpid JMS Client appears to ignore the error, so there may not be an impact
to applications using this client. I have not checked other AMQP 1.0 clients.
{code:java}
Context context = new InitialContext();
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
Destination topic = (Destination) context.lookup("myTopicLookup");
Connection connection = factory.createConnection(System.getProperty("USER"),
System.getProperty("PASSWORD"));
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer messageConsumer = session.createConsumer(topic);
messageConsumer.close();{code}
{noformat}
[154612396:0] -> Open{ containerId='ID:29fbab21-96a9-45a9-ba6d-05b1744b9ce3:1',
hostname='localhost', maxFrameSize=1048576, channelMax=32767,
idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container,
DELAYED_DELIVERY, ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
version=0.33.0-SNAPSHOT, platform=JVM: 1.8.0_171, 25.171-b10, Oracle
Corporation, OS: Linux, 4.16.8-300.fc28.x86_64, amd64}}
[154612396:0] <- Open{ containerId='a73d8803-f5bd-46c8-90d3-b3ae6754e681',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=qpid, version=7.1.0-SNAPSHOT, qpid.build=,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true,
sole-connection-detection-policy=0}}
[154612396:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] ->
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=[topic]},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[154612396:1] <-
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=copy, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:released:list,
amqp:rejected:list], capabilities=[topic]}, target=Target{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=[SHARED-SUBS], desiredCapabilities=null, properties={}}
[154612396:1] -> Flow{nextIncomingId=0, incomingWindow=2047, nextOutgoingId=1,
outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=1000,
available=null, drain=false, echo=false, properties=null}
[154612396:1] -> Detach{handle=0, closed=true, error=null}
[154612396:1] <- Detach{handle=0, closed=true,
[jira] [Updated] (QPID-8201) [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted twice during link close
[
https://issues.apache.org/jira/browse/QPID-8201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8201:
-
Summary: [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted
twice during link close (was: [Broker-J] Queue backing temporary subscription
deleted twice during link close)
> [Broker-J] [AMQP1.0] Queue backing temporary subscription deleted twice
> during link close
> -
>
> Key: QPID-8201
> URL: https://issues.apache.org/jira/browse/QPID-8201
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> Running the following code using the Qpid JMS Client (I am using master) that
> creates a temporary topic subscription, exposes a defect in the Broker-J.
> Internally Broker-J is cleaning up the queue backing the temporary
> subscription twice. The second attempt fails, which causes the detach
> performative to carry a spurious {{error amqp:not-found.}}
> The Qpid JMS Client appears to ignore the error, so there may not be an
> impact to applications using this client. I have not checked other AMQP 1.0
> clients.
>
> {code:java}
> Context context = new InitialContext();
> ConnectionFactory factory = (ConnectionFactory)
> context.lookup("myFactoryLookup");
> Destination topic = (Destination) context.lookup("myTopicLookup");
> Connection connection = factory.createConnection(System.getProperty("USER"),
> System.getProperty("PASSWORD"));
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(topic);
> messageConsumer.close();{code}
>
> {noformat}
> [154612396:0] -> Open{
> containerId='ID:29fbab21-96a9-45a9-ba6d-05b1744b9ce3:1',
> hostname='localhost', maxFrameSize=1048576, channelMax=32767,
> idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container,
> DELAYED_DELIVERY, ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
> version=0.33.0-SNAPSHOT, platform=JVM: 1.8.0_171, 25.171-b10, Oracle
> Corporation, OS: Linux, 4.16.8-300.fc28.x86_64, amd64}}
> [154612396:0] <- Open{ containerId='a73d8803-f5bd-46c8-90d3-b3ae6754e681',
> hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
> outgoingLocales=null, incomingLocales=null,
> offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
> sole-connection-for-container], desiredCapabilities=null,
> properties={product=qpid, version=7.1.0-SNAPSHOT, qpid.build=,
> qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true,
> sole-connection-detection-policy=0}}
> [154612396:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:0] <- Begin{remoteChannel=0, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
> incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] <- Begin{remoteChannel=1, nextOutgoingId=0,
> incomingWindow=8192, outgoingWindow=2048, handleMax=4294967295,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] ->
> Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
> handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null, messageAnnotations=null},
> outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list,
> amqp:modified:list], capabilities=[topic]}, target=Target{address='null',
> durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
> dynamicNodeProperties=null, capabilities=null}, unsettled=null,
> incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
> offeredCapabilities=null, desiredCapabilities=null, properties=null}
> [154612396:1] <-
> Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
> handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
> source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH,
> timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=copy,
> filter=null, defaultOutcome=Modified{deliveryFailed=true,
> undeliverableHere=null,
[jira] [Created] (QPID-8201) [Broker-J] Queue backing temporary subscription deleted twice during link close
Keith Wall created QPID-8201:
Summary: [Broker-J] Queue backing temporary subscription deleted
twice during link close
Key: QPID-8201
URL: https://issues.apache.org/jira/browse/QPID-8201
Project: Qpid
Issue Type: Bug
Components: Broker-J
Reporter: Keith Wall
Running the following code using the Qpid JMS Client (I am using master) that
creates a temporary topic subscription, exposes a defect in the Broker-J.
Internally Broker-J is cleaning up the queue backing the temporary subscription
twice. The second attempt fails, which causes the detach performative to carry
a spurious {{error amqp:not-found}}
{code:java}
Context context = new InitialContext();
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
Destination topic = (Destination) context.lookup("myTopicLookup");
Connection connection = factory.createConnection(System.getProperty("USER"),
System.getProperty("PASSWORD"));
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer messageConsumer = session.createConsumer(topic);
messageConsumer.close();{code}
{noformat}
[154612396:0] -> Open{ containerId='ID:29fbab21-96a9-45a9-ba6d-05b1744b9ce3:1',
hostname='localhost', maxFrameSize=1048576, channelMax=32767,
idleTimeOut=3, outgoingLocales=null, incomingLocales=null,
offeredCapabilities=null, desiredCapabilities=[sole-connection-for-container,
DELAYED_DELIVERY, ANONYMOUS-RELAY, SHARED-SUBS], properties={product=QpidJMS,
version=0.33.0-SNAPSHOT, platform=JVM: 1.8.0_171, 25.171-b10, Oracle
Corporation, OS: Linux, 4.16.8-300.fc28.x86_64, amd64}}
[154612396:0] <- Open{ containerId='a73d8803-f5bd-46c8-90d3-b3ae6754e681',
hostname='null', maxFrameSize=262144, channelMax=255, idleTimeOut=0,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, SHARED-SUBS,
sole-connection-for-container], desiredCapabilities=null,
properties={product=qpid, version=7.1.0-SNAPSHOT, qpid.build=,
qpid.instance_name=Broker, qpid.virtualhost_properties_supported=true,
sole-connection-detection-policy=0}}
[154612396:0] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:0] <- Begin{remoteChannel=0, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] -> Begin{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2047, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[154612396:1] <- Begin{remoteChannel=1, nextOutgoingId=0, incomingWindow=8192,
outgoingWindow=2048, handleMax=4294967295, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[154612396:1] ->
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=RECEIVER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=null, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:rejected:list,
amqp:released:list, amqp:modified:list], capabilities=[topic]},
target=Target{address='null', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[154612396:1] <-
Attach{name='qpid-jms:receiver:ID:1537beab-fd64-4d97-ae27-3b888ee072a6:1:1:1:foo',
handle=0, role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='foo', durable=NONE, expiryPolicy=LINK_DETACH, timeout=0,
dynamic=false, dynamicNodeProperties=null, distributionMode=copy, filter=null,
defaultOutcome=Modified{deliveryFailed=true, undeliverableHere=null,
messageAnnotations=null}, outcomes=[amqp:accepted:list, amqp:released:list,
amqp:rejected:list], capabilities=[topic]}, target=Target{address='null',
durable=NONE, expiryPolicy=SESSION_END, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled={},
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=[SHARED-SUBS], desiredCapabilities=null, properties={}}
[154612396:1] -> Flow{nextIncomingId=0, incomingWindow=2047, nextOutgoingId=1,
outgoingWindow=2147483647, handle=0, deliveryCount=0, linkCredit=1000,
available=null, drain=false, echo=false, properties=null}
[154612396:1] -> Detach{handle=0, closed=true, error=null}
[154612396:1] <- Detach{handle=0,
[jira] [Created] (DISPATCH-1020) Detach expiring links with closed=true when peer connectivity lost
Keith Wall created DISPATCH-1020:
Summary: Detach expiring links with closed=true when peer
connectivity lost
Key: DISPATCH-1020
URL: https://issues.apache.org/jira/browse/DISPATCH-1020
Project: Qpid Dispatch
Issue Type: Improvement
Reporter: Keith Wall
Currently, Dispatch responds to the loss of an underlying connection to a peer
by detaching the links established over that connection in the following way.
{noformat}
@detach(22) [handle=0, closed=false, error=@error(29)
[condition=:"qd:routed-link-lost", description="Connectivity to the peer
container was lost”]]
{noformat}
As is makes no sense for link defined to expire to attached again, it would be
an improvement to the dispatch's behaviour if those links were detached with
{{closed=true}}. This would aid the timely clean-up of resources elsewhere in
the AMQP network.
--
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-8139) [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or JMSCorrelationID expressed using the AMQP type encoded form values fail to select target message
[
https://issues.apache.org/jira/browse/QPID-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16492167#comment-16492167
]
Keith Wall commented on QPID-8139:
--
I don't think the commit at {{f1ce866}} solves the problem. It has the 0-10
and 0-9 AMQMessageHeader implementations returning stringified messages ids
(i..e. MessageTransferHeader#getMessageId and getCorrelationId return Strings
rather than Objects), which will mean an AMQP 1.0 consumer selecting an AMQP
0-10 or 0-9 message with an messageId/correlationId predicate won't work.
I'll put an alternative together to illustrate my idea. I think {{f1ce866}}
should be reverted.
> [Broker-J] [AMQP1-0] [JMSBINDMAP] JMS selectors using JMSMessageID or
> JMSCorrelationID expressed using the AMQP type encoded form values fail to
> select target message
> ---
>
> Key: QPID-8139
> URL: https://issues.apache.org/jira/browse/QPID-8139
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8139-Broker-J-AMQP-1.0-Make-sure-that-selector-.patch
>
>
> When using the Qpid JMS AMQP 1.0 Client with Broker-J, if the consumer
> specifies a JMS message selectors including a {{JMSMessageID}} or
> {{JMSCorrelationID}} predicate, the selector can fail to find the target
> message in some circumstances. This occurs when the message producer is
> configured to use one of the following {{jms.messageIDPolicy.messageIDType}}
> modes: {{UUID}}. {{UUID_STRING}}, {{PREFIXED_UUID_STRING}}. In the default
> mode, {{BUILTIN}} the problem does not manifest.
> The issue is the Broker-J JMS selector implementation does not understand the
> AMQP type encoded forms specified by 3.2.1.1 of the Advanced Message Queuing
> Protocol (AMQP) JMS Mapping Version 1.0 [WD9].
> The problem also manifests when the Broker's message conversion feature is in
> use. For instance, a message produced by a AMQP 0-10 producer cannot be
> selected by an consumer using a Qpid JMS Client 1.0 using a {{JMSMessageID}}
> or {{JMSCorrelationID}} predicate. This was originally highlighted by the
> following user list post:
> http://qpid.2158936.n2.nabble.com/JMSMessageID-differences-in-JMS-0-30-0-and-JMS-AMQP-0-x-6-3-0-clients-td7674019.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] [Updated] (QPID-8194) [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
[
https://issues.apache.org/jira/browse/QPID-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8194:
-
Status: Reviewable (was: In Progress)
> [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
> -
>
> Key: QPID-8194
> URL: https://issues.apache.org/jira/browse/QPID-8194
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> The following two TransferTests fail consistently on Windows,.
> * TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries
> * TransferTest.receiveMultipleDeliveries
> In both cases, the tests fail as the latest delivery is decoded by the test
> harness. The tests fail in the same way on Appveyor and virtualised Windows
> 7 Enterprise.
> This could either be a bug in the test harness or production code, or both.
> [https://ci.appveyor.com/project/ApacheSoftwareFoundation/qpid-broker-j/build/45]
>
> {noformat}
> org.apache.qpid.server.protocol.v1_0.type.AmqpErrorException: Invalid
> Message: Expected type "section" but found "UnsignedInteger"
> at
> org.apache.qpid.server.protocol.v1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:62)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.parse(MessageDecoder.java:86)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.getData(MessageDecoder.java:171)
> at
> org.apache.qpid.tests.protocol.v1_0.Interaction.decodeLatestDelivery(Interaction.java:1084)
> at
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries(TransferTest.java:1072)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8194) [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
[
https://issues.apache.org/jira/browse/QPID-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8194:
-
Priority: Minor (was: Major)
> [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
> -
>
> Key: QPID-8194
> URL: https://issues.apache.org/jira/browse/QPID-8194
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> The following two TransferTests fail consistently on Windows,.
> * TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries
> * TransferTest.receiveMultipleDeliveries
> In both cases, the tests fail as the latest delivery is decoded by the test
> harness. The tests fail in the same way on Appveyor and virtualised Windows
> 7 Enterprise.
> This could either be a bug in the test harness or production code, or both.
> [https://ci.appveyor.com/project/ApacheSoftwareFoundation/qpid-broker-j/build/45]
>
> {noformat}
> org.apache.qpid.server.protocol.v1_0.type.AmqpErrorException: Invalid
> Message: Expected type "section" but found "UnsignedInteger"
> at
> org.apache.qpid.server.protocol.v1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:62)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.parse(MessageDecoder.java:86)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.getData(MessageDecoder.java:171)
> at
> org.apache.qpid.tests.protocol.v1_0.Interaction.decodeLatestDelivery(Interaction.java:1084)
> at
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries(TransferTest.java:1072)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8194) [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
[
https://issues.apache.org/jira/browse/QPID-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-8194:
Assignee: Keith Wall
> [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
> -
>
> Key: QPID-8194
> URL: https://issues.apache.org/jira/browse/QPID-8194
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
>
> The following two TransferTests fail consistently on Windows,.
> * TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries
> * TransferTest.receiveMultipleDeliveries
> In both cases, the tests fail as the latest delivery is decoded by the test
> harness. The tests fail in the same way on Appveyor and virtualised Windows
> 7 Enterprise.
> This could either be a bug in the test harness or production code, or both.
> [https://ci.appveyor.com/project/ApacheSoftwareFoundation/qpid-broker-j/build/45]
>
> {noformat}
> org.apache.qpid.server.protocol.v1_0.type.AmqpErrorException: Invalid
> Message: Expected type "section" but found "UnsignedInteger"
> at
> org.apache.qpid.server.protocol.v1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:62)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.parse(MessageDecoder.java:86)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.getData(MessageDecoder.java:171)
> at
> org.apache.qpid.tests.protocol.v1_0.Interaction.decodeLatestDelivery(Interaction.java:1084)
> at
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries(TransferTest.java:1072)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-8181. -- Resolution: Fixed > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 > > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port
[ https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16488068#comment-16488068 ] Keith Wall commented on QPID-8181: -- Changes look reasonable to me. > [Broker-J] Add statistics for a total number of connections established on > AMQP port > > > Key: QPID-8181 > URL: https://issues.apache.org/jira/browse/QPID-8181 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4 > > > A statistics for a current number of connections is available on AMQP port. > Introduction of additional statistic for a total number of connections > established on AMQP port would allow to detect such use cases as "connection > per message anti-pattern" without even looking into Qpid broker logs. -- 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-7153) Allow expired messages to be sent to DLQ
[
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483705#comment-16483705
]
Keith Wall commented on QPID-7153:
--
One comment. If as a user I want the expired messages that that land on the
DLQ to live indefinitely, then I would have expected to set the the DLQ's
{{minimumMessageTtl}} to {{Long.MAX_VALUE}}. This doesn't work because the
long arithmetic overflows within {{AbstactQueue#calculateExpiration}} and
{{wouldExpire}} (which would be better named wouldExpireNow) returns the wrong
value. Perhaps {{calculateExpiration}} should use {{Math.addExact}} and clamp
the value if ArithmeticException occurs.
Separately, largely note to self, when testing this feature with the Qpid JMS
Client, one needs to remember to turn off {{jms.localMessageExpiry}} otherwise
the client expires the message as it is consumed from the DLQ.
> Allow expired messages to be sent to DLQ
>
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Attachments: QPID-7153v2.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The
> behaviour should be configurable and allow for expired messages to be
> directed to the alternate exchange to allow for dead-lettering.
--
This message was sent by Atlassian JIRA
(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-8194) [Protocol Tests] [AMQP 1.0] TransferTests seens to fail on Windows
[
https://issues.apache.org/jira/browse/QPID-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8194:
-
Summary: [Protocol Tests] [AMQP 1.0] TransferTests seens to fail on Windows
(was: [Protocol Tests] [AMQP 1.0] TransferTests seems to fail on Windows)
> [Protocol Tests] [AMQP 1.0] TransferTests seens to fail on Windows
> --
>
> Key: QPID-8194
> URL: https://issues.apache.org/jira/browse/QPID-8194
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The following two TransferTests fail consistently on Windows,.
> * TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries
> * TransferTest.receiveMultipleDeliveries
> In both cases, the tests fail as the latest delivery is decoded by the test
> harness. The tests fail in the same way on Appveyor and virtualised Windows
> 7 Enterprise.
> This could either be a bug in the test harness or production code, or both.
> [https://ci.appveyor.com/project/ApacheSoftwareFoundation/qpid-broker-j/build/45]
>
> {noformat}
> org.apache.qpid.server.protocol.v1_0.type.AmqpErrorException: Invalid
> Message: Expected type "section" but found "UnsignedInteger"
> at
> org.apache.qpid.server.protocol.v1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:62)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.parse(MessageDecoder.java:86)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.getData(MessageDecoder.java:171)
> at
> org.apache.qpid.tests.protocol.v1_0.Interaction.decodeLatestDelivery(Interaction.java:1084)
> at
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries(TransferTest.java:1072)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8194) [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
[
https://issues.apache.org/jira/browse/QPID-8194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8194:
-
Summary: [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
(was: [Protocol Tests] [AMQP 1.0] TransferTests seens to fail on Windows)
> [Protocol Tests] [AMQP 1.0] TransferTests seen to fail on Windows
> -
>
> Key: QPID-8194
> URL: https://issues.apache.org/jira/browse/QPID-8194
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
>
> The following two TransferTests fail consistently on Windows,.
> * TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries
> * TransferTest.receiveMultipleDeliveries
> In both cases, the tests fail as the latest delivery is decoded by the test
> harness. The tests fail in the same way on Appveyor and virtualised Windows
> 7 Enterprise.
> This could either be a bug in the test harness or production code, or both.
> [https://ci.appveyor.com/project/ApacheSoftwareFoundation/qpid-broker-j/build/45]
>
> {noformat}
> org.apache.qpid.server.protocol.v1_0.type.AmqpErrorException: Invalid
> Message: Expected type "section" but found "UnsignedInteger"
> at
> org.apache.qpid.server.protocol.v1_0.messaging.SectionDecoderImpl.parseAll(SectionDecoderImpl.java:62)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.parse(MessageDecoder.java:86)
> at
> org.apache.qpid.tests.protocol.v1_0.MessageDecoder.getData(MessageDecoder.java:171)
> at
> org.apache.qpid.tests.protocol.v1_0.Interaction.decodeLatestDelivery(Interaction.java:1084)
> at
> org.apache.qpid.tests.protocol.v1_0.messaging.TransferTest.receiveMixtureOfTransactionalAndNonTransactionalDeliveries(TransferTest.java:1072)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70){noformat}
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8195) [Broker-J] Improve AmqpErrorException#toString
[
https://issues.apache.org/jira/browse/QPID-8195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-8195:
Assignee: Keith Wall
> [Broker-J] Improve AmqpErrorException#toString
> --
>
> Key: QPID-8195
> URL: https://issues.apache.org/jira/browse/QPID-8195
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
>
> The {{AmqpErrorException#toString}} does not include the details of the
> underlying {{Error}} which impedes problem resolution.
--
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
