[jira] [Commented] (DISPATCH-927) detach not echoed back on multi-hop link route

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464297#comment-16464297
 ] 

ASF GitHub Bot commented on DISPATCH-927:
-

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/299

DISPATCH-927 - System test for fix. Makes sure both detaches are echo…

…ed back

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-927

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/299.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #299


commit a8eb40384750ca2bd4e1fe4e0144507d0859e7fb
Author: Ganesh Murthy 
Date:   2018-05-04T19:16:43Z

DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back




> detach not echoed back on multi-hop link route
> --
>
> Key: DISPATCH-927
> URL: https://issues.apache.org/jira/browse/DISPATCH-927
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
> Attachments: DISPATCH-927.patch, broker.xml, simple-topic-a.conf, 
> simple-topic-b.conf, simple_recv_modified.py
>
>
> In a two router network, router-a and router-b, a link route is defined in 
> both directions on both routers. There is also an associated connector to a 
> broker on router-b. The address is configured to be a topic on the broker.
> If two receivers attach on this address to router-a, and then detach at the 
> same time having received the defined number of messages, frequently (but not 
> always), one of the receivers will not get a detach echoed back to it.
> On inspection of protocol traces, it appears that router-b, though it gets 
> the detach echoed back from the broker, does not forward this back to the 
> client (via router-a).



--
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

[GitHub] qpid-dispatch pull request #299: DISPATCH-927 - System test for fix. Makes s...

[ganeshmurthy]

GitHub user ganeshmurthy opened a pull request:

https://github.com/apache/qpid-dispatch/pull/299

DISPATCH-927 - System test for fix. Makes sure both detaches are echo…

…ed back

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-927

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/299.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #299


commit a8eb40384750ca2bd4e1fe4e0144507d0859e7fb
Author: Ganesh Murthy 
Date:   2018-05-04T19:16:43Z

DISPATCH-927 - System test for fix. Makes sure both detaches are echoed back




---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464100#comment-16464100
 ] 

ASF subversion and git services commented on QPID-8181:
---

Commit e84273b056abc9a38ec635c52cacbd19d0b45a99 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=e84273b ]

QPID-8181: [Broker-J] Add statistics for a total number of connections 
established on AMQP port


> [Broker-J] Add statistics for a total number of connections established on 
> AMQP port
> 
>
> Key: QPID-8181
> URL: https://issues.apache.org/jira/browse/QPID-8181
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Major
>
> A statistics for a current number of connections is available on AMQP port. 
> Introduction of additional statistic for a total number of connections 
> established on AMQP port would allow to detect such use cases as "connection 
> per message anti-pattern" without even looking into Qpid broker logs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-8181) [Broker-J] Add statistics for a total number of connections established on AMQP port

[Alex Rudyy (JIRA)]

Alex Rudyy created QPID-8181:


 Summary: [Broker-J] Add statistics for a total number of 
connections established on AMQP port
 Key: QPID-8181
 URL: https://issues.apache.org/jira/browse/QPID-8181
 Project: Qpid
  Issue Type: Improvement
  Components: Broker-J
Affects Versions: qpid-java-broker-7.1.0, qpid-java-broker-7.0.4
Reporter: Alex Rudyy


A statistics for a current number of connections is available on AMQP port. 
Introduction of additional statistic for a total number of connections 
established on AMQP port would allow to detect such use cases as "connection 
per message anti-pattern" without even looking into Qpid broker logs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPIDIT-93) Optionally produce xUnit XML report with test results

