[jira] [Commented] (QPID-8119) Create a standalone web management console (WMC)
[ https://issues.apache.org/jira/browse/QPID-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16391246#comment-16391246 ] Lorenz Quack commented on QPID-8119: A while ago I started a small proof of concept to demonstrate how we could implement a standalone WMC using angularJS 1. My attempt at using angularJS 2 failed quite miserably due to my inability to wrap my head around all the boilerplate, transpiling, and auxiliary tools and libs.I have not touched the code since I gave the demo at work in 2016. However, I thought that experiment might be useful in case someone ever wants to pursue something in this direction. So I just zipped it up and attached it here just as it was lying around on my disk without and cleanup (well, I did delete the "node_modules" and "bower_components" directories) or instructions. sorry. I had no prior experience with angularJS and the JS ecosystem so I am sure there are nicer and more idiomatic ways of doing things. It is what it is. I'll leave it at that. Do with the code as you will: Release, Relicense, Laugh at, Rip apart, Put back together again, Burn in a pyre, completely ignore, ... all are fair game and hereby explicitly permitted! > Create a standalone web management console (WMC) > > > Key: QPID-8119 > URL: https://issues.apache.org/jira/browse/QPID-8119 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Lorenz Quack >Priority: Minor > Attachments: qpid_wmc_ajs.tar.bz2 > > > For several reasons having a standalone web management console (WMC) might be > desirable: > * separation of concerns > * sepatate development and release cycles > * standalone WMC could connect to multiple brokers/virtualhosts (maybe even > non-qpid broker) > * standalone WMC available when broker is down (restarts) > * ... -- 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-8119) Create a standalone web management console (WMC)
[ https://issues.apache.org/jira/browse/QPID-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8119: --- Attachment: qpid_wmc_ajs.tar.bz2 > Create a standalone web management console (WMC) > > > Key: QPID-8119 > URL: https://issues.apache.org/jira/browse/QPID-8119 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Lorenz Quack >Priority: Minor > Attachments: qpid_wmc_ajs.tar.bz2 > > > For several reasons having a standalone web management console (WMC) might be > desirable: > * separation of concerns > * sepatate development and release cycles > * standalone WMC could connect to multiple brokers/virtualhosts (maybe even > non-qpid broker) > * standalone WMC available when broker is down (restarts) > * ... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8119) Create a standalone web management console (WMC)
Lorenz Quack created QPID-8119: -- Summary: Create a standalone web management console (WMC) Key: QPID-8119 URL: https://issues.apache.org/jira/browse/QPID-8119 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Lorenz Quack For several reasons having a standalone web management console (WMC) might be desirable: * separation of concerns * sepatate development and release cycles * standalone WMC could connect to multiple brokers/virtualhosts (maybe even non-qpid broker) * standalone WMC available when broker is down (restarts) * ... -- 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-8045) [Broker-J] Refactor context variables
[
https://issues.apache.org/jira/browse/QPID-8045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-8045:
---
Attachment: QPID-8045_contextVars_WIP.tar.gz
This is an old attempt of mine at refactoring the context variables. The patch
has not been updated in a while.
General approach I took:
* Declare a getter method on the interface and annotate it.
* The annotation carries the default value, the name, and a description.
* Annotation processing then auto-generates a subclass with a variable for the
materialized value (the type can be deduced from the getter's return type), the
implementation of the getter, and a postResolve to materialize the context
variable.
* all code should be using the getter and not refer to the materialized value
directly nor use {{getContextValue()}}. This is why I chose to annotate getter
methods rather than the default value.
Some problems I encountered with the above approach and which have not been
addressed yet in the patch:
* The developer written implementation (as opposed to the auto generated one)
needs to have a stub for the method or be declare abstract.
* Since the materialization happens in the auto-generated subclasses the
dev-written implementations are not fully functional. This is mainly a problem
for testing. The tests would have to subclass the tests in question and mock
the getters for the context variables.
> [Broker-J] Refactor context variables
> -
>
> Key: QPID-8045
> URL: https://issues.apache.org/jira/browse/QPID-8045
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Lorenz Quack
> Attachments: QPID-8045_contextVars_WIP.tar.gz
>
>
> Context variables are heavily used in Qpid Broker-J.
> Over the years their implementation and use has grown organically.
> Maybe it is time they are refactored.
> Some reasons for considering a refactor:
> * boilerplate: Currently a context variable requires quite a lot of
> boilerplate code. A variable for the name and the {{\@ManagedContextDefault}}
> annotated default value, a {{\@DerivedAttribute}} annotated getter for the
> materialized value, a variable to hold the materialized value, the code to
> materialize the context variable.
> * inconsistency: Some context variables are materialized others aren't
> (i.e., change takes effect after restart vs immediately). The point of
> materialization is inconsistent (popular choices being {{onOpen}} and
> {{postResolve}}). Some expose the materialized value through a
> {{\@DerivedAttribute}} others do not. The names of the context variables are
> sometimes directly on the scattered around {{\@ManagedContextDefault}}
> sometimes on a separate variable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8045) [Broker-J] Refactor context variables
Lorenz Quack created QPID-8045:
--
Summary: [Broker-J] Refactor context variables
Key: QPID-8045
URL: https://issues.apache.org/jira/browse/QPID-8045
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Lorenz Quack
Context variables are heavily used in Qpid Broker-J.
Over the years their implementation and use has grown organically.
Maybe it is time they are refactored.
Some reasons for considering a refactor:
* boilerplate: Currently a context variable requires quite a lot of
boilerplate code. A variable for the name and the {{\@ManagedContextDefault}}
annotated default value, a {{\@DerivedAttribute}} annotated getter for the
materialized value, a variable to hold the materialized value, the code to
materialize the context variable.
* inconsistency: Some context variables are materialized others aren't (i.e.,
change takes effect after restart vs immediately). The point of materialization
is inconsistent (popular choices being {{onOpen}} and {{postResolve}}). Some
expose the materialized value through a {{\@DerivedAttribute}} others do not.
The names of the context variables are sometimes directly on the scattered
around {{\@ManagedContextDefault}} sometimes on a separate variable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8039) [Broker-J] Placeholder
[ https://issues.apache.org/jira/browse/QPID-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack closed QPID-8039. -- Resolution: Won't Fix > [Broker-J] Placeholder > -- > > Key: QPID-8039 > URL: https://issues.apache.org/jira/browse/QPID-8039 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: 0.32 >Reporter: Lorenz Quack > > To be filled in later. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8039) [Broker-J] Placeholder
Lorenz Quack created QPID-8039: -- Summary: [Broker-J] Placeholder Key: QPID-8039 URL: https://issues.apache.org/jira/browse/QPID-8039 Project: Qpid Issue Type: Bug Components: Broker-J Affects Versions: 0.32 Reporter: Lorenz Quack To be filled in later. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8031) [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0
[ https://issues.apache.org/jira/browse/QPID-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8031: --- Attachment: 0001-QPID-8031-Broker-J-System-Tests-Bump-version-of-AMQP.patch The bump requires a small change to a test class. Also the client version fixes some bugs which allows us to enable some conversion tests. See attached patch. > [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0 > - > > Key: QPID-8031 > URL: https://issues.apache.org/jira/browse/QPID-8031 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack >Priority: Minor > Attachments: > 0001-QPID-8031-Broker-J-System-Tests-Bump-version-of-AMQP.patch > > > When the 6.3.0 client is released we should bump the version in the broker. > Eventually the broker system tests should become independent of the specific > client version. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8031) [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0
[ https://issues.apache.org/jira/browse/QPID-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8031: --- Priority: Minor (was: Major) > [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0 > - > > Key: QPID-8031 > URL: https://issues.apache.org/jira/browse/QPID-8031 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack >Priority: Minor > > When the 6.3.0 client is released we should bump the version in the broker. > Eventually the broker system tests should become independent of the specific > client version. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8031) [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0
Lorenz Quack created QPID-8031: -- Summary: [Broker-J, System Tests] Bump version of AMQP 0-x client to 6.3.0 Key: QPID-8031 URL: https://issues.apache.org/jira/browse/QPID-8031 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Lorenz Quack When the 6.3.0 client is released we should bump the version in the broker. Eventually the broker system tests should become independent of the specific client version. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8030) [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId
[ https://issues.apache.org/jira/browse/QPID-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8030: --- Fix Version/s: qpid-java-broker-7.0.1 > [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary > correlationId > -- > > Key: QPID-8030 > URL: https://issues.apache.org/jira/browse/QPID-8030 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.1 > > > In AMQP 0-8..9 the message correlation Id can be either a String or byte[]. > AMQP 1.0 supports both of those formats so the conversion should preserve > those. > Currently the conversion always converts to String. In case the byte[] are > non-UTF_8 substitution characters are used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8030) [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId
Lorenz Quack created QPID-8030: -- Summary: [Broker-J] Message conversion from 0-8 to 1.0 should preserve binary correlationId Key: QPID-8030 URL: https://issues.apache.org/jira/browse/QPID-8030 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack In AMQP 0-8..9 the message correlation Id can be either a String or byte[]. AMQP 1.0 supports both of those formats so the conversion should preserve those. Currently the conversion always converts to String. In case the byte[] are non-UTF_8 substitution characters are used. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out
[
https://issues.apache.org/jira/browse/QPID-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-8018:
---
Status: Reviewable (was: In Progress)
> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did
> not respond in time. It might be that the client JVM was garbage collecting
> and did not execute anything which resulted in a timeout, it might be a
> network issue, and finally it also might be the server not responding in a
> timely fashion.
> The error message should be clarified to more clearly express the actual
> problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7898) [Java 0-8...0-9-1 Client] Calling getJMSReplyTo on a received message can lead to NullPointerException
[
https://issues.apache.org/jira/browse/QPID-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244276#comment-16244276
]
Lorenz Quack commented on QPID-7898:
Fun fact: if this problem is solved the next one pops right out: All calls to
the {{NonBURLReplyToDestination}} constructor fail in {{AMQDestination:381}}
because we pass in {{null}} as the {{exchangeClass}} in
{{AMQMessageDelegate_0_8.NonBURLReplyToDestination#NonBURLReplyToDestination}}.
> [Java 0-8...0-9-1 Client] Calling getJMSReplyTo on a received message can
> lead to NullPointerException
> --
>
> Key: QPID-7898
> URL: https://issues.apache.org/jira/browse/QPID-7898
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> A call to {{Message#getJMSReplyTo()}} can lead to a {{NullPointerException}}.
> {noformat}java.lang.NullPointerException
> at
> org.apache.qpid.client.message.AMQMessageDelegate_0_8.getJMSReplyTo(AMQMessageDelegate_0_8.java:301)
> at
> org.apache.qpid.client.message.AbstractJMSMessage.getJMSReplyTo(AbstractJMSMessage.java:104){noformat}
> The circumstances are
> * a Message received over AMQP 0-8...0-9-1
> * the replyTo set to a non-BURL address not containing a slash ("/")
> The code throwing the NPE:
> {code:title=AMQMessageDelegate_0_8#getJMSReplyTo (slightly edited for
> clarity)}public Destination getJMSReplyTo() throws JMSException
> {
> String replyToEncoding =
> getContentHeaderProperties().getReplyToAsString();
> Destination dest;
> try {
> BindingURL binding = new AMQBindingURL(replyToEncoding);
> // something else
> } catch (URISyntaxException e) {
> if (replyToEncoding.startsWith("/")) {
> // something
> } else if (replyToEncoding.contains("/")) {
> // something
> } else if (getAMQSession().isQueueBound(replyToEncoding, null, null))
> {
> // THE ABOVE CALL TO getAMQSession THROWS A NPE!!!
> } else {
> // something
> }
> }
> return dest;
> }{code}
> The root cause seems to be that we are relying on the Message having
> knowledge of the session but we aren't setting the Session on the Message on
> all code paths.
> I encountered this testing message conversion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out
[
https://issues.apache.org/jira/browse/QPID-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-8018:
--
Assignee: (was: Lorenz Quack)
> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did
> not respond in time. It might be that the client JVM was garbage collecting
> and did not execute anything which resulted in a timeout, it might be a
> network issue, and finally it also might be the server not responding in a
> timely fashion.
> The error message should be clarified to more clearly express the actual
> problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out
[
https://issues.apache.org/jira/browse/QPID-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-8018:
--
Assignee: Lorenz Quack
> [Java Client, AMQP 0-x] Clarify error message when connection times out
> ---
>
> Key: QPID-8018
> URL: https://issues.apache.org/jira/browse/QPID-8018
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> In certain circumstances the client throws a {{AMQTimeoutException}} with the
> error message {{"Server did not respond in a timely fashion"}}.
> This error message is misleading. It is not necessarily the server who did
> not respond in time. It might be that the client JVM was garbage collecting
> and did not execute anything which resulted in a timeout, it might be a
> network issue, and finally it also might be the server not responding in a
> timely fashion.
> The error message should be clarified to more clearly express the actual
> problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8017) [Broker-J] [BDB] JE log events written at JUL level FINE and below not included in the log produced by a BrokerLogger
[
https://issues.apache.org/jira/browse/QPID-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244104#comment-16244104
]
Lorenz Quack commented on QPID-8017:
Have you looked at
[LevelChangePropagator|https://logback.qos.ch/manual/configuration.html#LevelChangePropagator]?
> [Broker-J] [BDB] JE log events written at JUL level FINE and below not
> included in the log produced by a BrokerLogger
> --
>
> Key: QPID-8017
> URL: https://issues.apache.org/jira/browse/QPID-8017
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Minor
>
> Reproduction:
> * Add {{NameAndLevel}} logger inclusion rule BrokerLogger {{file}} for source
> {{com.sleepycat.je.*}} with Level.ALL
> * Add a BDB HA VHN/VHN
> * Expected behaviour: verbose logging from JE. Actual behaviour: moderate
> logging only
> For instance, JE writes the following message at {{FINE}} which should be
> logged by the handler as {{TRACE}} but it is absent.
> {noformat}
> 2017-11-07 10:42:15,467 TRACE [Cleaner-1] (c.s.j.c.UtilizationCalculator) -
> [default] Clean file none: predicted min util is below minUtilization,
> current util min: 20 max: 20, predicted util min: 20 max: 20
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7897) [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously first converts to string before retreiving bytes
[
https://issues.apache.org/jira/browse/QPID-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7897:
--
Assignee: Lorenz Quack
> [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously
> first converts to string before retreiving bytes
>
>
> Key: QPID-7897
> URL: https://issues.apache.org/jira/browse/QPID-7897
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> If the correlationId of a message does not contain valid UTF_8 (e.g., set via
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}}) then
> {{javax.jms.Message#getJMSCorrelationIDAsBytes}} does not return the correct
> value.
> Some relevant code
> snippets:{{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} is implemented
> as follows:
> {code:title=AMQMessageDelegate_0_8.java}public byte[]
> getJMSCorrelationIDAsBytes() throws JMSException
> {
> return getContentHeaderProperties().getCorrelationIdAsString().getBytes();
> }{code}
> {code:title=BasicContentHeaderProperties}public String
> getCorrelationIdAsString()
> {
> return (_correlationId == null) ? null : _correlationId.toString();
> }{code}
> {code:title=AMQShortString}public String toString()
> {
> if (_asString == null)
> {
> _asString = new String(_data, _offset, _length,
> StandardCharsets.UTF_8);
> }
> return _asString;
> }{code}
> If {{_data}} does not contain valid UTF_8 the result of this call chain is
> incorrect.
> I do not see a reason why
> {{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} should not return
> {{getContentHeaderProperties().getCorrelationId().getBytes()}} instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string
[
https://issues.apache.org/jira/browse/QPID-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7899:
--
Assignee: Lorenz Quack
> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding
> (in which case why would you use this method in the first place), this is
> wrong.
> In the JMS API implementation of
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and
> it explicitly allows the provider to throw
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw
> {{UnsupportedOperationException}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7897) [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously first converts to string before retreiving bytes
[
https://issues.apache.org/jira/browse/QPID-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7897:
---
Status: Reviewable (was: In Progress)
> [Java 0-8...0-9-1 Client] Message#getJMSCorrelationIDAsBytes() erroneously
> first converts to string before retreiving bytes
>
>
> Key: QPID-7897
> URL: https://issues.apache.org/jira/browse/QPID-7897
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> If the correlationId of a message does not contain valid UTF_8 (e.g., set via
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}}) then
> {{javax.jms.Message#getJMSCorrelationIDAsBytes}} does not return the correct
> value.
> Some relevant code
> snippets:{{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} is implemented
> as follows:
> {code:title=AMQMessageDelegate_0_8.java}public byte[]
> getJMSCorrelationIDAsBytes() throws JMSException
> {
> return getContentHeaderProperties().getCorrelationIdAsString().getBytes();
> }{code}
> {code:title=BasicContentHeaderProperties}public String
> getCorrelationIdAsString()
> {
> return (_correlationId == null) ? null : _correlationId.toString();
> }{code}
> {code:title=AMQShortString}public String toString()
> {
> if (_asString == null)
> {
> _asString = new String(_data, _offset, _length,
> StandardCharsets.UTF_8);
> }
> return _asString;
> }{code}
> If {{_data}} does not contain valid UTF_8 the result of this call chain is
> incorrect.
> I do not see a reason why
> {{AMQMessageDelegate_0_8#getJMSCorrelationIDAsBytes}} should not return
> {{getContentHeaderProperties().getCorrelationId().getBytes()}} instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string
[
https://issues.apache.org/jira/browse/QPID-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7899:
--
Assignee: (was: Lorenz Quack)
> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding
> (in which case why would you use this method in the first place), this is
> wrong.
> In the JMS API implementation of
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and
> it explicitly allows the provider to throw
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw
> {{UnsupportedOperationException}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7899) [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously converts the bytes to string
[
https://issues.apache.org/jira/browse/QPID-7899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7899:
---
Status: Reviewable (was: In Progress)
> [Java 0-8...0-9-1 Client] Message#setJMSCorrelationIDAsBytes() erroneously
> converts the bytes to string
> ---
>
> Key: QPID-7899
> URL: https://issues.apache.org/jira/browse/QPID-7899
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The client converts the {{byte[]}} passed in to
> {{javax.jms.Message#setJMSCorrelationIDAsBytes}} to a String via {{new
> String(bytes);}}.
> If the bytes are not the encoding of a String in the current default encoding
> (in which case why would you use this method in the first place), this is
> wrong.
> In the JMS API implementation of
> {{setJMSCorrelationIDAsBytes()/getJMSCorrelationIDAsBytes()}} is optional and
> it explicitly allows the provider to throw
> {{java.lang.UnsupportedOperationException}}.
> We should either pack the raw bytes into the {{AMQShortString}} or throw
> {{UnsupportedOperationException}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7964: --- Status: Reviewable (was: In Progress) > [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and > "," for passwords > --- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack >Assignee: Lorenz Quack > Fix For: qpid-java-client-0-x-6.3.0 > > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7964: -- Assignee: Lorenz Quack > [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and > "," for passwords > --- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack >Assignee: Lorenz Quack > Fix For: qpid-java-client-0-x-6.3.0 > > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7964: -- Assignee: (was: Lorenz Quack) > [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and > "," for passwords > --- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack > Fix For: qpid-java-client-0-x-6.3.0 > > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243818#comment-16243818 ] Lorenz Quack commented on QPID-7964: The fix and tests were adapted from QPIDJMS-335 > [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and > "," for passwords > --- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack > Fix For: qpid-java-client-0-x-6.3.0 > > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8022) [Broker-J, WMC] When the session ends (timeout, broker goes away, connection lost) the UI should cearly indicate this
[
https://issues.apache.org/jira/browse/QPID-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243742#comment-16243742
]
Lorenz Quack commented on QPID-8022:
One possibility would be to redirect to the login page directly and add the
possibility to display an error there to indicate why the user ended up at the
login page. For example
* Failed login: Login failed. Try again.
* Authorization failed: Not authorized to log in to this broker. Try other
credentials.
* Session timeout: Previous session timed out. Please re-authenticate by
logging in again.
* Connection lost (could be broker crash): Connection to the broker was lost.
Fix the problem and try logging in again.
> [Broker-J, WMC] When the session ends (timeout, broker goes away, connection
> lost) the UI should cearly indicate this
> -
>
> Key: QPID-8022
> URL: https://issues.apache.org/jira/browse/QPID-8022
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>
> Currently when the http session ends (for example when the configured
> {{qpid.port.http.absoluteSessionTimeout}} expires) the Web Management Console
> (WMC) displays a dialogue box (with a generic 401 error in this case)
> offering a button to log in again.
> However, the dialogue box is closable. If the user closes it the WMC remains
> somewhat usable. All client-side operations continue to work (e.g., create a
> Query). Some operations fail silently (e.g., retrieving data when opening a
> new tab by double clicking on, for example, a Port) and yet other operations
> redisplay the 401 dialogue (e.g., broker-side operations involving POST or
> PUT).
> I think when the user is no longer logged in the WMC should clearly indicate
> this by somehow preventing all further use of the WMC. From a security point
> of view we also want the existing data currently being displayed to disappear.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8022) [Broker-J, WMC] When the session ends (timeout, broker goes away, connection lost) the UI should cearly indicate this
Lorenz Quack created QPID-8022:
--
Summary: [Broker-J, WMC] When the session ends (timeout, broker
goes away, connection lost) the UI should cearly indicate this
Key: QPID-8022
URL: https://issues.apache.org/jira/browse/QPID-8022
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Lorenz Quack
Currently when the http session ends (for example when the configured
{{qpid.port.http.absoluteSessionTimeout}} expires) the Web Management Console
(WMC) displays a dialogue box (with a generic 401 error in this case) offering
a button to log in again.
However, the dialogue box is closable. If the user closes it the WMC remains
somewhat usable. All client-side operations continue to work (e.g., create a
Query). Some operations fail silently (e.g., retrieving data when opening a new
tab by double clicking on, for example, a Port) and yet other operations
redisplay the 401 dialogue (e.g., broker-side operations involving POST or PUT).
I think when the user is no longer logged in the WMC should clearly indicate
this by somehow preventing all further use of the WMC. From a security point
of view we also want the existing data currently being displayed to disappear.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8018) [Java Client, AMQP 0-x] Clarify error message when connection times out
Lorenz Quack created QPID-8018:
--
Summary: [Java Client, AMQP 0-x] Clarify error message when
connection times out
Key: QPID-8018
URL: https://issues.apache.org/jira/browse/QPID-8018
Project: Qpid
Issue Type: Improvement
Components: Java Client
Reporter: Lorenz Quack
Priority: Minor
In certain circumstances the client throws a {{AMQTimeoutException}} with the
error message {{"Server did not respond in a timely fashion"}}.
This error message is misleading. It is not necessarily the server who did not
respond in time. It might be that the client JVM was garbage collecting and did
not execute anything which resulted in a timeout, it might be a network issue,
and finally it also might be the server not responding in a timely fashion.
The error message should be clarified to more clearly express the actual
problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7998) [Broker-J] Disable global shared durable subscriptions by default
[ https://issues.apache.org/jira/browse/QPID-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7998: --- Attachment: 0001-QPID-7998-Broker-J-AMQP-1.0-By-default-allow-global-.patch After further deliberation we consider enabling global shared durable subscriptions and instead bend the AMQP 1.0 spec in this case to avoid the leakage of links in the link registry. The attached patch allows global shared durable subscriptions but removes the associated links from the registry upon detach for all but a single link ending in "|global" to facilitate the closing detach which signals the JMS unsubscribe to the broker. > [Broker-J] Disable global shared durable subscriptions by default > - > > Key: QPID-7998 > URL: https://issues.apache.org/jira/browse/QPID-7998 > Project: Qpid > Issue Type: Task > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7998-Broker-J-AMQP-1.0-By-default-allow-global-.patch > > > As stated in [1] global shared durable subscriptions can cause an > accumulation of subscription links in link registry. The Broker-J currently > does not have any functionality for automatic removal of old links. Thus, for > v7 the global shared durable subscriptions need to be disabled. If feature is > required, it can be enabled but application would need to unsusbcribe from > shared durable subscriptions periodically or call Virtual Host operation > "purgeLinkRegistry" in order to avoid links accumulation with time. > [1] > https://lists.apache.org/thread.html/729cc17a8b0892d414f456f635ee435e7efeadd14e9123d84e45e3dc@%3Cdev.qpid.apache.org%3E -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8001) [Broker-J] [Documentation] Updates to docbook documentation to reflect changes/new features in v7
[ https://issues.apache.org/jira/browse/QPID-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8001. Resolution: Fixed > [Broker-J] [Documentation] Updates to docbook documentation to reflect > changes/new features in v7 > - > > Key: QPID-8001 > URL: https://issues.apache.org/jira/browse/QPID-8001 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > The documentation is out of date in a number of places. > The following areas need attention: > # 1. Introduction - include web sockets. BDB JE no longer separate download. > Message encryption is a client feature. > # 2.2 Unlimited strength JCE policy is now part of the JDK but needs to be > enabled. > # 4. Concepts - diagrams refer to exchanges which is no longer correct when > AMQP 1.0 is in use. > # 4.5 Virtualhosts - refers to Bindings as separate entities. Exchange and > Queue descriptions need to be updated to reflect AMQP 1.0. > # 4.6 Exchanges. Update section w.r.t AMQP 1.0. AMQP 1.0 may be used to > ingress messages to these entities. > # 4.6.4Unrouteable Messages - Update w.r.t alternate bindings. > # 4.7. Queues - Update section w.r.t AMQP 1.0. AMQP 1.0 may be used to > ingress messages directly to these entities. > # 4.7.2 Queue Declare Arguments - section applicable to AMQP 0-x. Move to > Appendix G - Queue Declaration Arguments. > # 4.7.5 Move queue declare argument to Appendix G. > # 4.7.5.2 Move consumer argument detail (Setting the replay period) to 9.7. > Consumers > # 6.5. QMF kill section > # Section 7 should really be auto generated from metadata, however > # 7.2. Entity/Management Channel Support Matrix - kill section > # 7.3.1 Heartbeating moved to port.. > # 7.7 Exchanges - add alternate binding, remove bindings. > # 7.8 Queues - add alternate binding > # 9.3. Producer Transaction Timeout - mention that AMQP 1.0 does not yet > implement this feature > # 9.4. Handing Undeliverable Messages - update related to alternateBinding > # 9.5.2 closeWhenNoRoute is now an attribute of Port. > # 9.6. Flow to Disk - defaults are out of date as are the references to the > messages. > # 9.11. Memory - AMQP 1.0 connections are larger. > # 10.6. Client failover - generalise i.e. remove the link to the old Qpid JMS > 0-x client. > # C. Operational Logging some messages are out of date. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8009) [Broker-J][WMC] New rows in message grid get selected after performing such operations like move messages and clear queue
[ https://issues.apache.org/jira/browse/QPID-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8009. Resolution: Fixed > [Broker-J][WMC] New rows in message grid get selected after performing such > operations like move messages and clear queue > - > > Key: QPID-8009 > URL: https://issues.apache.org/jira/browse/QPID-8009 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > New rows in message grid get selected after performing such operations like > move messages and clear queue. Additionally, null is returned from grid as > part of selection object for removed rows causing null pointer errors being > reported from delete/move/copy operations. The browser refresh is required to > work around the issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8010) [Broker-J][WMC] The row is selected on click or double-click for grids on virtual host tab
[ https://issues.apache.org/jira/browse/QPID-8010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8010. Resolution: Fixed > [Broker-J][WMC] The row is selected on click or double-click for grids on > virtual host tab > -- > > Key: QPID-8010 > URL: https://issues.apache.org/jira/browse/QPID-8010 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > Row selection is implemented inconsistently for WMC grids. The row is > selected on click or double-click for grids on virtual host tab, whilst for > all other grids in WMC the row selection is performed by checking the > selector checkbox. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7986) [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse of ServerConnection/SessionSession etc
[ https://issues.apache.org/jira/browse/QPID-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7986. Resolution: Fixed > [Qpid Broker-J] [AMQP0-10] Remove redundant casts left by collapse of > ServerConnection/SessionSession etc > - > > Key: QPID-7986 > URL: https://issues.apache.org/jira/browse/QPID-7986 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > Work of QPID-7622 (the collapse of AMQP 0-10 ServerConnection with Connection > etc) left behind a swath of redundant casts. These can be mechanically > removed. No functional changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8006) [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership can result in broker crash
[ https://issues.apache.org/jira/browse/QPID-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8006: --- Priority: Major (was: Trivial) > [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership > can result in broker crash > > > Key: QPID-8006 > URL: https://issues.apache.org/jira/browse/QPID-8006 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Lorenz Quack >Priority: Major > Attachments: qpid_.log > > > Not sure which steps I took to cause this but it was some order of deleting > VirtualHosts, stoping/starting VirtualHosts/VirtualHostNodes, and transfering > MASTERship between nodes. But the end result was a crashing broker. > I attach the complete (verbose) log so we can figure out what exactly I did > and what exactly happened. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8006) [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership can result in broker crash
[
https://issues.apache.org/jira/browse/QPID-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16237494#comment-16237494
]
Lorenz Quack commented on QPID-8006:
I tried to reporduce this but was not able to.
I think this might be a race condition.
Looking through the logs it seems like I preformed these actions:
# Initially we have to VHNs {{sdgfsfsdfsfsdf}} (MASTER) and {{dfsdf}} (REPLICA)
forming the group {{g1}}
# at 14:57:14,901 I delete the VH {{g1}} on the {{sdgfsfsdfsfsdf}}
# at 14:57:42,864 I create a new VH {{sdgfsfsdfsfsdf}} on the VHN
{{sdgfsfsdfsfsdf}}
# at 14:57:57,782 I stop the VHN {{sdgfsfsdfsfsdf}}
# at 14:58:07,891 I set some attributes on VHN {{dfsdf}}. potentially
{{designatedPrimary=true}}
# at 14:58:16,648 {{dfsdf}} tries to switch to MASTER
# There is an Exception at 14:58:16,659 but the node seems to switch to MASTER
regardless.
# at 14:58:30,790 I try to create a VH {{dfsdf}} on VHN {{dfsdf}}.
# This results in a
[{{com.sleepycat.je.rep.DatabasePreemptedException}}|https://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/rep/DatabasePreemptedException.html]
when trying to open the database {{AMQP_1_0_LINKS_VERSION}} at 14:58:30,830
# This exception is converted to a {{StoreException}} and brings down the
broker.
I think when the VH {{g1}} on {{sdgfsfsdfsfsdf}} gets deleted it deletes the
LinkRegistry including the AMQP_1_0_LINKS(_VERSION) databases. This db deletion
is replicated to {{dfsdf}} and causes the {{DatabasePreemptedException}} when
we try to open the new {{dfsdf}} VH.
> [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership
> can result in broker crash
>
>
> Key: QPID-8006
> URL: https://issues.apache.org/jira/browse/QPID-8006
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
> Attachments: qpid_.log
>
>
> Not sure which steps I took to cause this but it was some order of deleting
> VirtualHosts, stoping/starting VirtualHosts/VirtualHostNodes, and transfering
> MASTERship between nodes. But the end result was a crashing broker.
> I attach the complete (verbose) log so we can figure out what exactly I did
> and what exactly happened.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7995) [Broker-J][WMC] VirtualHost queues/exchanges/loggers can be wrongly deleted from virtual host UI when "select all" checkbox is used to select all displayed rows and some
[ https://issues.apache.org/jira/browse/QPID-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7995. Resolution: Fixed looks okay > [Broker-J][WMC] VirtualHost queues/exchanges/loggers can be wrongly deleted > from virtual host UI when "select all" checkbox is used to select all > displayed rows and some of the rows are deselected afterwards > --- > > Key: QPID-7995 > URL: https://issues.apache.org/jira/browse/QPID-7995 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.0.0 > > > When "select all" checkbox is used to select all rows in > queue/exchange/logger grid on Virtual Host tab, the de-selection of > individual rows does not work as expected: the UI displays rows as deselected > but internally all displayed rows are treated as selected and all of them can > be deleted after pressing "Delete Queue"/"Delete Exchange"/"Delete Logger" > button. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8002) [Broker-J][REST] Increase sasl exchange expiry interval
[ https://issues.apache.org/jira/browse/QPID-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8002. Resolution: Fixed Does what it says on the tin. We might want to consider removing this timeout all together. > [Broker-J][REST] Increase sasl exchange expiry interval > --- > > Key: QPID-8002 > URL: https://issues.apache.org/jira/browse/QPID-8002 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The web management SASL exchange is limited by the broker to 3 seconds by > default. On slow http connections, this time limit might be not sufficient > to perform SASL authentication. We need to increase it to 1minute. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8003) [Broker-J] Use log level 'info' to report conditions when no new rolled over log file is detected by the file logger
[ https://issues.apache.org/jira/browse/QPID-8003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8003. Resolution: Fixed looks good > [Broker-J] Use log level 'info' to report conditions when no new rolled over > log file is detected by the file logger > > > Key: QPID-8003 > URL: https://issues.apache.org/jira/browse/QPID-8003 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The log level 'warn' is currently used to report a condition when no new > rolled over log file is detected by the file logger. This issue does not > effect any core broker functionality. Thus, the log level can be safely > reduced to 'info' -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8005) [Broker-J][WMC] Redirect requests for removed 'login.html' to 'index.html'
[ https://issues.apache.org/jira/browse/QPID-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-8005. Resolution: Fixed looks good to me > [Broker-J][WMC] Redirect requests for removed 'login.html' to 'index.html' > -- > > Key: QPID-8005 > URL: https://issues.apache.org/jira/browse/QPID-8005 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > login.html was removed as part of re-factoring implemented in QPID-7789 ( > Refactor SASL web authentication). 404 is reported back on attempt to > navigate to login.html. Users of older Broker versions might have this page > bookmarked or preserved in browser history and can actually be accustomed to > open WMC using 'login.html'. For their convenience, we can simply send > redirects to index.html for any request coming to login.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8007) [Broker-J, WMC] Sometime the Buttons to create Dashboards and Queries stop working
Lorenz Quack created QPID-8007:
--
Summary: [Broker-J, WMC] Sometime the Buttons to create Dashboards
and Queries stop working
Key: QPID-8007
URL: https://issues.apache.org/jira/browse/QPID-8007
Project: Qpid
Issue Type: Bug
Affects Versions: qpid-java-broker-7.0.0
Reporter: Lorenz Quack
Priority: Major
So far I could not figure out the exact circumstances when this happens but
sometimes the Buttons in the Web management console to create new dashboards
and new queries stoip working. Clicking on them has no apparent effect. The
expected dialogue does not pop up and the browser's development tools show no
output on the console and no network activity. This happened on IE 11 and FF
45.8.
In one instance using the browser's debugger it appeared as if the code inside
the {{ready}} call in ConsoleHelper.js:94 was never executed (as if the
QueryCreateDialogForm DOM element never became ready).
Reloading the page resolves the issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8006) [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership can result in broker crash
[ https://issues.apache.org/jira/browse/QPID-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-8006: --- Attachment: qpid_.log Unfortunately, the beginning of the file is truncated due to log file rollover. > [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership > can result in broker crash > > > Key: QPID-8006 > URL: https://issues.apache.org/jira/browse/QPID-8006 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Lorenz Quack > Attachments: qpid_.log > > > Not sure which steps I took to cause this but it was some order of deleting > VirtualHosts, stoping/starting VirtualHosts/VirtualHostNodes, and transfering > MASTERship between nodes. But the end result was a crashing broker. > I attach the complete (verbose) log so we can figure out what exactly I did > and what exactly happened. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8006) [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership can result in broker crash
Lorenz Quack created QPID-8006: -- Summary: [Broker-J, HA] Deleting VH, stoping/starting VH(N)s, and switching mastership can result in broker crash Key: QPID-8006 URL: https://issues.apache.org/jira/browse/QPID-8006 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-broker-7.0.0 Reporter: Lorenz Quack Not sure which steps I took to cause this but it was some order of deleting VirtualHosts, stoping/starting VirtualHosts/VirtualHostNodes, and transfering MASTERship between nodes. But the end result was a crashing broker. I attach the complete (verbose) log so we can figure out what exactly I did and what exactly happened. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7994) [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found' on attaching of unsubscribe links for global durable shared subscriptions
[
https://issues.apache.org/jira/browse/QPID-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225099#comment-16225099
]
Lorenz Quack commented on QPID-7994:
A couple of points:
* Regarding the existing behaviour: The broker *does* look for the link. But
the link defined by the triplet (remote-container-id, role, name) cannot be
found because the remote-container-id does not match. Since it cannot recover
the link the broker decides to reject the link.
* I disagree with what you wrote the broker should do. I think that would break
compliance with AMQP core spec which clearly states that a link is defined by
the triplet (remote-container-id, role, name). And furthermore, I don't think
that is the behaviour QPIDJMS-220 suggests. Nowhere does it state that a link
from a different remote-container-id should be recovered.
* I think the broker is correct in not recovering a link not matching the
triplet. However, it clearly does not do the right thing when unsubscribing a
global durable share subscription. However instead of putting this
responsibility on the link recovery path I would suggest to put the
responsibility on either {{SendingLinkEndpoint#detach}} or somewhere on the
{{AbstractVirtualHost#removeSubscriptionQueue}} path.
> [Broker-J] [JMS2.0 support] 'null source lookup' ends up in 'amqp:not-found'
> on attaching of unsubscribe links for global durable shared subscriptions
> --
>
> Key: QPID-7994
> URL: https://issues.apache.org/jira/browse/QPID-7994
> Project: Qpid
> Issue Type: Bug
>Reporter: Alex Rudyy
>
> As per [QPIDJMS-220|https://issues.apache.org/jira/browse/QPIDJMS-220]
> {quote}
> During unsubscribe, if a ClientID is set on the connection, a link named with
> the subscription name would be used to perform a 'null source lookup' for the
> subscription, as it is already for the existing non-shared durable
> subscriptions (see earlier for behaviour outline). If a ClientID is not set,
> the "|global" suffix will be added as shown previously..
> {quote}
> The current broker behaviour is not compliment with QPIDJMS-220. The broker
> create a new link instead of looking for existing link having name
> {{|global}} as suggested by QPIDJMS-220. For the new link,
> the local source is null. As result, 'not=found' error is reported.
> The broker should try to find an existing link in the link registry using
> link name only rather than name and a container ID as it does now. If link
> with given name is found, it should be used to recover the source. The broker
> should perform the search by link name only if {{SHARED}} capability is
> requested either on connection or attach itself as suggested by QPIDJMS-220:
> {quote}
> Additionally, while using connections that dont have a ClientID set, i.e
> using global shared susbcriptions, the link will have "shared" and "global"
> desired capabilities added as hints to the server that this is an attempt to
> attach to a 'global' shared subscription of the appropriate name derived from
> the link, aiding the server should no link with this name be known by it for
> the particular client container-id currently in use.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7993) [Broker-J] Links for shared durable subscribers are accumulated in the link registry
[
https://issues.apache.org/jira/browse/QPID-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224529#comment-16224529
]
Lorenz Quack commented on QPID-7993:
For reference: QPIDJMS-220 describes the naming conventions for shared durable
subscribers.
> [Broker-J] Links for shared durable subscribers are accumulated in the link
> registry
>
>
> Key: QPID-7993
> URL: https://issues.apache.org/jira/browse/QPID-7993
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>
> Only link with name equals to subscription name is deleted from the link
> registry on unsubscribe of shared durable subscription. The other shared
> durable subscription links with names containing index are left in link
> registry forever. As result, such links can accumulate with time and cause
> OOM.
> The steps to reproduce
> * Apply patch from QPID-7992
> * Start the Broker
> * Create shared durable subscriptions with 2 subscribers
> * Close subscribers and unsubscribe the subscription
> * Dump the link registry state using management operation
> {{QueueManagingVirtualHost#dumpLinkRegistry}} . The link for the second
> shared subscriber will be present in the dumped data
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7399:
--
Assignee: Lorenz Quack
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7399:
---
Status: Reviewable (was: In Progress)
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7399:
--
Assignee: Keith Wall (was: Lorenz Quack)
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7962.
Resolution: Fixed
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222365#comment-16222365
]
Lorenz Quack commented on QPID-7962:
The commit message is incorrect. I removed the first point mentioned from the
commit. It no longer explicitly adds a consumer to the interested list if a
message is stolen.
Keith and I came to the conclusion, that it would not be necessary since the
message, once acquired, is delivered to the consumer regardless so the normal
process of adding itself to the interested list after delivery should kick in.
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7399) [Java Broker] ClosedSelectorException during shutdown
[
https://issues.apache.org/jira/browse/QPID-7399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222358#comment-16222358
]
Lorenz Quack commented on QPID-7399:
My analysis (current revision is 62a) is as follows:
# The selector thread detects acceptable keys and puts the Runnable on line 196
onto the {{_workQueue}}.
# In the meantime something closes the AmqpPort which calls
{{AmqpPortImpl#onClose}} -> {{TCPandSSLTransport#close}} ->
{{NetworkConnectionScheduler#close}} -> {{SelectorThread#close}} which sets
{{_closed}} to {{true}}.
# The selector thread now reaches the end of the while loop in
{{SelectionTask#performSelect}} and calls {{SelectionTask#closeSelector}} which
closes the {{_selector}}.
# Now a different IO-Thread picks up the Runnable from step 1. from the
{{_workQueue}} and starts executing it. Notice that the Runnable is a closure
around the former selector thread's {{SelectorTask}} (the one who's
{{_selector}} was closed in step 3.).
# When trying to use the {{_selector}} in line 210 we get the above
{{ClosedSelectorException}}
For now I will simply catch the exception which seems to occur rarely.
Since {{Selector#close}} is synchronized on the selector itself (see
Concurrency section of [the
docs|https://docs.oracle.com/javase/8/docs/api/java/nio/channels/Selector.html])
we could alternatively synchronize a block around the call to
{{channel.register}} in line 210.
> [Java Broker] ClosedSelectorException during shutdown
> -
>
> Key: QPID-7399
> URL: https://issues.apache.org/jira/browse/QPID-7399
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> TEST-org.apache.qpid.transport.MaxFrameSizeTest.testTooLargeFrameSize.txt
>
>
> Today the Jenkins mms.0-9-1 job on trunk failed the test
> {{MaxFrameSizeTest.testTooSmallFrameSize}} but the actual problem seems to
> have been during shutdown of {{MaxFrameSizeTest.testTooLargeFrameSize}}.
> There the following exception occurred:
> {code}
> 2016-08-23 20:26:34,118 ERROR [IO-pool-Port-amqp-2]
> o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread
> IO-pool-Port-amqp-2
> java.nio.channels.ClosedSelectorException: null
> at sun.nio.ch.EPollSelectorImpl.putEventOps(EPollSelectorImpl.java:185)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.ServerSocketChannelImpl.translateAndSetInterestOps(ServerSocketChannelImpl.java:361)
> ~[na:1.7.0_80]
> at
> sun.nio.ch.SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:105)
> ~[na:1.7.0_80]
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:83)
> ~[na:1.7.0_80]
> at
> java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:201)
> ~[na:1.7.0_80]
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:197)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:462)
> ~[qpid-broker-core-6.1.0-SNAPSHOT.jar:6.1.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_80]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_80]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_80]
> {code}
> The full log is attached.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7989) [Qpid Broker-J] [AMQP1.0] Session_1_0#unacknowledgedMessageCount not wired up
[
https://issues.apache.org/jira/browse/QPID-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7989.
Resolution: Fixed
> [Qpid Broker-J] [AMQP1.0] Session_1_0#unacknowledgedMessageCount not wired up
> -
>
> Key: QPID-7989
> URL: https://issues.apache.org/jira/browse/QPID-7989
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> The {{Session_1_0#unacknowledgedMessageCount}} statistic is not wired up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7982) [Java Broker] MariaDB backed JDBC virtualhost truncates message content at 64K leading to Broker abnormal shutdown
[
https://issues.apache.org/jira/browse/QPID-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7982.
Resolution: Fixed
> [Java Broker] MariaDB backed JDBC virtualhost truncates message content at
> 64K leading to Broker abnormal shutdown
> --
>
> Key: QPID-7982
> URL: https://issues.apache.org/jira/browse/QPID-7982
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> When using the Qpid Broker-J with a JDBC backed virtualhost using MariaDB,
> the database silently truncates message content at 64KB. This means if the
> Broker needs to recover a message from disk (i.e. after a restart or after
> message content has been flowed to disk), it will fail to retrieve the
> expected number of message bytes and will fail as it tries to deliver the
> message to the consumer. The failure also manifests if the message is viewed
> from Management.
> {noformat}
>
> #
> # Unhandled Exception java.lang.IllegalArgumentException: offset: 0, length:
> 262152, remaining: 65535 in Thread IO-/127.0.0.1:56942
> #
> # Exiting
> #
>
> java.lang.IllegalArgumentException: offset: 0, length: 262152, remaining:
> 65535
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.view(QpidByteBuffer.java:1003)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCMessageStore$StoredJDBCMessage.getContent(AbstractJDBCMessageStore.java:1443)
> at
> org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:191)
> at
> org.apache.qpid.server.protocol.v1_0.Message_1_0.getContent(Message_1_0.java:215)
> at
> org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:181)
> at
> org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0.doSend(ConsumerTarget_1_0.java:154)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.send(AbstractConsumerTarget.java:227)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:280)
> at
> org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:162)
> at
> org.apache.qpid.server.session.AbstractAMQPSession.processPending(AbstractAMQPSession.java:394)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$ProcessPendingIterator.lambda$next$2(AMQPConnection_1_0Impl.java:1814)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:356)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:264)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Inspecting the db you see:
> {noformat}
> MariaDB [qpid]> select octet_length(content) from QPID_MESSAGE_CONTENT
> -> ;
> +---+
> | octet_length(content) |
> +---+
> | 65535 |
> +---+
> 1 row in set (0.01 sec)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7971) [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not decremented when consumer disconnects
[
https://issues.apache.org/jira/browse/QPID-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7971.
Resolution: Fixed
> [Java Broker] [AMQP1.0] [AMQP0-9] Queue#ConsumerCountWithCredit statistic not
> decremented when consumer disconnects
> ---
>
> Key: QPID-7971
> URL: https://issues.apache.org/jira/browse/QPID-7971
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Running {{HelloWorld}} against the Java Broker, I notice that the
> {{Queue#ConsumerCountWithCredit}} statistic does not return to zero after the
> connection is closed. The problem is not apparent -when using the older
> protocols-. Corrected: AMQP 0-9 also exhibits the same problem.
> I notice {{org.apache.qpid.server.consumer.AbstractConsumerTarget#close}}
> clears {{_consumers}} then calls {{setNotifyWorkDesired}} which iterates
> {{_consumers}}.
> I verified that v6.1 is not affected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7990) [Qpid Broker-J] [AMQP0-8] Dead _model reference in AMQPChannel
[
https://issues.apache.org/jira/browse/QPID-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7990.
Resolution: Fixed
> [Qpid Broker-J] [AMQP0-8] Dead _model reference in AMQPChannel
> --
>
> Key: QPID-7990
> URL: https://issues.apache.org/jira/browse/QPID-7990
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Trivial
> Fix For: qpid-java-broker-7.0.0
>
>
> There a dead {{_modelObject}} reference in the AMQChannel that was left over
> from QPID-7633 (Removal of session adapters). It has no purpose and should
> be removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7916) Rename qpid broker for java to qpid-broker-j in maven descriptions, documentations, website etc
[ https://issues.apache.org/jira/browse/QPID-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7916. Resolution: Fixed > Rename qpid broker for java to qpid-broker-j in maven descriptions, > documentations, website etc > --- > > Key: QPID-7916 > URL: https://issues.apache.org/jira/browse/QPID-7916 > Project: Qpid > Issue Type: Task > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > In this thread we agreed that the Java Broker would be known as > "qpid-broker-j" (the consensus was that the "Qpid Broker for Java" was > misleading). The "qpid-broker-j" name was adopted for the name of the new > Git repo (work of QPID-7622) > http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html#none > We need to reflect this name in Maven metadata (descriptions etc), docbook > and website. > The maven artefactIds will not be changed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7983) Bump the initial-config's model version from 6.1 to 7.0
[ https://issues.apache.org/jira/browse/QPID-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7983. Resolution: Fixed > Bump the initial-config's model version from 6.1 to 7.0 > > > Key: QPID-7983 > URL: https://issues.apache.org/jira/browse/QPID-7983 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > The model has advanced from 6.1 to 7.0, this needs to be reflected in the > initial configuration too. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7962) [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back when Flow with drain flag set is received from client
[
https://issues.apache.org/jira/browse/QPID-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7962:
---
Attachment: 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch
My attached patch tries to fix the issue by doing two things:
* When message is stolen from consumer add it to the queue's list of interested
consumers
* Rename {{QueueConsumer#}} and {{ConsumerTarget#queueEmpty}} to
{{#noMessagesAvailable}}. The effect of this method is potential auto-close on
0-8 and potential credit draining on 1.0. This is now always called when we
currently cannot deliver messages to this consumer. This can occur when
** there is no message (the queue is empty)
** existing messages do not pass through the consumer's filters
** the consumer has no credit
** there is a different consumer with higher priority and credit blocking
delivery to this lower priority consumer
> [Java Broker][AMQP 1.0] In some circumstances Broker fails to send Flow back
> when Flow with drain flag set is received from client
> --
>
> Key: QPID-7962
> URL: https://issues.apache.org/jira/browse/QPID-7962
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7962-Broker-J-AMQP-1.0-In-some-circumstances-Br.patch,
> TEST-org.apache.qpid.server.queue.LiveQueueOperationsTest.testClearQueueOperationWithActiveConsumerDlqAll.txt
>
>
> Occasionally when clear queue operation is invoked from management and
> {{Flow}} with {{drain}} flag is received from client concurrently, the
> {{Broker}} might not send {{Flow}} back after clearing the queue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7830) Heap dominated by duplicates of common routing values / header values etc
[
https://issues.apache.org/jira/browse/QPID-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16220081#comment-16220081
]
Lorenz Quack commented on QPID-7830:
All this sounds awfully complicated.
What is wrong with something simpler like using a static class in broker-core
{{StringCache}} that uses a [guava
cache|https://github.com/google/guava/wiki/CachesExplained] with a [size
limit|https://github.com/google/guava/wiki/CachesExplained#size-based-eviction]
and [time based
eviction|https://github.com/google/guava/wiki/CachesExplained#timed-eviction]?
When a protocol layer then needs a String which we know might be repetitive
(like the cases mentioned above) it calls {{StringCache#getString()}} and guava
takes care of the rest.
This might be a naive approach but I would like to at least discuss why it is
not sufficient?
> Heap dominated by duplicates of common routing values / header values etc
> -
>
> Key: QPID-7830
> URL: https://issues.apache.org/jira/browse/QPID-7830
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: Future
>
>
> When used for store and forwarding, in some use cases the Broker's heap can
> become dominated by duplicates of common values such as routing information
> (e.g. {{amq.direct}} or an application's queue name) or common header values
> (e.g a application/octet-stream or an application's user id).
> On the 0-8..0-91 paths, every enqueued message gets its own
> {{MessagePublishInfo}} referencing its own {{AMQShortString}} exchange and
> routing keys. For some use-cases, these are drawn from a small set. On the
> AMQP 1.0 path, {{Properties#to}} is an example. 0-10 is probably affected
> too.
> This unnecessarily increases the heap requirements of the Broker.
> The Broker should adopt a sensible intern/caching policy with the same policy
> applying regardless of whether messages follow the on-line enqueue or
> recovery path. Note that in AMQP 1.0, values which are {{Symbols}} have
> their underlying String automatically interned.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7954) [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
[
https://issues.apache.org/jira/browse/QPID-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218631#comment-16218631
]
Lorenz Quack commented on QPID-7954:
Alex pointed out to me that the above comment is not fully accurate.
On normal broker initiated detach we do not seem to discard the endpoint
immediately.
We do discard them in two cases that seem problematic:
* after sending detach due to a session end which seems problematic because the
remote peer is supposed to answer with its own detach. Furthermore, there might
still be performatives in flight.
* we remove the inputhandle in disassociateEndpoint which happens for
errant-links immediately after sending the detach. This would cause a problem
in the case where a performative is sent pipelined with the attach without
waiting for the attach response from the broker.
> [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
>
>
> Key: QPID-7954
> URL: https://issues.apache.org/jira/browse/QPID-7954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: Future
>
>
> Currently the AMQP detach handling code is messy.
> It could use a good refactoring and cleanup.
> Also the following issues need looking into:
> * Are we handling simultaneous detach correctly? There seems to be shared
> code between broker- and client-side detach ({{Session_1_0#detach()}}) which
> unmaps both the input and output handle.
> * We should probably have a ticker timing out clients that do not send back a
> detach after a broker side detach in a reasonable amount of time.
> * Are all state transitions handled correctly?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7988) [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result in a session error
[ https://issues.apache.org/jira/browse/QPID-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7988: -- Assignee: Lorenz Quack > [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result > in a session error > -- > > Key: QPID-7988 > URL: https://issues.apache.org/jira/browse/QPID-7988 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > Section 2.7.4 when talking about the handle says: > bq. If set to a handle that is not currently associated with an attached > link, the recipient MUST respond by ending the session with an > unattached-handle session error. > Currently, the broker is treating this case as if the handle was not set > (null). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7981:
--
Assignee: (was: Lorenz Quack)
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> SEND[/10.211.55.13:52035|0] :
>
[jira] [Commented] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218404#comment-16218404
]
Lorenz Quack commented on QPID-7981:
The last part of the requirements layed out by Keith about errant-link is not
implemented due to QPID-7954
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
>
[jira] [Updated] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7981:
---
Status: Reviewable (was: In Progress)
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
>
[jira] [Assigned] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7981:
--
Assignee: Lorenz Quack
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The second is if the {{Source}} (again not mandatory) is omitted:
> {noformat}
> 2017-10-21 18:19:52,556 DEBUG [IO-/10.211.55.13:52035]
> (o.a.q.s.p.v.f.FrameHandler) - RECV 89 bytes
> 2017-10-21 18:19:52,557 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52035|0] :
> Attach{name=c2c65769-7d3b-5440-b8fb-f00badbddd0d,handle=1,role=sender,target=Target{address=examples},initialDeliveryCount=0}
> 2017-10-21 18:19:52,562 DEBUG [IO-/10.211.55.13:52035] (o.a.q.s.p.frame) -
>
[jira] [Updated] (QPID-7988) [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result in a session error
[ https://issues.apache.org/jira/browse/QPID-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7988: --- Status: Reviewable (was: In Progress) > [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result > in a session error > -- > > Key: QPID-7988 > URL: https://issues.apache.org/jira/browse/QPID-7988 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack >Assignee: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > Section 2.7.4 when talking about the handle says: > bq. If set to a handle that is not currently associated with an attached > link, the recipient MUST respond by ending the session with an > unattached-handle session error. > Currently, the broker is treating this case as if the handle was not set > (null). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7988) [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result in a session error
[ https://issues.apache.org/jira/browse/QPID-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7988: -- Assignee: (was: Lorenz Quack) > [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result > in a session error > -- > > Key: QPID-7988 > URL: https://issues.apache.org/jira/browse/QPID-7988 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > Section 2.7.4 when talking about the handle says: > bq. If set to a handle that is not currently associated with an attached > link, the recipient MUST respond by ending the session with an > unattached-handle session error. > Currently, the broker is treating this case as if the handle was not set > (null). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7954) [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
[
https://issues.apache.org/jira/browse/QPID-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16218382#comment-16218382
]
Lorenz Quack commented on QPID-7954:
It also looks like that if we do a broker initiated link detach we immediately
discard the endpoint from the session. So if the remote side sends another
performative (or it is already on the wire) involving the handle it will result
in a {{unattached-handle}} session error.
We should only discard the input handle once we receive the detach from the
remote peer or after a timeout.
> [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
>
>
> Key: QPID-7954
> URL: https://issues.apache.org/jira/browse/QPID-7954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: Future
>
>
> Currently the AMQP detach handling code is messy.
> It could use a good refactoring and cleanup.
> Also the following issues need looking into:
> * Are we handling simultaneous detach correctly? There seems to be shared
> code between broker- and client-side detach ({{Session_1_0#detach()}}) which
> unmaps both the input and output handle.
> * We should probably have a ticker timing out clients that do not send back a
> detach after a broker side detach in a reasonable amount of time.
> * Are all state transitions handled correctly?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7988) [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result in a session error
Lorenz Quack created QPID-7988: -- Summary: [Java Broker, AMQP 1.0] Receiving a Flow with an unknown handle MUST result in a session error Key: QPID-7988 URL: https://issues.apache.org/jira/browse/QPID-7988 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack Fix For: qpid-java-broker-7.0.0 Section 2.7.4 when talking about the handle says: bq. If set to a handle that is not currently associated with an attached link, the recipient MUST respond by ending the session with an unattached-handle session error. Currently, the broker is treating this case as if the handle was not set (null). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (QPID-7981) [Java Broker] [AMQP1.0] Handle erroneous null termini cases
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7981:
---
Comment: was deleted
(was: Gordon wrote:
{quote}
I believe that the source is set for the 'outgoing' link, i.e. the link on
which the client will receive messages. However the target is not.
{quote}
The stacktraces that Keith put in the description suggest that this is not the
case. I haven't run this myself but just looking at the stacktraces (which are
from the broker's perspective) the {{StandardReceivingLinkEndpoint}} fails
because {{source}} is {{null}} and {{SendingLinkEndpoint}} fail because
{{target}} seems to be {{null}}. So either Rhea does not set them correctly or
we do not save them correctly.)
> [Java Broker] [AMQP1.0] Handle erroneous null termini cases
> ---
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.lambda$null$0(QpidByteBuffer.java:1396)
> at
[jira] [Resolved] (QPID-7922) Null pointer exception while handling a message without any payload
[ https://issues.apache.org/jira/browse/QPID-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7922. Resolution: Fixed > Null pointer exception while handling a message without any payload > --- > > Key: QPID-7922 > URL: https://issues.apache.org/jira/browse/QPID-7922 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.1.4 >Reporter: Artyom Safronov > > An exception occures while sending a message created by no-args "create" > method of the Message.Factory. > And this is a stack trace found in a log file of the Java broker. > 2017-09-25 13:39:39,396 WARN [IO-/127.0.0.1:50488] > (o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame > java.lang.NullPointerException: null > at > org.apache.qpid.server.protocol.v1_0.ReceivingLink_1_0.messageTransfer(ReceivingLink_1_0.java:126) > at > org.apache.qpid.server.protocol.v1_0.Session_1_0$SubjectSpecificReceivingLinkListener$1.run(Session_1_0.java:1423) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.protocol.v1_0.Session_1_0$SubjectSpecificReceivingLinkListener.messageTransfer(Session_1_0.java:1418) > at > org.apache.qpid.server.protocol.v1_0.ReceivingLinkEndpoint.receiveTransfer(ReceivingLinkEndpoint.java:164) > at > org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveTransfer(Session_1_0.java:688) > at > org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0$5.run(AMQPConnection_1_0.java:652) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0.receiveTransfer(AMQPConnection_1_0.java:647) > at > org.apache.qpid.server.protocol.v1_0.type.transport.Transfer.invoke(Transfer.java:281) > at > org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0.receive(AMQPConnection_1_0.java:309) > at > org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:166) > at > org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0$10.run(AMQPConnection_1_0.java:1167) > at java.security.AccessController.doPrivileged(Native Method) > at > org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0.received(AMQPConnection_1_0.java:1140) > at > org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:143) > at > org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:624) > at > org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58) > at > org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:512) > at > org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:285) > at > org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:130) > at > org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7981) [Java Broker] [AMQP1.0] Protocol layer assumes source and target are not null.
[
https://issues.apache.org/jira/browse/QPID-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16215368#comment-16215368
]
Lorenz Quack commented on QPID-7981:
Gordon wrote:
{quote}
I believe that the source is set for the 'outgoing' link, i.e. the link on
which the client will receive messages. However the target is not.
{quote}
The stacktraces that Keith put in the description suggest that this is not the
case. I haven't run this myself but just looking at the stacktraces (which are
from the broker's perspective) the {{StandardReceivingLinkEndpoint}} fails
because {{source}} is {{null}} and {{SendingLinkEndpoint}} fail because
{{target}} seems to be {{null}}. So either Rhea does not set them correctly or
we do not save them correctly.
> [Java Broker] [AMQP1.0] Protocol layer assumes source and target are not null.
> --
>
> Key: QPID-7981
> URL: https://issues.apache.org/jira/browse/QPID-7981
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Testing the Broker against Rhea's {{example/helloworld.js}} shows that the
> AMQP 1.0 protocol layer fails in at least two places.
> The first is if the {{Target}} (not mandatory) is omitted from the incoming
> attach.
> {noformat}
> 2017-10-21 18:13:20,609 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.frame) -
> RECV[/10.211.55.13:52033|0] :
> Attach{name=7e65e0a0-961f-e941-b42b-262380143f76,handle=0,role=receiver,source=Source{address=examples}}
> 2017-10-21 18:13:20,622 DEBUG [IO-/10.211.55.13:52033] (o.a.q.s.p.v.LinkImpl)
> - Error attaching link
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.createConsumerTarget(SendingLinkEndpoint.java:209)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.attachReceived(SendingLinkEndpoint.java:636)
> at
> org.apache.qpid.server.protocol.v1_0.SendingLinkEndpoint.establishLink(SendingLinkEndpoint.java:352)
> at
> org.apache.qpid.server.protocol.v1_0.AbstractLinkEndpoint.receiveAttach(AbstractLinkEndpoint.java:131)
> at
> org.apache.qpid.server.protocol.v1_0.LinkImpl.attach(LinkImpl.java:106)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receiveAttach(Session_1_0.java:210)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveAttach(AMQPConnection_1_0Impl.java:435)
> at
> org.apache.qpid.server.protocol.v1_0.type.transport.Attach.invoke(Attach.java:366)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:517)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receive$0(AMQPConnection_1_0Impl.java:469)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:463)
> at
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:211)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$received$11(AMQPConnection_1_0Impl.java:1316)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1291)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:134)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:606)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:136)
> 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:563)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
>
[jira] [Commented] (QPID-7974) JdbcUtils.TableExists is very slow on big databases such as Oracle
[ https://issues.apache.org/jira/browse/QPID-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209395#comment-16209395 ] Lorenz Quack commented on QPID-7974: I just had a very brief look but the commit seems wrong. It looks like if the tableName is all lower or all upper case tableExists will always return true regardless of whether the table exists or not. > JdbcUtils.TableExists is very slow on big databases such as Oracle > -- > > Key: QPID-7974 > URL: https://issues.apache.org/jira/browse/QPID-7974 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-6.1.4 >Reporter: Adel Boutros >Assignee: Rob Godfrey > Fix For: qpid-java-broker-7.0.0 > > > The problem is that JdbcUtils.tableExists will actually load all tables and > then iterate to find the correct one. On Oracle, this can be around 40 000 > tables. So it will take 12 minutes for the broker to start. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7832) Refactor store/protocol API using Collection
[ https://issues.apache.org/jira/browse/QPID-7832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7832: --- Attachment: 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch > Refactor store/protocol API using Collection > - > > Key: QPID-7832 > URL: https://issues.apache.org/jira/browse/QPID-7832 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > Attachments: > 0001-QPID-7832-Java-Broker-Refactor-store-protocol-API-us.patch > > > Store/protocol APIs have gradually been evolving to accept/return message > content/message metadata in terms of an ordered list of QBBs. This has lead > to use of helper methods such as those in QBBUtils which read from a list of > buffers rather than a single one. > This would be better refactored. QpidByteBuffer should be an interface. > This would allow a concrete implementation CompositeQpidByteBuffer which is > backed by a list produced by the store or network IO. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7967) [Java Broker] Internal Oracle TLS classes leaked per connection when connecting the Qpid JMS Client
[
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16199980#comment-16199980
]
Lorenz Quack commented on QPID-7967:
My gut feeling is to set them to something reasonable (cache: 100-1000 objects;
timeout: 5-10 min) and not bother making it configurable (IMHO we already have
too many knobs and dials).
However, if you do want to make it configurable I would not veto and I would
not object to Rob's approach (picking minimal default values).
> [Java Broker] Internal Oracle TLS classes leaked per connection when
> connecting the Qpid JMS Client
> ---
>
> Key: QPID-7967
> URL: https://issues.apache.org/jira/browse/QPID-7967
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Environment: Java version "1.8.0_144"
> Mac OS X 10.12.6
>Reporter: Keith Wall
>
> Performing leak analysis shows that the following internal TLS classes are
> leaked, once per TLS connection, when connecting using the Qpid JMS Client
> 0.26.0 over AMQP 1.0 with TLS. The same leak was not apparent when connecting
> the older Qpid JMS AMQP 0-x client.
> The classes are:
> # sun.security.ssl.SessionId
> # sun.security.ssl.SSLSessionImpl
> The test is run with the following command:
> {code}
> mvn exec:java -pl tools -Dstresstest=qpid-jms-client
> -Dexec.args="jndiProperties=stress-test-client-qpid-jms-client.properties
> jndiConnectionFactory=qpidConnectionFactoryTls connections=100"
> -Djavax.net.ssl.trustStore=/Users/keith/Downloads/myks.jks
> -Dqpid-jms-client-version=0.26.0
> {code}
> It seems there is session caching going on within the JDK. The cache size
> and timeout looks to be tuneable with
> {{javax.net.ssl.SSLContext#getServerSessionContext}}. The default timeout is
> 86400s (1day) and a session cache size of 0 (unbounded). I suspect if Broker
> had a sufficiently large number of TLS connections over a short time period,
> memory may be exhausted.
> -I don't currently understand why the behaviour is different between the
> old/new JMS client-. Edit - see comment below.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7956) [Java Broker] Memory compactor threw NPE during Broker shutdown
[
https://issues.apache.org/jira/browse/QPID-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7956.
Resolution: Fixed
Keith and I paired on this.
> [Java Broker] Memory compactor threw NPE during Broker shutdown
> ---
>
> Key: QPID-7956
> URL: https://issues.apache.org/jira/browse/QPID-7956
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following exception was received during shutdown of the Broker (^C from
> the terminal). There was a significant queue depth enqueued at the time.
> {noformat}
> 2017-10-04 04:49:54,848 ERROR [broker-Broker-pool-0]
> (o.a.q.s.u.HousekeepingExecutor) - Housekeeping task threw an exception:
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.reallocateMessages(AbstractVirtualHost.java:1390)
> at
> org.apache.qpid.server.model.BrokerImpl.compactMemoryInternal(BrokerImpl.java:1245)
> at
> org.apache.qpid.server.model.BrokerImpl.checkDirectMemoryUsage(BrokerImpl.java:447)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7956) [Java Broker] Memory compactor threw NPE during Broker shutdown
[
https://issues.apache.org/jira/browse/QPID-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7956:
---
Summary: [Java Broker] Memory compactor threw NPE during Broker shutdown
(was: Memory compactor threw NPE during Broker shutdown)
> [Java Broker] Memory compactor threw NPE during Broker shutdown
> ---
>
> Key: QPID-7956
> URL: https://issues.apache.org/jira/browse/QPID-7956
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The following exception was received during shutdown of the Broker (^C from
> the terminal). There was a significant queue depth enqueued at the time.
> {noformat}
> 2017-10-04 04:49:54,848 ERROR [broker-Broker-pool-0]
> (o.a.q.s.u.HousekeepingExecutor) - Housekeeping task threw an exception:
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.reallocateMessages(AbstractVirtualHost.java:1390)
> at
> org.apache.qpid.server.model.BrokerImpl.compactMemoryInternal(BrokerImpl.java:1245)
> at
> org.apache.qpid.server.model.BrokerImpl.checkDirectMemoryUsage(BrokerImpl.java:447)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7933) [Java Broker] Changes made to existing durable children of virtualhost not recorded to the configuration store after a virtualhost restart
[ https://issues.apache.org/jira/browse/QPID-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7933. Resolution: Fixed > [Java Broker] Changes made to existing durable children of virtualhost not > recorded to the configuration store after a virtualhost restart > -- > > Key: QPID-7933 > URL: https://issues.apache.org/jira/browse/QPID-7933 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > If a *virtualhost* is stopped, the object's children are closed and evacuated > from memory. On restart, the children are recovered from the store. > However, the restart path AbstractVirtualHost#onRestart fails to reinstall > the StoreConfigurationChangeListener on the recovered children. The effect > of this is that subsequent changes made to *existing* durable children (for > instance, a queue's alert threshold) are not persisted to the configuration > store. > The persistence of newly added objects (or the deletion of existing objects) > is not affected. This is because the VirtualHost still has its > StoreConfigurationChangeListener intact. (The virtualhost is not closed > during a restart). > A restart at the virtualhostnode level does not suffer this problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7944) [Java Broker] [AMQP1.0] Observing a message with a null object property cause 500 error to be sent to the browser
[
https://issues.apache.org/jira/browse/QPID-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7944.
Resolution: Fixed
Keith and I paired on this.
> [Java Broker] [AMQP1.0] Observing a message with a null object property cause
> 500 error to be sent to the browser
> -
>
> Key: QPID-7944
> URL: https://issues.apache.org/jira/browse/QPID-7944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> # Start the Broker
> # Configured HTTPS
> # Send an JMS message from Qpid JMS Client with setObjectProperty("mynull",
> null)
> # Try to observe the message using Management (using HTTPS).
> The browser receives a 500 and the following is logged.
> {noformat}
> 2017-10-02 08:53:23,844 ERROR [qtp163439984-248]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/queue/default/default/queue/getMessageContent':
> java.lang.NullPointerException: null
> at java.util.HashMap.merge(HashMap.java:1224)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.qpid.server.message.internal.InternalMessageHeader.(InternalMessageHeader.java:94)
> at
> org.apache.qpid.server.message.internal.InternalMessage.convert(InternalMessage.java:220)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:69)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:39)
> at
> org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3308)
> at
> org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3281)
> at
> org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:102)
> 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.ConfiguredObjectMethodOperation.perform(ConfiguredObjectMethodOperation.java:125)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:620)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:205)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:122)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:365)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
>
[jira] [Resolved] (QPID-7958) [Java Broker] [AMQP0-10] References to messages sent by $virtualhostProperties node retained by store
[
https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack resolved QPID-7958.
Resolution: Fixed
> [Java Broker] [AMQP0-10] References to messages sent by
> $virtualhostProperties node retained by store
> -
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> On the 0-10 path, I notice that references to messages created by the
> {{${virtualhostProperties\}}} node are being retained internally within the
> store. This is leaking approximately ~1024 bytes per connection. Restarting
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}}
> set.
> QPID-7783 added the _messages data structure. -It was back ported to 6.0 and
> 6.1, so the leak might be present there too. I have not verified this-.
> (updated 2017/10/06 does not affect 6.1 or 6.0. The
> MessageInstanceConsumerPair, which is no longer on master, unconditionally
> took a reference, so a reference was already taken).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7958) [Java Broker] [AMQP0-10] References to messages sent by $virtualhostProperties node retained by store
[
https://issues.apache.org/jira/browse/QPID-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196945#comment-16196945
]
Lorenz Quack commented on QPID-7958:
Keith and I paired on this task.
> [Java Broker] [AMQP0-10] References to messages sent by
> $virtualhostProperties node retained by store
> -
>
> Key: QPID-7958
> URL: https://issues.apache.org/jira/browse/QPID-7958
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> On the 0-10 path, I notice that references to messages created by the
> {{${virtualhostProperties\}}} node are being retained internally within the
> store. This is leaking approximately ~1024 bytes per connection. Restarting
> the Broker or recycling the virtualhost frees the memory.
> The reference are being retained by the {{AbstractXXXMessageStore#_messages}}
> set.
> QPID-7783 added the _messages data structure. -It was back ported to 6.0 and
> 6.1, so the leak might be present there too. I have not verified this-.
> (updated 2017/10/06 does not affect 6.1 or 6.0. The
> MessageInstanceConsumerPair, which is no longer on master, unconditionally
> took a reference, so a reference was already taken).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7964) [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7964: --- Summary: [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and "," for passwords (was: [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" and "," for passwords) > [Java Client, AMQP 0-x] SCRAM SASL implementation incorrectly encodes "=" and > "," for passwords > --- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7944) [Java Broker] [AMQP1.0] Observing a message with a null object property cause 500 error to be sent to the browser
[
https://issues.apache.org/jira/browse/QPID-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196756#comment-16196756
]
Lorenz Quack commented on QPID-7944:
We seem to be running into
[JDK-8148463|https://bugs.openjdk.java.net/browse/JDK-8148463].
See also [this
Stackoverflow|https://stackoverflow.com/questions/24630963/java-8-nullpointerexception-in-collectors-tomap]
entry.
> [Java Broker] [AMQP1.0] Observing a message with a null object property cause
> 500 error to be sent to the browser
> -
>
> Key: QPID-7944
> URL: https://issues.apache.org/jira/browse/QPID-7944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> # Start the Broker
> # Configured HTTPS
> # Send an JMS message from Qpid JMS Client with setObjectProperty("mynull",
> null)
> # Try to observe the message using Management (using HTTPS).
> The browser receives a 500 and the following is logged.
> {noformat}
> 2017-10-02 08:53:23,844 ERROR [qtp163439984-248]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/queue/default/default/queue/getMessageContent':
> java.lang.NullPointerException: null
> at java.util.HashMap.merge(HashMap.java:1224)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.qpid.server.message.internal.InternalMessageHeader.(InternalMessageHeader.java:94)
> at
> org.apache.qpid.server.message.internal.InternalMessage.convert(InternalMessage.java:220)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:69)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:39)
> at
> org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3308)
> at
> org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3281)
> at
> org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:102)
> 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.ConfiguredObjectMethodOperation.perform(ConfiguredObjectMethodOperation.java:125)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:620)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:205)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:122)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:365)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
>
[jira] [Commented] (QPID-7961) [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and ","
[ https://issues.apache.org/jira/browse/QPID-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196723#comment-16196723 ] Lorenz Quack commented on QPID-7961: QPID-7964 and QPIDJMS-335 capture the client defect > [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and > "," > --- > > Key: QPID-7961 > URL: https://issues.apache.org/jira/browse/QPID-7961 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > > The SCRAM SASL mechanism requires special encoding of "=" and "," in the > username -and password-. > It seems that the broker is doing this for the username but not for the > password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7964) [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196715#comment-16196715 ] Lorenz Quack commented on QPID-7964: The SCRAM SASL implementation was ported from the AMQP 0-x client to the new AMQP 1.0 client. This porting included this bug. > [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" > and "," for passwords > -- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7964) [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" and "," for passwords
[ https://issues.apache.org/jira/browse/QPID-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7964: --- Description: Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" and "," in passwords when using the SCRAM SASL mechanism. This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires encoding of those characters for the username. Not for the password. This was reported on the [user mailing list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] was: Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" and "," in passwords when using the SCRAM SASL mechanism. This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires encoding of those characters for the username. Not for the password. > [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" > and "," for passwords > -- > > Key: QPID-7964 > URL: https://issues.apache.org/jira/browse/QPID-7964 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Lorenz Quack > > Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" > and "," in passwords when using the SCRAM SASL mechanism. > This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires > encoding of those characters for the username. Not for the password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7964) [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" and "," for passwords
Lorenz Quack created QPID-7964: -- Summary: [Java Client, AMQP 0-x] SCRAM AuthenticationProvider incorrectly encodes "=" and "," for passwords Key: QPID-7964 URL: https://issues.apache.org/jira/browse/QPID-7964 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Lorenz Quack Currently the Qpid Client for Java for AMQP 0-x encodes the characters "=" and "," in passwords when using the SCRAM SASL mechanism. This is incorrect. [The spec|https://tools.ietf.org/html/rfc5802] requires encoding of those characters for the username. Not for the password. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7961) [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and ","
[ https://issues.apache.org/jira/browse/QPID-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7961: --- Description: The SCRAM SASL mechanism requires special encoding of "=" and "," in the username -and password-. It seems that the broker is doing this for the username but not for the password. This was reported on the [user mailing list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] was: The SCRAM SASL mechanism requires special encoding of "=" and "," in the username and password. It seems that the broker is doing this for the username but not for the password. This was reported on the [user mailing list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] > [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and > "," > --- > > Key: QPID-7961 > URL: https://issues.apache.org/jira/browse/QPID-7961 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > > The SCRAM SASL mechanism requires special encoding of "=" and "," in the > username -and password-. > It seems that the broker is doing this for the username but not for the > password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7961) [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and ","
[ https://issues.apache.org/jira/browse/QPID-7961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack closed QPID-7961. -- Resolution: Invalid The problem is actually client side. the encoding should only be applied to the username. not the password. > [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and > "," > --- > > Key: QPID-7961 > URL: https://issues.apache.org/jira/browse/QPID-7961 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Lorenz Quack > > The SCRAM SASL mechanism requires special encoding of "=" and "," in the > username and password. > It seems that the broker is doing this for the username but not for the > password. > This was reported on the [user mailing > list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7961) [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and ","
Lorenz Quack created QPID-7961: -- Summary: [Java Broker] SCRAM AuthenticationProvider does not properly encode "=" and "," Key: QPID-7961 URL: https://issues.apache.org/jira/browse/QPID-7961 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack The SCRAM SASL mechanism requires special encoding of "=" and "," in the username and password. It seems that the broker is doing this for the username but not for the password. This was reported on the [user mailing list|http://mail-archives.apache.org/mod_mbox/qpid-users/201710.mbox/%3C1507290028737-0.post%40n2.nabble.com%3E] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7957) [Java Broker, AMQP 1.0] Add support for max-message-size on Attach
Lorenz Quack created QPID-7957: -- Summary: [Java Broker, AMQP 1.0] Add support for max-message-size on Attach Key: QPID-7957 URL: https://issues.apache.org/jira/browse/QPID-7957 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Lorenz Quack Fix For: qpid-java-broker-7.0.0 Currently the max-message-size on Attach is never set by the broker. We should set it to the limit configured on the Connection/VirtualHost and enforce it upon receiving Transfers. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7954) [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
Lorenz Quack created QPID-7954:
--
Summary: [Java Broker, AMQP 1.0] Improve AMQP 1.0 detach code
Key: QPID-7954
URL: https://issues.apache.org/jira/browse/QPID-7954
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Lorenz Quack
Fix For: Future
Currently the AMQP detach handling code is messy.
It could use a good refactoring and cleanup.
Also the following issues need looking into:
* Are we handling simultaneous detach correctly? There seems to be shared code
between broker- and client-side detach ({{Session_1_0#detach()}}) which unmaps
both the input and output handle.
* We should probably have a ticker timing out clients that do not send back a
detach after a broker side detach in a reasonable amount of time.
* Are all state transitions handled correctly?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7952) [Java Broker, AMQP 1.0] Changes to Terminus on Reattach/Resuming a Link are not persisted
Lorenz Quack created QPID-7952: -- Summary: [Java Broker, AMQP 1.0] Changes to Terminus on Reattach/Resuming a Link are not persisted Key: QPID-7952 URL: https://issues.apache.org/jira/browse/QPID-7952 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack Fix For: Future When establishing a Link we save the terminus in the LinkRegistry. When we reattach/resume the Link with a modified Terminus we do not update the representation in the LinkRegistry. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7951) [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang indefinitely
[
https://issues.apache.org/jira/browse/QPID-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7951:
---
Summary: [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread
to hang indefinitely (was: [Java Broker, AMQP 1.0] )
> [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang
> indefinitely
> ---
>
> Key: QPID-7951
> URL: https://issues.apache.org/jira/browse/QPID-7951
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> It seems that it is possible that a Task is submitted to be executed on the
> IOThread via doOnIOThread but is never being executed because the Connection
> is already closed. This might result in a Thread hanging indefinetely if it
> calls ACO.doSync() on the ListeningFuture of the Task.
> This was occurring in the cleanup code to
> {{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7951) [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang indefinitely
[
https://issues.apache.org/jira/browse/QPID-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7951:
---
Priority: Blocker (was: Major)
> [Java Broker, AMQP 1.0] Task on IOThread might cause Config thread to hang
> indefinitely
> ---
>
> Key: QPID-7951
> URL: https://issues.apache.org/jira/browse/QPID-7951
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
>Priority: Blocker
> Fix For: qpid-java-broker-7.0.0
>
>
> It seems that it is possible that a Task is submitted to be executed on the
> IOThread via doOnIOThread but is never being executed because the Connection
> is already closed. This might result in a Thread hanging indefinetely if it
> calls ACO.doSync() on the ListeningFuture of the Task.
> This was occurring in the cleanup code to
> {{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7951) [Java Broker, AMQP 1.0]
Lorenz Quack created QPID-7951:
--
Summary: [Java Broker, AMQP 1.0]
Key: QPID-7951
URL: https://issues.apache.org/jira/browse/QPID-7951
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Lorenz Quack
Fix For: qpid-java-broker-7.0.0
It seems that it is possible that a Task is submitted to be executed on the
IOThread via doOnIOThread but is never being executed because the Connection is
already closed. This might result in a Thread hanging indefinetely if it calls
ACO.doSync() on the ListeningFuture of the Task.
This was occurring in the cleanup code to
{{TransactionalTransferTest#receiveTransactionalAcquisitionFlowFailsDueToUnknownTransactionId}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7950) [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach does not apply the correct outcomes
Lorenz Quack created QPID-7950: -- Summary: [Java Broker, AMQP 1.0] Discharging transaction after consumer link detach does not apply the correct outcomes Key: QPID-7950 URL: https://issues.apache.org/jira/browse/QPID-7950 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Lorenz Quack Priority: Blocker Fix For: qpid-java-broker-7.0.0 Consider the following scenario: * declare transaction * receive a delivery * detach the consumer * send disposition with txn-state and Accepted outcome * discharge the transaction After this message should be deleted from the broker. It currently is not. Currently, detaching the link applies the Modified outcome to all unsettled messages therefore the disposition and discharge have no effect on them. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7932) [Java Broker, AMQP 1.0] Improve Error handling when decoding
[ https://issues.apache.org/jira/browse/QPID-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7932. Resolution: Fixed > [Java Broker, AMQP 1.0] Improve Error handling when decoding > > > Key: QPID-7932 > URL: https://issues.apache.org/jira/browse/QPID-7932 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 deserialization of composite types does currently not do proper > error handling. > This results in CONNECTION-FORCED errors when encountering a problem. > This should be improved to result in proper DECODE-ERROR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7837) Malformed annotated messages (message format 0) can lead to ClassCastException
[ https://issues.apache.org/jira/browse/QPID-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7837. Resolution: Fixed > Malformed annotated messages (message format 0) can lead to > ClassCastException > --- > > Key: QPID-7837 > URL: https://issues.apache.org/jira/browse/QPID-7837 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > As per this thread, the Broker can fail unexpectedly with illegal input. > http://qpid.2158936.n2.nabble.com/Malframed-AMQP-packets-are-accepted-tc7664321.html#none > The implementation should be sufficiently robust to fail the connection, but > the Broker service should survive. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7932) [Java Broker, AMQP 1.0] Improve Error handling when decoding
[ https://issues.apache.org/jira/browse/QPID-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack updated QPID-7932: --- Summary: [Java Broker, AMQP 1.0] Improve Error handling when decoding (was: [Java Broker, AMQP 1.0] Improve Error handling when deserializing composite types) > [Java Broker, AMQP 1.0] Improve Error handling when decoding > > > Key: QPID-7932 > URL: https://issues.apache.org/jira/browse/QPID-7932 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 deserialization of composite types does currently not do proper > error handling. > This results in CONNECTION-FORCED errors when encountering a problem. > This should be improved to result in proper DECODE-ERROR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
