Review Request 67678: when indicating a routed link has been detached due to loss of connection, set close flag based on ability of terminus to survive disconnection

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67678/
---

Review request for qpid and Ted Ross.


Bugs: DISPATCH-1020
https://issues.apache.org/jira/browse/DISPATCH-1020


Repository: qpid-dispatch


Description
---

This ensures that the broker (or other route container) will clean-up the 
terminus state when the client is disconnected, unless that state is supposed 
to survive disconnection.

This is an alternative approach to solving DISPATCH-1020 to 
https://reviews.apache.org/r/67661/


Diffs
-

  src/router_core/connections.c 5fdc3bf 
  src/router_core/router_core_private.h cd2ffa4 


Diff: https://reviews.apache.org/r/67678/diff/1/


Testing
---


Thanks,

Gordon Sim

[GitHub] qpid-dispatch issue #296: WIP - Introduce a new structure under docs for mul...

[ssorj]

Github user ssorj commented on the issue:

https://github.com/apache/qpid-dispatch/pull/296
  
@bhardesty, agreed.  I'll get final confirmation from the dispatch folks 
and then go ahead.


---

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

[jira] [Assigned] (DISPATCH-1045) Sometimes close connetion after releasing partial multi-frame messsage

[Alan Conway (JIRA)]

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

Alan Conway reassigned DISPATCH-1045:
-

Assignee: Ganesh Murthy

> Sometimes close connetion after releasing partial multi-frame messsage
> --
>
> Key: DISPATCH-1045
> URL: https://issues.apache.org/jira/browse/DISPATCH-1045
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Router Node
>Affects Versions: 1.1.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Major
>
> Since DISPATCH-1012 the router releases undeliverable deliveries.
> In the case of a multi-frame delivery, it is possible for dispatch to release 
> it before the entire delivery has been received. Presently dispatch settles 
> such deliveries and advances its link. That means that if another transfer 
> for the same delivery arrives, dispatch regards it as a new message with an 
> invalid delivery-id and closes the connection. Since the release is 
> asynchronous, there's no way for the client to avoid this possibility.
> Worth checking the spec but I suspect we should be dropping the extra data 
> rather than closing the connection. Need to investigate how this would work 
> in proton - I think we'd update the delivery without settling it and then 
> wait for the remote to settle before finally throwing it away.
>  



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

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

[jira] [Created] (DISPATCH-1045) Sometimes close connetion after releasing partial multi-frame messsage

[Alan Conway (JIRA)]

Alan Conway created DISPATCH-1045:
-

 Summary: Sometimes close connetion after releasing partial 
multi-frame messsage
 Key: DISPATCH-1045
 URL: https://issues.apache.org/jira/browse/DISPATCH-1045
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Router Node
Affects Versions: 1.1.0
Reporter: Alan Conway


Since DISPATCH-1012 the router releases undeliverable deliveries.

In the case of a multi-frame delivery, it is possible for dispatch to release 
it before the entire delivery has been received. Presently dispatch settles 
such deliveries and advances its link. That means that if another transfer for 
the same delivery arrives, dispatch regards it as a new message with an invalid 
delivery-id and closes the connection. Since the release is asynchronous, 
there's no way for the client to avoid this possibility.

Worth checking the spec but I suspect we should be dropping the extra data 
rather than closing the connection. Need to investigate how this would work in 
proton - I think we'd update the delivery without settling it and then wait for 
the remote to settle before finally throwing it away.

 



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

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

[jira] [Commented] (QPIDJMS-2) [IGNORE ME] Subversion & Git to JIRA integration test

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518403#comment-16518403
 ] 

ASF subversion and git services commented on QPIDJMS-2:
---

Commit 1ba083b5ab7ca9369f23f84c8c86b7135743 in qpid-jms's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=1ba ]

QPIDJMS-2: commit for testing git to JIRA comment bot again, ignore.


> [IGNORE ME] Subversion & Git to JIRA integration test 
> --
>
> Key: QPIDJMS-2
> URL: https://issues.apache.org/jira/browse/QPIDJMS-2
> Project: Qpid JMS
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
>
> JIRA for testing gitsvn2jira integration, as with QPID-4891 and PROTON-321



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

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

[jira] [Commented] (QPIDJMS-2) [IGNORE ME] Subversion & Git to JIRA integration test

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPIDJMS-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518397#comment-16518397
 ] 

ASF subversion and git services commented on QPIDJMS-2:
---

Commit 8dd21f673d69d157b490ddc3c22e567ac45bc902 in qpid-jms's branch 
refs/heads/master from [~gemmellr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=8dd21f6 ]

QPIDJMS-2: commit for testing git to JIRA comment bot, ignore.


> [IGNORE ME] Subversion & Git to JIRA integration test 
> --
>
> Key: QPIDJMS-2
> URL: https://issues.apache.org/jira/browse/QPIDJMS-2
> Project: Qpid JMS
>  Issue Type: Task
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Major
>
> JIRA for testing gitsvn2jira integration, as with QPID-4891 and PROTON-321



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

Re: Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client

[Gordon Sim]