[Kim van der Riet (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDIT-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464023#comment-16464023
 ] 

Kim van der Riet commented on QPIDIT-93:


A more comprehensive xUnit XML schema is available here

[https://github.com/windyroad/JUnit-Schema]

and which includes a <{{properties>}} element containing 0..n <{{property>}} 
elements, each of which contains a name/value pair of attributes. This can be 
used to add additional information about the test in a compliant way as follows:
{noformat}

  



...
  
  
  
  
  ...
{noformat}
The question is, what information should be included?

A minimum list should be:
 * test machine identity
 * test executable path/name
 * parameters to test executable
 * broker topology (single-node, Sender->B1->B2->B3->Receiver, etc)
 * broker ip address(es)
 * broker configuration(s) - how to achieve this?

In addition, nice-to-have might include:
 * Date/timestamp/duration for test
 * Additional test description as passed on command-line
 * Broker connection properties (if necessary, for both sender and receiver if 
different)

Each {{}} element supports the following attributes:
 * name
 * classname
 * time

but I would like to add the following out-of-band attributes:
 * receiver-client
 * sender-client
 * type
 * duration of individual testcase
 * any other specialized parameter used in individual tests:
 * subtype (amqp_complex_types_test)
 * size (amqp_large_content_test)
 * headers (jms_hdrs_props_test)
 * properties (jms_hdrs_props_test)

Ideas?

> Optionally produce xUnit XML report with test results
> -
>
> Key: QPIDIT-93
> URL: https://issues.apache.org/jira/browse/QPIDIT-93
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>Affects Versions: 0.1.0
>Reporter: Jiri Daněk
>Assignee: Kim van der Riet
>Priority: Minor
> Fix For: 0.2.0
>
> Attachments: amqp_types_test.2018-01-26T09-24-24.xml, 
> jms_hdrs_props_test.2018-01-26T09-45-29.xml, xunit.xsd
>
>
> Something like the following should do the job. Instead of 
> https://pypi.python.org/pypi/unittest-xml-reporting, it might be possible to 
> maybe switch from unittest package to py.test, which has xUnit reports built 
> in.
> {noformat}
> diff --git a/src/python/qpid_interop_test/jms_messages_test.py 
> b/src/python/qpid_interop_test/jms_messages_test.py
> index 3b54510..3b94f3a 100755
> --- a/src/python/qpid_interop_test/jms_messages_test.py
> +++ b/src/python/qpid_interop_test/jms_messages_test.py
> @@ -24,19 +24,17 @@ Module to test JMS message types across different APIs
>  from json import dumps
>  from os import getenv, path
> +import xmlrunner
>  from proton import symbol
>  from qpid_interop_test.test_type_map import TestTypeMap
> @@ -302,7 +300,7 @@ class TestOptions(object):
>  Class controlling command-line arguments used to control the test.
>  """
>  def __init__(self, shim_map):
> -parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoparability test suite '
> +parser = argparse.ArgumentParser(description='Qpid-interop AMQP 
> client interoperability test suite '
>   'for JMS message types')
>  parser.add_argument('--sender', action='store', 
> default='localhost:5672', metavar='IP-ADDR:PORT',
>  help='Node to which test suite will send 
> messages.')
> @@ -313,6 +311,8 @@ class TestOptions(object):
>  parser.add_argument('--broker-type', action='store', 
> metavar='BROKER_NAME',
>  help='Disable test of broker type (using 
> connection properties) by specifying the broker' +
>  ' name, or "None".')
> +parser.add_argument('--xunit-report-dir', action='store', 
> metavar='REPORTS_DIRECTORY',
> +help='Generate xUnit report into 
> REPORTS_DIRECTORY/TEST--.xml')
>  type_group = parser.add_mutually_exclusive_group()
>  type_group.add_argument('--include-type', action='append', 
> metavar='JMS_MESSAGE-TYPE',
>  help='Name of JMS message type to include. 
> Supported types:\n%s' %
> @@ -421,6 +421,7 @@ if __name__ == '__main__':
>  TEST_SUITE.addTest(unittest.makeSuite(test_case_class))
>  
>  # Finally, run all the dynamically created tests
> -RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)
> +#RES = unittest.TextTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
> +RES = xmlrunner.XMLTestRunner(verbosity=2).run(TEST_SUITE)  # type: 
> unittest.TextTestResult
>  if not RES.wasSuccessful():
>  sys.exit(1)
> {noformat}
> The main "problem" seems that each test has 

[jira] [Resolved] (QPID-8166) [Broker-J] Remove use of ${QPID_HOME}/etc from default configuration

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8166.
--
Resolution: Fixed

The implemented changes look good to me

> [Broker-J] Remove use of ${QPID_HOME}/etc from default configuration
> 
>
> Key: QPID-8166
> URL: https://issues.apache.org/jira/browse/QPID-8166
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.1
>
>
> Currently, the Broker's default configuration relies on the contents of 
> external {{${QPID_HOME}/etc/passwd}} file.  This makes the configuration 
> fragile. Errors occur if {{$\{QPID_HOME}}} is unset or files absent.   The 
> default configuration should be switched to use a built-in password database 
> and the {{etc}} directory eliminated from the assembly.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-7546.
--
   Resolution: Fixed
 Assignee: (was: Rob Godfrey)
Fix Version/s: qpid-java-broker-7.0.0

The necessary changes have been implemented. Thus, closing the JIRA

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-7546:
-
Attachment: (was: 
0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch)

> [Java Broker] Allow the system tests to be run using the Qpid JMS client for 
> AMQP 1.0 testing
> -
>
> Key: QPID-7546
> URL: https://issues.apache.org/jira/browse/QPID-7546
> Project: Qpid
>  Issue Type: Test
>  Components: Java Tests
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
>
> Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the 
> AMQP 1.0 protocol implementation does not get as thoroughly tested.
> We should aim to move all the system tests such that they can be run with 
> either client



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7830) Heap dominated by duplicates of common routing values / header values etc

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463990#comment-16463990
 ] 

Alex Rudyy commented on QPID-7830:
--

I reviewed the changes. They look good to me. Though, I would add additional 
caching for 0-10 routing keys, exchange names (in DeliveryProperties), 
contentType (MessageProperties) and 1-0 "to" field (in Properties) as it would 
save us additional heap space and reduce frequency and length of GC pauses.

> 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: Broker-J
>Reporter: Keith Wall
>Priority: Major
> 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
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8180.
--
Resolution: Fixed

> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463985#comment-16463985
 ] 

ASF subversion and git services commented on QPID-8180:
---

Commit 4e127c21159c2bdd69f55ff8b4e087f2fb264bf5 in qpid-jms-amqp-0-x's branch 
refs/heads/6.3.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=4e127c2 ]

QPID-8180: [Qpid JMS AMQP 0-8..0-91] Improve error message used to handle a 
channel not found condition during frame dispatch.

(cherry picked from commit e4e2b6b206c8d232f01a7527a0a884abb957be53)


> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7282) Java Broker should always send server-final message (if required) to the client on succesful SASL negotiation

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463841#comment-16463841
 ] 

Alex Rudyy commented on QPID-7282:
--

Authentication providers storing credentials in broker configuration (Plain, 
SCRAM-SHA-256, SCRAM-SHA-1) are not affected by the issue. Only authentication 
providers of types PlainPasswordFile and Simple are affected

> Java Broker should always send server-final message (if required) to the 
> client on succesful SASL negotiation
> -
>
> Key: QPID-7282
> URL: https://issues.apache.org/jira/browse/QPID-7282
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1, 
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.0.4, qpid-java-6.1
>
>
> On Scram Sha SASL negotiation Broker does not send server-final challenge 
> (ServerSignature) with the following authentication providers:
> * Simple (SimpleAuthenticationManager)
> * PlainPasswordFile (PlainPasswordDatabaseAuthenticationManager)
> The sasl negotiation for Scram Sha SASL mechanisms should always include 
> sending of server-final message in order to give a chance to verify server 
> signature on a client as per  [RFC 
> 5802|https://tools.ietf.org/html/rfc5802#page-7]
> {quote}
>   The client then authenticates the server by computing the
>ServerSignature and comparing it to the value sent by the server.  If
>the two are different, the client MUST consider the authentication
>exchange to be unsuccessful, and it might have to drop the
>connection.
> {quote}
> We need to change all existing Authentication Provider to support sending of 
> final message



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-8141) [JMS AMQP 0-x] Cannot publish message with address based destinations falsely identified as resolved due to unset routing key and exchange name

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-8141.
--
Resolution: Fixed
  Assignee: (was: Keith Wall)

> [JMS AMQP 0-x] Cannot publish message with address based destinations falsely 
> identified as resolved due to unset routing key and exchange name
> ---
>
> Key: QPID-8141
> URL: https://issues.apache.org/jira/browse/QPID-8141
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Address based destination resolution functionality 
> {{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
> {{exchange name}}, etc as part of invocation of 
> {{AMQSession#setLegacyFieldsForQueueType}}. If destination object is 
> identified as resolved {{AMQSession#isResolved}} the essential fields are not 
> set on the destination object. As result, publishing attempts with such 
> destination objects will fail due to routing issues like the one reported 
> below:
> {noformat}
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
>   at 
> org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
>   ... 6 more
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at 
> org.apache.qpid.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:90)
>   at 
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:227)
>   at 
> org.apache.qpid.framing.ConnectionCloseBody.execute(ConnectionCloseBody.java:105)
>   at 
> org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
>   at 
> org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
>   at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:549)
>   at 
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:164)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The clients applications creating new destination objects on every publishing 
> attempt using the same session are impacted by the issue.
> The following code snippet demonstrate the problem:
> {code}
> MessageProducer messageProducer = session.createProducer(null);
> for (int i=0;i {
> Message message = session.createTextMessage("Test");
> messageProducer.send(session.createQueue(String.format(
> 
> "ADDR:test;{\"create\":\"always\",\"node\":{\"type\":\"queue\",\"durable\":true}}")),
>  message);
> }
> session.commit();
> {code}
> The work around would be to avoid creation of destination objects every time. 
> For example, Qpid JNDI properties can be used to declare and cache the 
> destination objects. 
> {code}
> destination.queue=ADDR:test;{"create":"always","node":"type":"queue","durable":true}}
> {code}
> {code}
> Destination destination = (Destination)context.lookup("queue")
> {code}
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (QPID-8141) [JMS AMQP 0-x] Cannot publish message with address based destinations falsely identified as resolved due to unset routing key and exchange name

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463783#comment-16463783
 ] 

Alex Rudyy commented on QPID-8141:
--

Changes in commits 
[https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=a762b9d], 
[https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=6a5ffcf], 
[https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=f5fb52d] and 
corresponding merges look good to me

> [JMS AMQP 0-x] Cannot publish message with address based destinations falsely 
> identified as resolved due to unset routing key and exchange name
> ---
>
> Key: QPID-8141
> URL: https://issues.apache.org/jira/browse/QPID-8141
> Project: Qpid
>  Issue Type: Bug
>  Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> Address based destination resolution functionality 
> {{AMQSession#resolveAddress}} sets a number of fields like {{routing key}}, 
> {{exchange name}}, etc as part of invocation of 
> {{AMQSession#setLegacyFieldsForQueueType}}. If destination object is 
> identified as resolved {{AMQSession#isResolved}} the essential fields are not 
> set on the destination object. As result, publishing attempts with such 
> destination objects will fail due to routing issues like the one reported 
> below:
> {noformat}
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:81)
>   at 
> org.apache.qpid.AMQException.cloneForCurrentThread(AMQException.java:24)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.writeCommandFrameAndWaitForReply(AMQProtocolHandler.java:638)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:675)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.syncWrite(AMQProtocolHandler.java:669)
>   at 
> org.apache.qpid.client.AMQSession_0_8.commitImpl(AMQSession_0_8.java:271)
>   at org.apache.qpid.client.AMQSession.commit(AMQSession.java:913)
>   ... 6 more
> Caused by: org.apache.qpid.AMQConnectionClosedException: Error: No route for 
> message with exchange 'null' and routing key 'null' [error code: 312(no 
> route)]
>   at 
> org.apache.qpid.client.handler.ConnectionCloseMethodHandler.methodReceived(ConnectionCloseMethodHandler.java:90)
>   at 
> org.apache.qpid.client.handler.ClientMethodDispatcherImpl.dispatchConnectionClose(ClientMethodDispatcherImpl.java:227)
>   at 
> org.apache.qpid.framing.ConnectionCloseBody.execute(ConnectionCloseBody.java:105)
>   at 
> org.apache.qpid.client.state.AMQStateManager.methodReceived(AMQStateManager.java:118)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.methodBodyReceived(AMQProtocolHandler.java:531)
>   at 
> org.apache.qpid.client.protocol.AMQProtocolSession.methodFrameReceived(AMQProtocolSession.java:460)
>   at 
> org.apache.qpid.framing.AMQMethodBodyImpl.handle(AMQMethodBodyImpl.java:66)
>   at 
> org.apache.qpid.client.AMQProtocolHandler.received(AMQProtocolHandler.java:480)
>   at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:549)
>   at 
> org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:164)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The clients applications creating new destination objects on every publishing 
> attempt using the same session are impacted by the issue.
> The following code snippet demonstrate the problem:
> {code}
> MessageProducer messageProducer = session.createProducer(null);
> for (int i=0;i {
> Message message = session.createTextMessage("Test");
> messageProducer.send(session.createQueue(String.format(
> 
> "ADDR:test;{\"create\":\"always\",\"node\":{\"type\":\"queue\",\"durable\":true}}")),
>  message);
> }
> session.commit();
> {code}
> The work around would be to avoid creation of destination objects every time. 
> For example, Qpid JNDI properties can be used to declare and cache the 
> destination objects. 
> 

[jira] [Assigned] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8167:


Assignee: Keith Wall  (was: Alex Rudyy)

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Alex Rudyy (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463719#comment-16463719
 ] 

Alex Rudyy commented on QPID-8180:
--

The changes look good to me. I am going to merge them into 6.3.x branch for 
inclusion into 6.3.1 release.

> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
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-8165) [Broker-J][WMC] Validation of configured object names is too restrictive in Web Management Console

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8165:
-
Description: 
WMC only allows to create (or edit) configured objects with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
match regular expression (as per documentation for connection open)
{code}
^[a-zA-Z0-9/-_]+$
{code}

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}

As a minimum, the Web Management Console should allow creation of queues, 
exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}. The virtual host names 
matching regular expression {{^[a-zA-Z0-9/-_]+$}} should be allowed . The names 
of other configured objects can be unrestricted. 

Alternatively, we can add some sort of AMQP compatibility modes to Web 
Management Console and management API when required level compatibility can be 
configured by the user and different validation rules can apply based on 
required compatibility.



  was:
WMC only allows to create (or edit) configured objects with names consisting 
only from any mixture of digits, letters, and underscores. This restriction was 
added into Web Management Console to meet the requirements of AMQP 0-8 
protocol. The queue and exchange names in  domain definition are defined as  
name consisting only from digits, letters, and underscores.

{quote}
The queue name identifies the queue within the vhost.  Queue
names may consist of any mixture of digits, letters, and
underscores.
{quote}

{quote}
The exchange name is a client-selected string that identifies
  the exchange for publish methods.  Exchange names may consist
  of any mixture of digits, letters, and underscores.  Exchange
  names are scoped by the virtual host.
{quote}

However, in definitions of declare commands for queue and exchange  the AMQP 
0-8 specifies a regular expression for the names allowing more characters:
{code}
^[a-zA-Z0-9-_.:]*$
{code}
The same regular expression is defined in specifications for AMQP 0-9 and 0-9-1.

The names of virtual hosts in specifications for AMQP 0-8 and AMQP 0-9 should 
match regular expression (as per documentation of connection open)
{code}
^[a-zA-Z0-9-_.:]*$
{code}

AMQP 0-10 allows more characters in queue name

{quote}
 Queue names must have a length
of between 1 and 255 characters inclusive, must start with a digit, 
letter or underscores
('_') character, and must be otherwise encoded in UTF-8.
{quote}

As a minimum, the Web Management Console should allow creation of queues, 
exchanges with names matching {{^[a-zA-Z0-9-_.:]*$}}. The virtual host names 
matching regular expression {{^[a-zA-Z0-9/-_]+$}} should be allowed . The names 
of other configured objects can be unrestricted. 

Alternatively, we can add some sort of AMQP compatibility modes to Web 
Management Console and management API when required level compatibility can be 
configured by the user and different validation rules can apply based on 
required compatibility.




> [Broker-J][WMC] Validation of configured object names is too restrictive in 
> Web Management Console
> --
>
> Key: QPID-8165
> URL: https://issues.apache.org/jira/browse/QPID-8165
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 
> qpid-java-broker-7.0.2, qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, 
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1, 
> qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2, qpid-java-6.0.7, 
> qpid-java-6.1.3, qpid-java-6.0.8, 

[jira] [Updated] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8180:
-
Fix Version/s: qpid-java-client-0-x-6.3.1

> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
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-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8180:
-
Status: Reviewable  (was: In Progress)

> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.1
>
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall reassigned QPID-8180:


Assignee: Keith Wall

> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16463679#comment-16463679
 ] 

ASF subversion and git services commented on QPID-8180:
---

Commit e4e2b6b206c8d232f01a7527a0a884abb957be53 in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=e4e2b6b ]

QPID-8180: [Qpid JMS AMQP 0-8..0-91] Improve error message used to handle a 
channel not found condition during frame dispatch.


> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Priority: Minor
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
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-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-8180:
-
Description: 
A defect report against a 0.32 derivative client included a seemingly 
spontaneous  NullPointerException stack trace whilst the IOReceiver was 
processing an incoming content.body frame.  There is no indication that the 
underlying channel had been closed.

{noformat}
2018-05-01 15:30:27.914 ERROR Exception processing frame
  
[IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
java.lang.NullPointerException: null
at 
org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
 ~[qpid-client-x.x.x.jar: x.x.x]
at 
org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
 ~[qpid-client- x.x.x.jar: x.x.x]
at 
org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) ~[qpid-common- 
x.x.x.jar: x.x.x]
at 
org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
 [qpid-client- x.x.x.jar: x.x.x]
at 
org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
 [qpid-client- x.x.x.jar:5.1.8]
at 
org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
 [qpid-client- x.x.x.jar: x.x.x]
at 
org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
 [qpid-client- x.x.x.jar: x.x.x]
{noformat}

Attempts to reproduce the problem have so far been unsuccessful. Improving the 
error message used in this situation should help a future investigation, if it 
occurs again.


  was:
A defect report against a 0.32 derivative client included a seemingly 
spontaneous  NullPointerException stack trace whilst the IOReceiver was 
processing an incoming content.body frame.  There is no indication that the 
underlying channel had been closed.

Attempts to reproduce the problem have so far been unsuccessful. Improving the 
error message used in this situation should help a future investigation, if it 
occurs again.



> [JMS AMQP 0-8..0-91] Improve error message associated with the channel not 
> found during frame dispatch
> --
>
> Key: QPID-8180
> URL: https://issues.apache.org/jira/browse/QPID-8180
> Project: Qpid
>  Issue Type: Improvement
>  Components: JMS AMQP 0-x
>Affects Versions: 0.32
>Reporter: Keith Wall
>Priority: Minor
>
> A defect report against a 0.32 derivative client included a seemingly 
> spontaneous  NullPointerException stack trace whilst the IOReceiver was 
> processing an incoming content.body frame.  There is no indication that the 
> underlying channel had been closed.
> {noformat}
> 2018-05-01 15:30:27.914 ERROR Exception processing frame  
> 
> [IoRcvr-/x.x.x.x:45506-yyy-rrqpid1.us.x.xx/x.xx.x:5681][AMQProtocolHandler.java:512]
> java.lang.NullPointerException: null
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.deliverMessageToAMQSession(AMQProtocolSession.java:290)
>  ~[qpid-client-x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolSession.contentBodyReceived(AMQProtocolSession.java:272)
>  ~[qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.framing.ContentBody.handle(ContentBody.java:72) 
> ~[qpid-common- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:492)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.protocol.AMQProtocolHandler.received(AMQProtocolHandler.java:120)
>  [qpid-client- x.x.x.jar:5.1.8]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:538)
>  [qpid-client- x.x.x.jar: x.x.x]
> at 
> org.apache.qpid.client.AMQConnectionDelegate_8_0$ReceiverClosedWaiter.received(AMQConnectionDelegate_8_0.java:524)
>  [qpid-client- x.x.x.jar: x.x.x]
> {noformat}
> Attempts to reproduce the problem have so far been unsuccessful. Improving 
> the error message used in this situation should help a future investigation, 
> if it occurs again.



--
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: 

[jira] [Created] (QPID-8180) [JMS AMQP 0-8..0-91] Improve error message associated with the channel not found during frame dispatch

[Keith Wall (JIRA)]

Keith Wall created QPID-8180:


 Summary: [JMS AMQP 0-8..0-91] Improve error message associated 
with the channel not found during frame dispatch
 Key: QPID-8180
 URL: https://issues.apache.org/jira/browse/QPID-8180
 Project: Qpid
  Issue Type: Improvement
  Components: JMS AMQP 0-x
Affects Versions: 0.32
Reporter: Keith Wall


A defect report against a 0.32 derivative client included a seemingly 
spontaneous  NullPointerException stack trace whilst the IOReceiver was 
processing an incoming content.body frame.  There is no indication that the 
underlying channel had been closed.

Attempts to reproduce the problem have so far been unsuccessful. Improving the 
error message used in this situation should help a future investigation, if it 
occurs again.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Assigned] (QPID-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy reassigned QPID-8167:


Assignee: Alex Rudyy

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
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-8167) [Broker-J] Broker command line option '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-8167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy updated QPID-8167:
-
Status: Reviewable  (was: In Progress)

> [Broker-J] Broker command line option 
> '-mmqv/--management-mode-quiesce-virtualhosts' does not quiesce virtual hosts
> ---
>
> Key: QPID-8167
> URL: https://issues.apache.org/jira/browse/QPID-8167
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3, 0.26, 0.28, 
> 0.32, qpid-java-6.0.8
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> When command line option '-mmqv/--management-mode-quiesce-virtualhosts' is 
> set to true and management mode is requested to start the broker, the 
> existing virtual hosts are not  started in QUIESCED state. Their state remain 
> ACTIVE. 
> It seems this issue exists since introduction of virtual host nodes. 
> {{ManagementModeStoreHandler}} is looking for the entries of type 
> {{VirtualHost }} but such types are not stored in the broker configuration 
> store anymore.
> Either we need to re-purpose this option to quiesce virtual host nodes, or, 
> remove it completely.



--
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] [Closed] (QPID-8179) qpid_messaging (amqp1.0) randomly hangs when closing the connection.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/QPID-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Håkan Johansson closed QPID-8179.
-

> qpid_messaging (amqp1.0) randomly hangs when closing the connection.
> 
>
> Key: QPID-8179
> URL: https://issues.apache.org/jira/browse/QPID-8179
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Håkan Johansson
>Priority: Major
>
> We are using {{qpid_messaging}} to communicate with an ActiveMQ broker using 
> the {{amqp1.0}} protocol.
> We have noticed during both large scale tests and in production that our 
> program sometimes hangs when it is closing the connection to the broker. This 
> is a very rare occurrence, but happens often enough to be annoying.
> While the design of the {{amqp1.0}} implementation is generally nice, I have 
> noticed a lack of life cycle management for the helper objects, especially 
> the ones interacting with background threads. The background thread is shut 
> down when closing the last remaining connection, but not enough care is being 
> taken to make sure it is in a safe state to do so.
> If an event is being processed when the connection is closed, then a deadlock 
> might occur, as seen in this stack-trace:
> {noformat}
> #0  0x7fd104f26945 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /usr/lib64/libpthread.so.0
> #1  0x7fd10111a420 in qpid::sys::Condition::wait (this=, 
> mutex=...) at /qpid-cpp-1.38.0/src/qpid/sys/posix/Condition.h:59
> #2  0x7fd10112489b in wait (this=0xbaff20) at 
> /qpid-cpp-1.38.0/src/qpid/sys/Monitor.h:41
> #3  qpid::sys::TimerTask::cancel (this=0xbafef0) at 
> /qpid-cpp-1.38.0/src/qpid/sys/Timer.cpp:94
> #4  0x7fd105bb367f in qpid::messaging::amqp::ConnectionContext::close 
> (this=0xb7b350) at 
> /qpid-cpp-1.38.0/src/qpid/messaging/amqp/ConnectionContext.cpp:246
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-8179) qpid_messaging (amqp1.0) randomly hangs when closing the connection.

[JIRA]

 [ 
https://issues.apache.org/jira/browse/QPID-8179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Håkan Johansson resolved QPID-8179.
---
Resolution: Not A Bug

Now that my test program is running against the correct version of qpid-cpp it 
has been running the whole night without hanging.

Closing this jira as the bug has already been fixed.

> qpid_messaging (amqp1.0) randomly hangs when closing the connection.
> 
>
> Key: QPID-8179
> URL: https://issues.apache.org/jira/browse/QPID-8179
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: qpid-cpp-1.38.0
>Reporter: Håkan Johansson
>Priority: Major
>
> We are using {{qpid_messaging}} to communicate with an ActiveMQ broker using 
> the {{amqp1.0}} protocol.
> We have noticed during both large scale tests and in production that our 
> program sometimes hangs when it is closing the connection to the broker. This 
> is a very rare occurrence, but happens often enough to be annoying.
> While the design of the {{amqp1.0}} implementation is generally nice, I have 
> noticed a lack of life cycle management for the helper objects, especially 
> the ones interacting with background threads. The background thread is shut 
> down when closing the last remaining connection, but not enough care is being 
> taken to make sure it is in a safe state to do so.
> If an event is being processed when the connection is closed, then a deadlock 
> might occur, as seen in this stack-trace:
> {noformat}
> #0  0x7fd104f26945 in pthread_cond_wait@@GLIBC_2.3.2 () from 
> /usr/lib64/libpthread.so.0
> #1  0x7fd10111a420 in qpid::sys::Condition::wait (this=, 
> mutex=...) at /qpid-cpp-1.38.0/src/qpid/sys/posix/Condition.h:59
> #2  0x7fd10112489b in wait (this=0xbaff20) at 
> /qpid-cpp-1.38.0/src/qpid/sys/Monitor.h:41
> #3  qpid::sys::TimerTask::cancel (this=0xbafef0) at 
> /qpid-cpp-1.38.0/src/qpid/sys/Timer.cpp:94
> #4  0x7fd105bb367f in qpid::messaging::amqp::ConnectionContext::close 
> (this=0xb7b350) at 
> /qpid-cpp-1.38.0/src/qpid/messaging/amqp/ConnectionContext.cpp:246
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org