> On June 20, 2018, 1:12 p.m., Kenneth Giusti wrote:
> > include/qpid/dispatch/router_core.h
> > Lines 350 (patched)
> > 
> >
> > nit:
> > 
> > I hate to be "that guy" but I find the the name of the function 
> > ambiguous. I'd expect a "check" to either succeed or fail.  Perhaps 
> > something along the lines of
> > 
> > qdr_terminus_set_default_expiry(*term)
> > 
> > or
> > 
> > qdr_terminus_set_default_expiry(*term, default)
> > 
> > would be more flexible?
> 
> Gordon Sim wrote:
> I agree it is not a great name... how about 
> qdr_terminus_set_link_expire_if_unset? Is that too long?

I've updated the name now.


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67661/#review205063
---


On June 20, 2018, 5 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67661/
> ---
> 
> (Updated June 20, 2018, 5 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Ted Ross.
> 
> 
> Bugs: DISPATCH-1020
> https://issues.apache.org/jira/browse/DISPATCH-1020
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> The default expiry policy for a terminus is session-end. Now that link routed 
> links share a session by default, this is likely not what is wanted (terminus 
> state on a broker would have to be kept until the session ended, which is 
> when the connection between broker and router ends). This change propagates 
> an explicit link-detach policy where none is explicitly requested by the 
> client. If the client does request an explicit policy, that is propagated 
> without alteration.
> 
> Note this requires a change to proton PROTON-1866, 
> https://reviews.apache.org/r/67659/
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/system_tests_link_routes.py 57e6d41 
> 
> 
> Diff: https://reviews.apache.org/r/67661/diff/2/
> 
> 
> Testing
> ---
> 
> Automated tests added, all existing tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67661/
---

(Updated June 20, 2018, 5 p.m.)


Review request for qpid, Alan Conway and Ted Ross.


Changes
---

Changed method name to hopefully be a bit more intuitive


Bugs: DISPATCH-1020
https://issues.apache.org/jira/browse/DISPATCH-1020


Repository: qpid-dispatch


Description
---

The default expiry policy for a terminus is session-end. Now that link routed 
links share a session by default, this is likely not what is wanted (terminus 
state on a broker would have to be kept until the session ended, which is when 
the connection between broker and router ends). This change propagates an 
explicit link-detach policy where none is explicitly requested by the client. 
If the client does request an explicit policy, that is propagated without 
alteration.

Note this requires a change to proton PROTON-1866, 
https://reviews.apache.org/r/67659/


Diffs (updated)
-

  include/qpid/dispatch/router_core.h 8f144b0 
  src/router_core/connections.c 5fdc3bf 
  src/router_core/terminus.c 4c0e0a3 
  tests/system_tests_link_routes.py 57e6d41 


Diff: https://reviews.apache.org/r/67661/diff/2/

Changes: https://reviews.apache.org/r/67661/diff/1-2/


Testing
---

Automated tests added, all existing tests pass.


Thanks,

Gordon Sim

[GitHub] qpid-dispatch issue #296: WIP - Introduce a new structure under docs for mul...

[bhardesty]

Github user bhardesty commented on the issue:

https://github.com/apache/qpid-dispatch/pull/296
  
@ssorj I think this can be rebased and merged now.


---

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

Re: Review Request 66839: translation of remote address in link route

[Gordon Sim]

> On June 20, 2018, 2:22 p.m., Ganesh Murthy wrote:
> > 1. Should displayLinkRoutes() function in qpid-dispatch/tools/qdstat be 
> > modified to show "addExternalPrefix" and "delExternalPrefix" attributes?  
> > 2. I think we should have an additional test added to 
> > system_tests_link_routes_add_external_prefix which will run qdmanage query 
> > on link routes and make sure that "addExternalPrefix" and 
> > "delExternalPrefix" are showing correctly

Done. (The extra columns do add a little noise to the qdstat output considering 
they will often not be set)


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/#review205080
---


On June 20, 2018, 4:25 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66839/
> ---
> 
> (Updated June 20, 2018, 4:25 p.m.)
> 
> 
> Review request for qpid and Ted Ross.
> 
> 
> Bugs: DISPATCH-980
> https://issues.apache.org/jira/browse/DISPATCH-980
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> This adds two fields to the link route config, addExternalPrefix and 
> delExternalPrefix, that behave similar to the externalAddr in auto links. 
> I.e. they will cause a prefix to be inserted and/or deleted in the final hop 
> for a link routed link attach. That prefix will also be stripped off or 
> inserted back into the reply, making the renaming completely transparent to 
> clients.
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   python/qpid_dispatch/management/qdrouter.json 42f501f 
>   src/router_config.c 94758df 
>   src/router_core/agent_config_link_route.h 57f6f0d 
>   src/router_core/agent_config_link_route.c 981d142 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/forwarder.c fca19c3 
>   src/router_core/route_control.h 3c715bc 
>   src/router_core/route_control.c 61f426d 
>   src/router_core/router_core.c 9d7f7a5 
>   src/router_core/router_core_private.h cd2ffa4 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/CMakeLists.txt 159521d 
>   tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 
>   tools/qdstat 1e3a3a3 
> 
> 
> Diff: https://reviews.apache.org/r/66839/diff/5/
> 
> 
> Testing
> ---
> 
> Added system tests plus some ad hoc testing.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 66839: translation of remote address in link route

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/
---

(Updated June 20, 2018, 4:25 p.m.)


Review request for qpid and Ted Ross.


Changes
---

Added new fields to qdstat output; added a test for qdstat change.


Bugs: DISPATCH-980
https://issues.apache.org/jira/browse/DISPATCH-980


Repository: qpid-dispatch


Description
---

This adds two fields to the link route config, addExternalPrefix and 
delExternalPrefix, that behave similar to the externalAddr in auto links. I.e. 
they will cause a prefix to be inserted and/or deleted in the final hop for a 
link routed link attach. That prefix will also be stripped off or inserted back 
into the reply, making the renaming completely transparent to clients.


Diffs (updated)
-

  include/qpid/dispatch/router_core.h 8f144b0 
  python/qpid_dispatch/management/qdrouter.json 42f501f 
  src/router_config.c 94758df 
  src/router_core/agent_config_link_route.h 57f6f0d 
  src/router_core/agent_config_link_route.c 981d142 
  src/router_core/connections.c 5fdc3bf 
  src/router_core/forwarder.c fca19c3 
  src/router_core/route_control.h 3c715bc 
  src/router_core/route_control.c 61f426d 
  src/router_core/router_core.c 9d7f7a5 
  src/router_core/router_core_private.h cd2ffa4 
  src/router_core/terminus.c 4c0e0a3 
  tests/CMakeLists.txt 159521d 
  tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 
  tools/qdstat 1e3a3a3 


Diff: https://reviews.apache.org/r/66839/diff/5/

Changes: https://reviews.apache.org/r/66839/diff/4-5/


Testing
---

Added system tests plus some ad hoc testing.


Thanks,

Gordon Sim

[jira] [Created] (DISPATCH-1044) Link routed deliveries not included in the global transit and egress counts

[Ganesh Murthy (JIRA)]

Ganesh Murthy created DISPATCH-1044:
---

 Summary: Link routed deliveries not included in the global transit 
and egress counts
 Key: DISPATCH-1044
 URL: https://issues.apache.org/jira/browse/DISPATCH-1044
 Project: Qpid Dispatch
  Issue Type: Bug
  Components: Container
Affects Versions: 1.1.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
 Fix For: 1.2.0


Setup a two router network using the attached config files. Start a broker and 
create a queue called pulp.task

 

Connect to the first broker and send 100 messages like this -
{noformat}
python simple_send.py -m100 --address 0.0.0.0:24822/pulp.task{noformat}
These messages enter the first router and are forwarded to the second router 
which in turn forwards it via the route-container connection to the broker.

Run qdstat -g on the first router, the deliveries transit shows 0, must show 100

Run qdstat -g against the second router and notice that the deliveries egress 
is 0 it should be 100



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

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

[jira] [Updated] (QPIDIT-100) Check status of broker between tests

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPIDIT-100:

Fix Version/s: (was: 0.2.0)

> Check status of broker between tests
> 
>
> Key: QPIDIT-100
> URL: https://issues.apache.org/jira/browse/QPIDIT-100
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Improvement
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Minor
>
> If the broker should stop during a test, the test will continue to try to run 
> all of the tests.  A check should be made between each test that will ensure 
> the broker is still present. Perhaps a check of the PID will suffice.
> Note that for some broker configurations (such as multi-node dispatch router 
> tests), multiple nodes and/or brokers may be present, and all of them must be 
> checked.
> If one or more of the test nodes is missing, the test should immediately 
> terminate with an error 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] [Updated] (QPIDIT-8) Implement AMQP type array

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPIDIT-8:
--
Fix Version/s: (was: 0.2.0)
   Future

> Implement AMQP type array
> -
>
> Key: QPIDIT-8
> URL: https://issues.apache.org/jira/browse/QPIDIT-8
> Project: Apache QPID Interoperability Test Suite
>  Issue Type: Task
>  Components: Proton Python Shim
>Affects Versions: 0.1.0
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
> Fix For: Future
>
>
> The AMQP type array has not been implemented in any of the shims.



--
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] (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:all-tabpanel
 ]

Kim van der Riet resolved QPIDIT-93.

Resolution: Fixed

> 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 completely separate main method 
> and builds up options from scratch. Adding this to every test would mean some 
> unnecessary duplication. So maybe refactor this somewhat at first? On the 
> other hand, there are good reasons to keep the tests simple...
> What do you think?



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPID-8211:
---
Status: Reviewable  (was: In Progress)

> [legacystore] Place deprecation warnings in cmake and in log when starting
> --
>
> Key: QPID-8211
> URL: https://issues.apache.org/jira/browse/QPID-8211
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> After a discussion on the users list, it has been decided to place 
> deprecation notices in the cmake scripts and in the log files at WARNING 
> level when the legacystore module is loaded on broker start. The legacystore 
> will be removed from the source code tree at some point in the 
> not-too-distant future (perhaps six months or so).



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Kim van der Riet (JIRA)]

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

Kim van der Riet commented on QPID-8211:


I have committed the change. The usual automatically created notice has not 
appeared (yet). The commit details are:

[https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;a=commit;h=91ed1489de7ab74d99f9d7198b90583454e96c5e]

QPID-8211: Placed a deprecation notice into the cmake script, also into the log 
file at warning level when the store is intialized on broker startup.

> [legacystore] Place deprecation warnings in cmake and in log when starting
> --
>
> Key: QPID-8211
> URL: https://issues.apache.org/jira/browse/QPID-8211
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> After a discussion on the users list, it has been decided to place 
> deprecation notices in the cmake scripts and in the log files at WARNING 
> level when the legacystore module is loaded on broker start. The legacystore 
> will be removed from the source code tree at some point in the 
> not-too-distant future (perhaps six months or so).



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Kim van der Riet (JIRA)]

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

Kim van der Riet updated QPID-8211:
---
Description: After a discussion on the users list, it has been decided to 
place deprecation notices in the cmake scripts and in the log files at WARNING 
level when the legacystore module is loaded on broker start. The legacystore 
will be removed from the source code tree at some point in the not-too-distant 
future (perhaps six months or so).  (was: After a discussion on the users list, 
it has been decided to place deprecation notices in the cmake scripts and in 
the log files at WARNING level when the linearstore module is loaded on broker 
start. The linearstore will be removed from the source code tree at some point 
in the not-too-distant future (perhaps six months or so).)

> [legacystore] Place deprecation warnings in cmake and in log when starting
> --
>
> Key: QPID-8211
> URL: https://issues.apache.org/jira/browse/QPID-8211
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> After a discussion on the users list, it has been decided to place 
> deprecation notices in the cmake scripts and in the log files at WARNING 
> level when the legacystore module is loaded on broker start. The legacystore 
> will be removed from the source code tree at some point in the 
> not-too-distant future (perhaps six months or so).



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Kim van der Riet (JIRA)]

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

Kim van der Riet commented on QPID-8211:


Oops, yes. I'll edit that. Thanks for pointing it out!

> [legacystore] Place deprecation warnings in cmake and in log when starting
> --
>
> Key: QPID-8211
> URL: https://issues.apache.org/jira/browse/QPID-8211
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> After a discussion on the users list, it has been decided to place 
> deprecation notices in the cmake scripts and in the log files at WARNING 
> level when the linearstore module is loaded on broker start. The linearstore 
> will be removed from the source code tree at some point in the 
> not-too-distant future (perhaps six months or so).



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Chris Richardson (JIRA)]

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

Chris Richardson commented on QPID-8211:


I hope you mean "legacystore" ;)

 

> [legacystore] Place deprecation warnings in cmake and in log when starting
> --
>
> Key: QPID-8211
> URL: https://issues.apache.org/jira/browse/QPID-8211
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Reporter: Kim van der Riet
>Assignee: Kim van der Riet
>Priority: Major
>
> After a discussion on the users list, it has been decided to place 
> deprecation notices in the cmake scripts and in the log files at WARNING 
> level when the linearstore module is loaded on broker start. The linearstore 
> will be removed from the source code tree at some point in the 
> not-too-distant future (perhaps six months or so).



--
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-8211) [legacystore] Place deprecation warnings in cmake and in log when starting

[Kim van der Riet (JIRA)]

Kim van der Riet created QPID-8211:
--

 Summary: [legacystore] Place deprecation warnings in cmake and in 
log when starting
 Key: QPID-8211
 URL: https://issues.apache.org/jira/browse/QPID-8211
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Reporter: Kim van der Riet
Assignee: Kim van der Riet


After a discussion on the users list, it has been decided to place deprecation 
notices in the cmake scripts and in the log files at WARNING level when the 
linearstore module is loaded on broker start. The linearstore will be removed 
from the source code tree at some point in the not-too-distant future (perhaps 
six months or so).



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

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

[jira] [Updated] (PROTON-1862) Idle timeout not working on Linux

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1862:

Component/s: (was: proton-c)
 cpp-binding

> Idle timeout not working on Linux
> -
>
> Key: PROTON-1862
> URL: https://issues.apache.org/jira/browse/PROTON-1862
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Critical
>  Labels: reproducer
> Attachments: test_case.cpp
>
>
> We faced an issue with the idle timeout on linux. On windows, it seems to 
> work.
> In our proton feature test suite, we test the idle timeout feature by doing a 
> sleep in the method on_session_open.
> This should trigger a connection timeout. It works on windows, and it used to 
> work with proton v0.16.0 on windows and linux.
> Removing the sleep from the on_session_open and putting it in 
> on_connection_open, yields the same result.
> See attached file to reproduce.
> Machines:
>  * Windows machine
>  ** OS: Windows 7
>  ** Compiler: MSVC 2013 Version 12 Update 5
>  * Linux machine
>  ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago)
>  ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)



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

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

[jira] [Updated] (PROTON-1862) Idle timeout not working on Linux

[Justin Ross (JIRA)]

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

Justin Ross updated PROTON-1862:

Labels: reproducer  (was: )

> Idle timeout not working on Linux
> -
>
> Key: PROTON-1862
> URL: https://issues.apache.org/jira/browse/PROTON-1862
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Critical
>  Labels: reproducer
> Attachments: test_case.cpp
>
>
> We faced an issue with the idle timeout on linux. On windows, it seems to 
> work.
> In our proton feature test suite, we test the idle timeout feature by doing a 
> sleep in the method on_session_open.
> This should trigger a connection timeout. It works on windows, and it used to 
> work with proton v0.16.0 on windows and linux.
> Removing the sleep from the on_session_open and putting it in 
> on_connection_open, yields the same result.
> See attached file to reproduce.
> Machines:
>  * Windows machine
>  ** OS: Windows 7
>  ** Compiler: MSVC 2013 Version 12 Update 5
>  * Linux machine
>  ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago)
>  ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)



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

Re: Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client

[Ganesh Murthy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67661/#review205085
---


Ship it!




Ship It!

- Ganesh Murthy


On June 19, 2018, 10:25 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67661/
> ---
> 
> (Updated June 19, 2018, 10:25 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Ted Ross.
> 
> 
> Bugs: DISPATCH-1020
> https://issues.apache.org/jira/browse/DISPATCH-1020
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> The default expiry policy for a terminus is session-end. Now that link routed 
> links share a session by default, this is likely not what is wanted (terminus 
> state on a broker would have to be kept until the session ended, which is 
> when the connection between broker and router ends). This change propagates 
> an explicit link-detach policy where none is explicitly requested by the 
> client. If the client does request an explicit policy, that is propagated 
> without alteration.
> 
> Note this requires a change to proton PROTON-1866, 
> https://reviews.apache.org/r/67659/
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/system_tests_link_routes.py 57e6d41 
> 
> 
> Diff: https://reviews.apache.org/r/67661/diff/1/
> 
> 
> Testing
> ---
> 
> Automated tests added, all existing tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 66839: translation of remote address in link route

[Ganesh Murthy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/#review205080
---



1. Should displayLinkRoutes() function in qpid-dispatch/tools/qdstat be 
modified to show "addExternalPrefix" and "delExternalPrefix" attributes?  
2. I think we should have an additional test added to 
system_tests_link_routes_add_external_prefix which will run qdmanage query on 
link routes and make sure that "addExternalPrefix" and "delExternalPrefix" are 
showing correctly

- Ganesh Murthy


On June 20, 2018, 2:08 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66839/
> ---
> 
> (Updated June 20, 2018, 2:08 p.m.)
> 
> 
> Review request for qpid and Ted Ross.
> 
> 
> Bugs: DISPATCH-980
> https://issues.apache.org/jira/browse/DISPATCH-980
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> This adds two fields to the link route config, addExternalPrefix and 
> delExternalPrefix, that behave similar to the externalAddr in auto links. 
> I.e. they will cause a prefix to be inserted and/or deleted in the final hop 
> for a link routed link attach. That prefix will also be stripped off or 
> inserted back into the reply, making the renaming completely transparent to 
> clients.
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   python/qpid_dispatch/management/qdrouter.json 42f501f 
>   src/router_config.c 94758df 
>   src/router_core/agent_config_link_route.h 57f6f0d 
>   src/router_core/agent_config_link_route.c 981d142 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/forwarder.c fca19c3 
>   src/router_core/route_control.h 3c715bc 
>   src/router_core/route_control.c 61f426d 
>   src/router_core/router_core.c 9d7f7a5 
>   src/router_core/router_core_private.h cd2ffa4 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/CMakeLists.txt 159521d 
>   tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66839/diff/4/
> 
> 
> Testing
> ---
> 
> Added system tests plus some ad hoc testing.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client

[Gordon Sim]

> On June 20, 2018, 1:12 p.m., Kenneth Giusti wrote:
> > include/qpid/dispatch/router_core.h
> > Lines 350 (patched)
> > 
> >
> > nit:
> > 
> > I hate to be "that guy" but I find the the name of the function 
> > ambiguous. I'd expect a "check" to either succeed or fail.  Perhaps 
> > something along the lines of
> > 
> > qdr_terminus_set_default_expiry(*term)
> > 
> > or
> > 
> > qdr_terminus_set_default_expiry(*term, default)
> > 
> > would be more flexible?

I agree it is not a great name... how about 
qdr_terminus_set_link_expire_if_unset? Is that too long?


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67661/#review205063
---


On June 19, 2018, 10:25 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67661/
> ---
> 
> (Updated June 19, 2018, 10:25 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Ted Ross.
> 
> 
> Bugs: DISPATCH-1020
> https://issues.apache.org/jira/browse/DISPATCH-1020
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> The default expiry policy for a terminus is session-end. Now that link routed 
> links share a session by default, this is likely not what is wanted (terminus 
> state on a broker would have to be kept until the session ended, which is 
> when the connection between broker and router ends). This change propagates 
> an explicit link-detach policy where none is explicitly requested by the 
> client. If the client does request an explicit policy, that is propagated 
> without alteration.
> 
> Note this requires a change to proton PROTON-1866, 
> https://reviews.apache.org/r/67659/
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/system_tests_link_routes.py 57e6d41 
> 
> 
> Diff: https://reviews.apache.org/r/67661/diff/1/
> 
> 
> Testing
> ---
> 
> Automated tests added, all existing tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 66839: translation of remote address in link route

[Gordon Sim]

> On June 20, 2018, 1:37 p.m., Ganesh Murthy wrote:
> > tests/system_tests_link_routes_add_external_prefix.py
> > Lines 193 (patched)
> > 
> >
> > error = "Incorrect message. Got %s, expected %s" % (event.message.body, 
> > self.message.body)
> > 
> > must be changed to 
> > 
> > self.error = "Incorrect message. Got %s, expected %s" % 
> > (event.message.body, self.message.body)

Well spotted, thanks Ganesh! I have fixed that now (tests still pass ;-)


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/#review205070
---


On June 20, 2018, 2:08 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66839/
> ---
> 
> (Updated June 20, 2018, 2:08 p.m.)
> 
> 
> Review request for qpid and Ted Ross.
> 
> 
> Bugs: DISPATCH-980
> https://issues.apache.org/jira/browse/DISPATCH-980
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> This adds two fields to the link route config, addExternalPrefix and 
> delExternalPrefix, that behave similar to the externalAddr in auto links. 
> I.e. they will cause a prefix to be inserted and/or deleted in the final hop 
> for a link routed link attach. That prefix will also be stripped off or 
> inserted back into the reply, making the renaming completely transparent to 
> clients.
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   python/qpid_dispatch/management/qdrouter.json 42f501f 
>   src/router_config.c 94758df 
>   src/router_core/agent_config_link_route.h 57f6f0d 
>   src/router_core/agent_config_link_route.c 981d142 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/forwarder.c fca19c3 
>   src/router_core/route_control.h 3c715bc 
>   src/router_core/route_control.c 61f426d 
>   src/router_core/router_core.c 9d7f7a5 
>   src/router_core/router_core_private.h cd2ffa4 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/CMakeLists.txt 159521d 
>   tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66839/diff/4/
> 
> 
> Testing
> ---
> 
> Added system tests plus some ad hoc testing.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 66839: translation of remote address in link route

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/
---

(Updated June 20, 2018, 2:08 p.m.)


Review request for qpid and Ted Ross.


Changes
---

Fixed test per review


Bugs: DISPATCH-980
https://issues.apache.org/jira/browse/DISPATCH-980


Repository: qpid-dispatch


Description
---

This adds two fields to the link route config, addExternalPrefix and 
delExternalPrefix, that behave similar to the externalAddr in auto links. I.e. 
they will cause a prefix to be inserted and/or deleted in the final hop for a 
link routed link attach. That prefix will also be stripped off or inserted back 
into the reply, making the renaming completely transparent to clients.


Diffs (updated)
-

  include/qpid/dispatch/router_core.h 8f144b0 
  python/qpid_dispatch/management/qdrouter.json 42f501f 
  src/router_config.c 94758df 
  src/router_core/agent_config_link_route.h 57f6f0d 
  src/router_core/agent_config_link_route.c 981d142 
  src/router_core/connections.c 5fdc3bf 
  src/router_core/forwarder.c fca19c3 
  src/router_core/route_control.h 3c715bc 
  src/router_core/route_control.c 61f426d 
  src/router_core/router_core.c 9d7f7a5 
  src/router_core/router_core_private.h cd2ffa4 
  src/router_core/terminus.c 4c0e0a3 
  tests/CMakeLists.txt 159521d 
  tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 


Diff: https://reviews.apache.org/r/66839/diff/4/

Changes: https://reviews.apache.org/r/66839/diff/3-4/


Testing
---

Added system tests plus some ad hoc testing.


Thanks,

Gordon Sim

Re: Review Request 66839: translation of remote address in link route

[Ganesh Murthy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66839/#review205070
---




tests/system_tests_link_routes_add_external_prefix.py
Lines 193 (patched)


error = "Incorrect message. Got %s, expected %s" % (event.message.body, 
self.message.body)

must be changed to 

self.error = "Incorrect message. Got %s, expected %s" % 
(event.message.body, self.message.body)


- Ganesh Murthy


On June 18, 2018, 9:37 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66839/
> ---
> 
> (Updated June 18, 2018, 9:37 p.m.)
> 
> 
> Review request for qpid and Ted Ross.
> 
> 
> Bugs: DISPATCH-980
> https://issues.apache.org/jira/browse/DISPATCH-980
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> This adds two fields to the link route config, addExternalPrefix and 
> delExternalPrefix, that behave similar to the externalAddr in auto links. 
> I.e. they will cause a prefix to be inserted and/or deleted in the final hop 
> for a link routed link attach. That prefix will also be stripped off or 
> inserted back into the reply, making the renaming completely transparent to 
> clients.
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   python/qpid_dispatch/management/qdrouter.json 42f501f 
>   src/router_config.c 94758df 
>   src/router_core/agent_config_link_route.h 57f6f0d 
>   src/router_core/agent_config_link_route.c 981d142 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/forwarder.c fca19c3 
>   src/router_core/route_control.h 3c715bc 
>   src/router_core/route_control.c 61f426d 
>   src/router_core/router_core.c 9d7f7a5 
>   src/router_core/router_core_private.h cd2ffa4 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/CMakeLists.txt 159521d 
>   tests/system_tests_link_routes_add_external_prefix.py PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66839/diff/3/
> 
> 
> Testing
> ---
> 
> Added system tests plus some ad hoc testing.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67659: provide new function to test whether an explicit expiry policy was set on a terminus

[Kenneth Giusti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67659/#review205065
---


Ship it!




Ship It!

- Kenneth Giusti


On June 20, 2018, 1:09 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67659/
> ---
> 
> (Updated June 20, 2018, 1:09 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1866
> https://issues.apache.org/jira/browse/PROTON-1866
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> This allows users of proton to determine whether an explicit expiry was 
> requested or not.
> 
> 
> Diffs
> -
> 
>   c/include/proton/terminus.h b2344c0 
>   c/src/core/engine-internal.h b1c6123 
>   c/src/core/engine.c 070c751 
>   c/src/core/transport.c bfa66c1 
> 
> 
> Diff: https://reviews.apache.org/r/67659/diff/2/
> 
> 
> Testing
> ---
> 
> All tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client

[Kenneth Giusti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67661/#review205063
---



For future reference: if you submit dispatch patches via a Pull Request against 
the apache mirror https://github.com/apache/qpid-dispatch instead of 
reviewboard, travis will run a unit test coverage report which will show how 
well the patch is covered.

thanks


include/qpid/dispatch/router_core.h
Lines 350 (patched)


nit:

I hate to be "that guy" but I find the the name of the function ambiguous. 
I'd expect a "check" to either succeed or fail.  Perhaps something along the 
lines of

qdr_terminus_set_default_expiry(*term)

or

qdr_terminus_set_default_expiry(*term, default)

would be more flexible?


- Kenneth Giusti


On June 19, 2018, 10:25 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67661/
> ---
> 
> (Updated June 19, 2018, 10:25 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Ted Ross.
> 
> 
> Bugs: DISPATCH-1020
> https://issues.apache.org/jira/browse/DISPATCH-1020
> 
> 
> Repository: qpid-dispatch
> 
> 
> Description
> ---
> 
> The default expiry policy for a terminus is session-end. Now that link routed 
> links share a session by default, this is likely not what is wanted (terminus 
> state on a broker would have to be kept until the session ended, which is 
> when the connection between broker and router ends). This change propagates 
> an explicit link-detach policy where none is explicitly requested by the 
> client. If the client does request an explicit policy, that is propagated 
> without alteration.
> 
> Note this requires a change to proton PROTON-1866, 
> https://reviews.apache.org/r/67659/
> 
> 
> Diffs
> -
> 
>   include/qpid/dispatch/router_core.h 8f144b0 
>   src/router_core/connections.c 5fdc3bf 
>   src/router_core/terminus.c 4c0e0a3 
>   tests/system_tests_link_routes.py 57e6d41 
> 
> 
> Diff: https://reviews.apache.org/r/67661/diff/1/
> 
> 
> Testing
> ---
> 
> Automated tests added, all existing tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67659: provide new function to test whether an explicit expiry policy was set on a terminus

[Gordon Sim]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67659/
---

(Updated June 20, 2018, 1:09 p.m.)


Review request for qpid, Alan Conway and Andrew Stitcher.


Changes
---

Updated to to have const pn_terminus_t* passed in to new method as requested.


Bugs: PROTON-1866
https://issues.apache.org/jira/browse/PROTON-1866


Repository: qpid-proton-git


Description
---

This allows users of proton to determine whether an explicit expiry was 
requested or not.


Diffs (updated)
-

  c/include/proton/terminus.h b2344c0 
  c/src/core/engine-internal.h b1c6123 
  c/src/core/engine.c 070c751 
  c/src/core/transport.c bfa66c1 


Diff: https://reviews.apache.org/r/67659/diff/2/

Changes: https://reviews.apache.org/r/67659/diff/1-2/


Testing
---

All tests pass.


Thanks,

Gordon Sim

Re: Review Request 67659: provide new function to test whether an explicit expiry policy was set on a terminus

[Gordon Sim]

> On June 20, 2018, 12:56 p.m., Kenneth Giusti wrote:
> > c/include/proton/terminus.h
> > Lines 200 (patched)
> > 
> >
> > nit: 
> > 
> > since this does not change the value of *terminus can the parameter be 
> > defined as 'const pn_terminus_t *' instead?

Sure, I'll do that. (However none of the get_xxx methods take a const at 
present, even if they also do not alter the terminus passed in).


- Gordon


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67659/#review205062
---


On June 19, 2018, 10:14 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67659/
> ---
> 
> (Updated June 19, 2018, 10:14 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1866
> https://issues.apache.org/jira/browse/PROTON-1866
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> This allows users of proton to determine whether an explicit expiry was 
> requested or not.
> 
> 
> Diffs
> -
> 
>   c/include/proton/terminus.h b2344c0 
>   c/src/core/engine-internal.h b1c6123 
>   c/src/core/engine.c 070c751 
>   c/src/core/transport.c bfa66c1 
> 
> 
> Diff: https://reviews.apache.org/r/67659/diff/1/
> 
> 
> Testing
> ---
> 
> All tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Re: Review Request 67659: provide new function to test whether an explicit expiry policy was set on a terminus

[Kenneth Giusti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/67659/#review205062
---




c/include/proton/terminus.h
Lines 200 (patched)


nit: 

since this does not change the value of *terminus can the parameter be 
defined as 'const pn_terminus_t *' instead?


- Kenneth Giusti


On June 19, 2018, 10:14 p.m., Gordon Sim wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67659/
> ---
> 
> (Updated June 19, 2018, 10:14 p.m.)
> 
> 
> Review request for qpid, Alan Conway and Andrew Stitcher.
> 
> 
> Bugs: PROTON-1866
> https://issues.apache.org/jira/browse/PROTON-1866
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> This allows users of proton to determine whether an explicit expiry was 
> requested or not.
> 
> 
> Diffs
> -
> 
>   c/include/proton/terminus.h b2344c0 
>   c/src/core/engine-internal.h b1c6123 
>   c/src/core/engine.c 070c751 
>   c/src/core/transport.c bfa66c1 
> 
> 
> Diff: https://reviews.apache.org/r/67659/diff/1/
> 
> 
> Testing
> ---
> 
> All tests pass.
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

[jira] [Commented] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8210:
--

Changes look good.

> [Broker-J]  Consumer attach when message is being released and requeued can 
> end-up in broker crash due to unhandled NullPointerException
> 
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, 
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue 
> consumer manager. When released message is requeued all consumers in consumer 
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for 
> every of them to update the released entry in consumer queue context if 
> required. The notification of consumer without a consumer node can result in 
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
>     at 
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
>     at 
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
>     at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
>     at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
>     at 
> org.apache.qpid.server.transport.SelectorThread$Connec

[jira] [Commented] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException

[Keith Wall (JIRA)]

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

Keith Wall commented on QPID-8210:
--

In addition the following cherry picks into 7.0.x are missing from the JIRAs 
history:

 

commit c5bf4260a0da733a048b9949ca0ccaf6f9bae158
Author: Alex Rudyy 
Date: Tue Jun 19 17:38:29 2018 +0100

QPID-8210: [Broker-J] Make field QueueConsumerImpl#_queueConsumerNode volatile

(cherry picked from commit a07e8fd80ea11f0458c0fcfe4bc7a0ec31b4a7bb)

commit ca118c933e4ad74375d056f694fbbb367cfa33a6
Author: Alex Rudyy 
Date: Mon Jun 18 17:51:47 2018 +0100

QPID-8210: [Broker-J] Set queue consumer node before adding consumer into queue 
consumer manager

(cherry picked from commit 0c4e41829d3f97eaa171fd1276e85e1685021cfc)

 

 

 

> [Broker-J]  Consumer attach when message is being released and requeued can 
> end-up in broker crash due to unhandled NullPointerException
> 
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, 
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue 
> consumer manager. When released message is requeued all consumers in consumer 
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for 
> every of them to update the released entry in consumer queue context if 
> required. The notification of consumer without a consumer node can result in 
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
>     at 
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
>     at 
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
>     at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
>     at 
> org.apache.qpid.server.transport.

[jira] [Resolved] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException

[Keith Wall (JIRA)]

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

Keith Wall resolved QPID-8210.
--
Resolution: Fixed

> [Broker-J]  Consumer attach when message is being released and requeued can 
> end-up in broker crash due to unhandled NullPointerException
> 
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
>  Issue Type: Bug
>  Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, 
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, 
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue 
> consumer manager. When released message is requeued all consumers in consumer 
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for 
> every of them to update the released entry in consumer queue context if 
> required. The notification of consumer without a consumer node can result in 
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
>     at 
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
>     at 
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
>     at 
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
>     at 
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
>     at 
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at 
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
>     at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
>     at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
>     at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
>     at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:5

[jira] [Updated] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException

[Keith Wall (JIRA)]

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

Keith Wall updated QPID-8210:
-
Description: 
The consumer node is currently set after consumer is added into queue consumer 
manager. When released message is requeued all consumers in consumer manager 
are iterated and AbstractQueue#updateSubRequeueEntry is invoke for every of 
them to update the released entry in consumer queue context if required. The 
notification of consumer without a consumer node can result in 
NullPointerException:
{noformat}
java.lang.NullPointerException
    at 
org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
    at 
org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
    at 
org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
    at 
org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
    at 
org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
    at 
org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
    at 
org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
    at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
    at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
    at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
    at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
    at 
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
    at 
org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
    at 
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
    at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
    at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
    at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
    at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
    at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
    at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
    at java.security.AccessController.doPrivileged(Native Method)
    at 
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
    at 
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
    at 
org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
    at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
    at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
    at java.security.AccessController.doPrivileged(Native Method)
    at 
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
    at 
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
    at 
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
    at 
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
    at 
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
    at 
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
    at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
    at 
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
    at 
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at 
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
    at java.lang.Thread.run(Thread.java:748)
{noformat}
The issue can happen in the following scenarios:
 * when previously acquired message is released due to 
consumer/session/connection close and another consumer is attached to the queue 
at the same time.
 * when transaction is rolled back or message is released (for example, JMS 
se