date:20171128

[jira] [Commented] (PROTON-1702) Fix epoll proactor listener for rearming and overflow per socket

2017-11-28 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270340#comment-16270340
 ] 

ASF subversion and git services commented on PROTON-1702:
-

Commit a7119f56cf29f1bb2be261951be1120c2243f29c in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a7119f5 ]

PROTON-1702: epoll proactor: per socket rearming and overflow for listeners


> Fix epoll proactor listener for rearming and overflow per socket
> 
>
> Key: PROTON-1702
> URL: https://issues.apache.org/jira/browse/PROTON-1702
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: proton-c
>Affects Versions: proton-c-0.18.1
> Environment: Linux epoll
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: proton-j-0.19.0
>
>
> This addresses the comment
>   // TODO: armed logic should be per socket not per aggregate listener
> which is a required step to add logic to safely shutdown a listener 
> (PROTON-1531).  The overflow logic needs similar per socket updating.
> Additional issues to address while addressing this code change:
>   pclosefd - fix deadlock on recursive lock for listener sockets
>   socket array size to 1 on failure to match realloc
>   check for need to wakeup listener if pn_listener_accept() not called from 
> or close to ACCEPT event callback (i.e. not "working").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (PROTON-1702) Fix epoll proactor listener for rearming and overflow per socket

2017-11-28 Thread Cliff Jansen (JIRA)

Cliff Jansen created PROTON-1702:


 Summary: Fix epoll proactor listener for rearming and overflow per 
socket
 Key: PROTON-1702
 URL: https://issues.apache.org/jira/browse/PROTON-1702
 Project: Qpid Proton
  Issue Type: Improvement
  Components: proton-c
Affects Versions: proton-c-0.18.1
 Environment: Linux epoll
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: proton-j-0.19.0


This addresses the comment

  // TODO: armed logic should be per socket not per aggregate listener

which is a required step to add logic to safely shutdown a listener 
(PROTON-1531).  The overflow logic needs similar per socket updating.

Additional issues to address while addressing this code change:

  pclosefd - fix deadlock on recursive lock for listener sockets

  socket array size to 1 on failure to match realloc

  check for need to wakeup listener if pn_listener_accept() not called from or 
close to ACCEPT event callback (i.e. not "working").





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2017-11-28 Thread ASF subversion and git services (JIRA)


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

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

Commit 49cd2c1d698b5da11967505f20df1d5a21bf6c33 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=49cd2c1 ]

QPID-6933: [System Tests] Move JMS common test functionality into a separate 
module


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-8038) [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x

2017-11-28 Thread ASF subversion and git services (JIRA)


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

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

Commit 0a7368ecb2acbee7e214cb8b6f3acd5f8d0eb31f in qpid-broker-j's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0a7368e ]

QPID-8038: [Broker-J][AMQP 1.0] Add 0-8/9/91 queue protocol tests


> [Broker-J][System Tests] Add protocol system test suites for AMQP 0-x
> -
>
> Key: QPID-8038
> URL: https://issues.apache.org/jira/browse/QPID-8038
> Project: Qpid
>  Issue Type: Improvement
>  Components: Broker-J, Java Tests
>Reporter: Alex Rudyy
>
> We need a test frameworks which would allow creation of tests which would be 
> sending the AMQP 0-x performatives over TCP and receiving and asserting 
> broker responses.
> The framework should satisfy the following requirements:
> * It should allow running tests against other AMQP brokers
> * The framework should encapsulate starting/stopping of broker and queue 
> creation/deletion under special interface(s) which can be implemented by the 
> Broker developers in order to run tests against different Broker 
> implementations
> * Tests should be able to start and stop broker if required or configured
> * Tests should be able to generate AMQP performatives and assert received 
> peer's AMQP performatives
> * The framework should allow using other transport than TCP if required
> * The framework should be based on AMQP 0-x  implementations of Broker-J



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-872) Add a counter for dropped-presettleds on links

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-872:
-

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-872 - Added a counter for dropped-presettleds on links. qdst…

…at now shows this counter

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

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

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

https://github.com/apache/qpid-dispatch/pull/226.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 #226


commit d9eed9ffc940e614be47a034aaca38634e65a4a3
Author: Ganesh Murthy 
Date:   2017-11-10T16:29:07Z

DISPATCH-872 - Added a counter for dropped-presettleds on links. qdstat now 
shows this counter




> Add a counter for dropped-presettleds on links
> --
>
> Key: DISPATCH-872
> URL: https://issues.apache.org/jira/browse/DISPATCH-872
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.1.0
>
>
> When the router drops pre-settled deliveries during congestion, those drops 
> are not counted or reported.  A new counter should be added for links to 
> account for dropped presettled deliveries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #226: DISPATCH-872 - Added a counter for dropped-...

2017-11-28 Thread ganeshmurthy

GitHub user ganeshmurthy opened a pull request:

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

DISPATCH-872 - Added a counter for dropped-presettleds on links. qdstâ¦

â¦at now shows this counter

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

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

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

https://github.com/apache/qpid-dispatch/pull/226.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 #226


commit d9eed9ffc940e614be47a034aaca38634e65a4a3
Author: Ganesh Murthy 
Date:   2017-11-10T16:29:07Z

DISPATCH-872 - Added a counter for dropped-presettleds on links. qdstat now 
shows this counter




---

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

[jira] [Commented] (PROTON-1700) [cpp] Reconnecting container does not respond to stop

2017-11-28 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269231#comment-16269231
 ] 

ASF subversion and git services commented on PROTON-1700:
-

Commit 27c5bf0b718bc500d363bceb8739f3f0ec526c3e in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=27c5bf0 ]

PROTON-1700: Revert erroneous checkin


> [cpp] Reconnecting container does not respond to stop
> -
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1649) [cpp] Reconnecting container cannot be stopped from a scheduled task

2017-11-28 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher resolved PROTON-1649.
-
Resolution: Duplicate

> [cpp] Reconnecting container cannot be stopped from a scheduled task
> 
>
> Key: PROTON-1649
> URL: https://issues.apache.org/jira/browse/PROTON-1649
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-j-0.18.0
> Environment: commit bdfe982f5f2dd8b9735288623fbc8eabe4a5371f 
> (upstream/master)
> Author: Jiri Danek 
> Date:   Tue Oct 10 21:57:30 2017 +0200
> PROTON-1622 Add coverage reporting to CMake build
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>
> The following test will get stuck
> {code}
> struct timed_reconnect_tester : public proton::messaging_handler {
> struct timer_handler : public proton::void_function0 {
> proton::container *c = nullptr;
> void operator()() PN_CPP_OVERRIDE {
> c->stop();
> }
> };
> test_port port;
> timer_handler handler;
> void on_container_start(proton::container ) PN_CPP_OVERRIDE {
> c.listen(port.url());
> handler.c = 
> proton::reconnect_options reconnect_options;
> c.connect(port.url("127.0.0.1"), 
> proton::connection_options().reconnect(reconnect_options));
> c.schedule(proton::duration::IMMEDIATE, handler);
> }
> };
> int test_timed_reconnect() {
> timed_reconnect_tester t;
> proton::container(t).run();
> return 0;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher resolved PROTON-1700.
-
Resolution: Fixed

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1649) [cpp] Reconnecting container cannot be stopped from a scheduled task

2017-11-28 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher updated PROTON-1649:

Fix Version/s: proton-c-0.19.0

> [cpp] Reconnecting container cannot be stopped from a scheduled task
> 
>
> Key: PROTON-1649
> URL: https://issues.apache.org/jira/browse/PROTON-1649
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-j-0.18.0
> Environment: commit bdfe982f5f2dd8b9735288623fbc8eabe4a5371f 
> (upstream/master)
> Author: Jiri Danek 
> Date:   Tue Oct 10 21:57:30 2017 +0200
> PROTON-1622 Add coverage reporting to CMake build
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.19.0
>
>
> The following test will get stuck
> {code}
> struct timed_reconnect_tester : public proton::messaging_handler {
> struct timer_handler : public proton::void_function0 {
> proton::container *c = nullptr;
> void operator()() PN_CPP_OVERRIDE {
> c->stop();
> }
> };
> test_port port;
> timer_handler handler;
> void on_container_start(proton::container ) PN_CPP_OVERRIDE {
> c.listen(port.url());
> handler.c = 
> proton::reconnect_options reconnect_options;
> c.connect(port.url("127.0.0.1"), 
> proton::connection_options().reconnect(reconnect_options));
> c.schedule(proton::duration::IMMEDIATE, handler);
> }
> };
> int test_timed_reconnect() {
> timed_reconnect_tester t;
> proton::container(t).run();
> return 0;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (PROTON-1700) [cpp] Reconnecting container does not respond to stop

2017-11-28 Thread Justin Ross (JIRA)


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

Justin Ross updated PROTON-1700:

Summary: [cpp] Reconnecting container does not respond to stop  (was: 
Reconnecting container does not respond to stop)

> [cpp] Reconnecting container does not respond to stop
> -
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread Andrew Stitcher (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269208#comment-16269208
 ] 

Andrew Stitcher commented on PROTON-1700:
-

Incidentally - this bug only exhibits when the stop happens *after* the 
connection error has been reported. This is why you may see the test program 
exit under some conditions.

The conditions for the bug are that the run loop needs to have something going 
on at the point of the stop command to cause it to carry on rescheduling the 
connect attempts. If the stop happens before the first reported failure then 
the run loop has nothing to keep it going and will just stop.

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269200#comment-16269200
 ] 

ASF subversion and git services commented on PROTON-1700:
-

Commit de1e81cc5090b0f10b8ff3e17059ef0d2275f098 in qpid-proton's branch 
refs/heads/master from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=de1e81c ]

PROTON-1700: [C++ binding] Interrupt reconnect attempts when container stopped


> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-872) Add a counter for dropped-presettleds on links

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-872:
-

Github user ganeshmurthy closed the pull request at:

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


> Add a counter for dropped-presettleds on links
> --
>
> Key: DISPATCH-872
> URL: https://issues.apache.org/jira/browse/DISPATCH-872
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Router Node
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 1.1.0
>
>
> When the router drops pre-settled deliveries during congestion, those drops 
> are not counted or reported.  A new counter should be added for links to 
> account for dropped presettled deliveries.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #216: DISPATCH-872 - Added a counter for dropped-...

2017-11-28 Thread ganeshmurthy

Github user ganeshmurthy closed the pull request at:

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


---

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

[jira] [Resolved] (DISPATCH-875) Document address and link route wildcards

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-875.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Document address and link route wildcards
> -
>
> Key: DISPATCH-875
> URL: https://issues.apache.org/jira/browse/DISPATCH-875
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 1.1.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
> Fix For: 1.1.0
>
>
> Update Dispatch Router doc to describe how to define groups of addresses 
> using the new "pattern" address attribute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-875) Document address and link route wildcards

2017-11-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-875:
--

Commit e494da0a957d3cbbb5daaa802dd13e73e0ca4774 in qpid-dispatch's branch 
refs/heads/master from [~bhardest]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e494da0 ]

DISPATCH-875 - Document the pattern attribute. This closes #218


> Document address and link route wildcards
> -
>
> Key: DISPATCH-875
> URL: https://issues.apache.org/jira/browse/DISPATCH-875
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 1.1.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Update Dispatch Router doc to describe how to define groups of addresses 
> using the new "pattern" address attribute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-875) Document address and link route wildcards

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-875:
-

Github user asfgit closed the pull request at:

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


> Document address and link route wildcards
> -
>
> Key: DISPATCH-875
> URL: https://issues.apache.org/jira/browse/DISPATCH-875
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 1.1.0
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>
> Update Dispatch Router doc to describe how to define groups of addresses 
> using the new "pattern" address attribute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #218: DISPATCH-875 - Doc new "pattern" attribute

2017-11-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Resolved] (DISPATCH-877) Document how to configure TLS ciphers

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-877.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Document how to configure TLS ciphers
> -
>
> Key: DISPATCH-877
> URL: https://issues.apache.org/jira/browse/DISPATCH-877
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-877) Document how to configure TLS ciphers

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-877:
-

Github user asfgit closed the pull request at:

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


> Document how to configure TLS ciphers
> -
>
> Key: DISPATCH-877
> URL: https://issues.apache.org/jira/browse/DISPATCH-877
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-877) Document how to configure TLS ciphers

2017-11-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-877:
--

Commit 95c9463e247a26d1b7374992d7826214c2805b5f in qpid-dispatch's branch 
refs/heads/master from [~bhardest]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=95c9463 ]

DISPATCH-877 - Document new ciphers attribute. This closes #219


> Document how to configure TLS ciphers
> -
>
> Key: DISPATCH-877
> URL: https://issues.apache.org/jira/browse/DISPATCH-877
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #219: DISPATCH-877 - Doc new "ciphers" attribute

2017-11-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Comment Edited] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

2017-11-28 Thread Jeremy (JIRA)


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

Jeremy edited comment on DISPATCH-878 at 11/28/17 4:17 PM:
---

Indeed, at Murex, we use the qpid _java_ broker and it has this feature.

We were testing with the qpid dispatch router to see if it supports being 
launched on port 0, and we saw that it was supported. However, we have no 
(reliable) way to tell what port it is actually using. This makes the feature 
half supported :)

This feature is interesting for us, because we want to launch several dispatch 
routers, and we would benefit from the following:
- Having a single configuration for the port is simpler for us
- Avoid having an error that the port is already taken, which would simplify 
the life of the cluster operator



was (Author: jeremy.aouad):
Indeed, at Murex, we use the qpid _java _broker and it has this feature.

We were testing with the qpid dispatch router to see if it supports being 
launched on port 0, and we saw that it was supported. However, we have no 
(reliable) way to tell what port it is actually using. This makes the feature 
half supported :)

This feature is interesting for us, because we want to launch several dispatch 
routers, and we would benefit from the following:
- Having a single configuration for the port is simpler for us
- Avoid having an error that the port is already taken, which would simplify 
the life of the cluster operator


> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

2017-11-28 Thread Jeremy (JIRA)


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

Jeremy commented on DISPATCH-878:
-

Indeed, at Murex, we use the qpid _java _broker and it has this feature.

We were testing with the qpid dispatch router to see if it supports being 
launched on port 0, and we saw that it was supported. However, we have no 
(reliable) way to tell what port it is actually using. This makes the feature 
half supported :)

This feature is interesting for us, because we want to launch several dispatch 
routers, and we would benefit from the following:
- Having a single configuration for the port is simpler for us
- Avoid having an error that the port is already taken, which would simplify 
the life of the cluster operator


> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-879) Document how Dispatch Router uses alternate failover URLs

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-879.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Document how Dispatch Router uses alternate failover URLs
> -
>
> Key: DISPATCH-879
> URL: https://issues.apache.org/jira/browse/DISPATCH-879
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-879) Document how Dispatch Router uses alternate failover URLs

2017-11-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-879:
--

Commit 00d1ea2207711b409eb9ef1f0f582adb502b6456 in qpid-dispatch's branch 
refs/heads/master from [~bhardest]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=00d1ea2 ]

DISPATCH-879 - Document how routers use alternate failover URLs. This closes 
#220


> Document how Dispatch Router uses alternate failover URLs
> -
>
> Key: DISPATCH-879
> URL: https://issues.apache.org/jira/browse/DISPATCH-879
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-879) Document how Dispatch Router uses alternate failover URLs

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-879:
-

Github user asfgit closed the pull request at:

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


> Document how Dispatch Router uses alternate failover URLs
> -
>
> Key: DISPATCH-879
> URL: https://issues.apache.org/jira/browse/DISPATCH-879
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #220: DISPATCH-879 - Document how routers use alt...

2017-11-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Assigned] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher reassigned PROTON-1700:
---

Assignee: Andrew Stitcher  (was: Jiri Daněk)

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1649) [cpp] Reconnecting container cannot be stopped from a scheduled task

2017-11-28 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher reassigned PROTON-1649:
---

Assignee: Andrew Stitcher  (was: Cliff Jansen)

> [cpp] Reconnecting container cannot be stopped from a scheduled task
> 
>
> Key: PROTON-1649
> URL: https://issues.apache.org/jira/browse/PROTON-1649
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-j-0.18.0
> Environment: commit bdfe982f5f2dd8b9735288623fbc8eabe4a5371f 
> (upstream/master)
> Author: Jiri Danek 
> Date:   Tue Oct 10 21:57:30 2017 +0200
> PROTON-1622 Add coverage reporting to CMake build
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>
> The following test will get stuck
> {code}
> struct timed_reconnect_tester : public proton::messaging_handler {
> struct timer_handler : public proton::void_function0 {
> proton::container *c = nullptr;
> void operator()() PN_CPP_OVERRIDE {
> c->stop();
> }
> };
> test_port port;
> timer_handler handler;
> void on_container_start(proton::container ) PN_CPP_OVERRIDE {
> c.listen(port.url());
> handler.c = 
> proton::reconnect_options reconnect_options;
> c.connect(port.url("127.0.0.1"), 
> proton::connection_options().reconnect(reconnect_options));
> c.schedule(proton::duration::IMMEDIATE, handler);
> }
> };
> int test_timed_reconnect() {
> timed_reconnect_tester t;
> proton::container(t).run();
> return 0;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-880) Document how Dispatch Router disconnects connections

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-880.

   Resolution: Fixed
Fix Version/s: 1.1.0

> Document how Dispatch Router disconnects connections
> 
>
> Key: DISPATCH-880
> URL: https://issues.apache.org/jira/browse/DISPATCH-880
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-880) Document how Dispatch Router disconnects connections

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-880:
-

Github user asfgit closed the pull request at:

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


> Document how Dispatch Router disconnects connections
> 
>
> Key: DISPATCH-880
> URL: https://issues.apache.org/jira/browse/DISPATCH-880
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Ben Hardesty
>Assignee: Ben Hardesty
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #221: DISPATCH-880 - Document initialHandshakeTim...

2017-11-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Commented] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread JIRA


[ 
https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268932#comment-16268932
 ] 

Jiri Daněk commented on PROTON-1700:


Duplicate of, PROTON-1649, I'd say.

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread JIRA


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

Jiri Daněk reassigned PROTON-1700:
--

Assignee: Jiri Daněk  (was: Andrew Stitcher)

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Jiri Daněk
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy edited comment on DISPATCH-878 at 11/28/17 3:31 PM:
--

Jeremy, can you please explain why you need this change. We have had tried to 
do this in other projects and found that it adds a lot of complication and 
future bugs. It would be best not to put this feature in. 


was (Author: ganeshmurthy):
Jeremy, can you please explain why you need this change. We have had tried to 
do this in other projects and it found that it adds a lot of complication and 
future bugs. It would be best not to put this feature in. 

> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-878) qdrouterd should log real port if port 0 was specified for the listener port property in qdrouterd.conf

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy commented on DISPATCH-878:


Jeremy, can you please explain why you need this change. We have had tried to 
do this in other projects and it found that it adds a lot of complication and 
future bugs. It would be best not to put this feature in. 

> qdrouterd should log real port if port 0 was specified for the listener port 
> property in qdrouterd.conf
> ---
>
> Key: DISPATCH-878
> URL: https://issues.apache.org/jira/browse/DISPATCH-878
> Project: Qpid Dispatch
>  Issue Type: Improvement
>  Components: Container
> Environment: OS: Red Hat Linux Server release 6.4
> Dispatch version: 0.7.0
>Reporter: Jeremy
>
> For such a qdrouterd.conf configuration:
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> *port: 5673*
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> {noformat}
> qdrouterd logs the port as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:5673 proto=any, role=normal
> {noformat}
> When specifying port 0, so that the dispatch router runs on a random 
> available port, the log is as such:
> {noformat}
> CONN_MGR (info) Configured Listener: 0.0.0.0:0 proto=any, role=normal
> {noformat}
> qdrouterd process can log instead the real port that was randomly chosen.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PROTON-1700) Reconnecting container does not respond to stop

2017-11-28 Thread Andrew Stitcher (JIRA)


[ 
https://issues.apache.org/jira/browse/PROTON-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268911#comment-16268911
 ] 

Andrew Stitcher commented on PROTON-1700:
-

I can confirm this is reproducable and seems to be a reasonably simple 
oversight (not checking whether the container is stopping when setting up for a 
reconnect).

> Reconnecting container does not respond to stop
> ---
>
> Key: PROTON-1700
> URL: https://issues.apache.org/jira/browse/PROTON-1700
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Justin Ross
>Assignee: Andrew Stitcher
>  Labels: reproducer
> Fix For: proton-c-0.19.0
>
> Attachments: reconnect-and-stop.cpp
>
>
> Calling stop from another thread fails to terminate a container when it is 
> attempting to reconnect.
> The attached reproducer never exits (or mostly never exits - I may have seen 
> it do it once).  I believe it should.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-882) router buffers messages for slow presettled receiver

2017-11-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-882:
--

Commit 6166f21accec8c305e9e3b378e76bdbdaefd57e9 in qpid-dispatch's branch 
refs/heads/master from Kenneth Giusti
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6166f21 ]

DISPATCH-882: delay settlement until after the i/o thread puts the delivery on 
the proper list

Closes #225


> router buffers messages for slow presettled receiver
> 
>
> Key: DISPATCH-882
> URL: https://issues.apache.org/jira/browse/DISPATCH-882
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ken Giusti
> Fix For: 1.1.0
>
>
> For an anycast address with incoming transfers unsettled and outgoing 
> transfers pre-settled, if the receiver can't keep up with the sender, the 
> router appears to buffer a growing number of deliveries.
> The link stats for the receiver, which is receiving pre-settled, are shown as 
> accepted and unsettled (with a small number of undelivered) with presettled 
> count remaining at zero and the unsettled count growing. qpid-stat -m shows 
> growth in buffer and message content related types.
> It looks like there is no limit to the amount of messages the router will try 
> to buffer in this case(?) though I did not push it all the way to failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] qpid-dispatch pull request #225: DISPATCH-882: delay settlement until after ...

2017-11-28 Thread asfgit

Github user asfgit closed the pull request at:

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


---

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

[jira] [Commented] (DISPATCH-882) router buffers messages for slow presettled receiver

2017-11-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on DISPATCH-882:
-

Github user asfgit closed the pull request at:

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


> router buffers messages for slow presettled receiver
> 
>
> Key: DISPATCH-882
> URL: https://issues.apache.org/jira/browse/DISPATCH-882
> Project: Qpid Dispatch
>  Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ken Giusti
> Fix For: 1.1.0
>
>
> For an anycast address with incoming transfers unsettled and outgoing 
> transfers pre-settled, if the receiver can't keep up with the sender, the 
> router appears to buffer a growing number of deliveries.
> The link stats for the receiver, which is receiving pre-settled, are shown as 
> accepted and unsettled (with a small number of undelivered) with presettled 
> count remaining at zero and the unsettled count growing. qpid-stat -m shows 
> growth in buffer and message content related types.
> It looks like there is no limit to the amount of messages the router will try 
> to buffer in this case(?) though I did not push it all the way to failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (DISPATCH-887) Dispatch reestablishes connection inspite of deleting the connector

2017-11-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on DISPATCH-887:
--

Commit e2a05e14eaa5740cfcd1d6be528ee548aa000441 in qpid-dispatch's branch 
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e2a05e1 ]

DISPATCH-887 - Fix race condition that led to connection reopen in spite of 
connector being deleted


> Dispatch reestablishes connection inspite of deleting the connector
> ---
>
> Key: DISPATCH-887
> URL: https://issues.apache.org/jira/browse/DISPATCH-887
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.1.0
>
>
> There is a race condition happening when a connector is deleted.
> On connector delete, the following function is called 
> {code}
> void qd_connection_manager_delete_connector(qd_dispatch_t *qd, void *impl)
> {
> qd_connector_t *ct = (qd_connector_t*) impl;
> if (ct) {
> sys_mutex_lock(ct->lock);
> if (ct->ctx && ct->ctx->pn_conn) {
> qd_connection_invoke_deferred(ct->ctx, deferred_close, 
> ct->ctx->pn_conn);
> }
> sys_mutex_unlock(ct->lock);
> DEQ_REMOVE(qd->connection_manager->connectors, ct);
> qd_connector_decref(ct);
> }
> }
> {code}
> The deferred_close() is invoked before qd_connector_decref() is invoked hence 
> the connection's connector is still in place and the connector is 
> re-established.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (DISPATCH-887) Dispatch reestablishes connection inspite of deleting the connector

2017-11-28 Thread Ganesh Murthy (JIRA)


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

Ganesh Murthy resolved DISPATCH-887.

Resolution: Fixed

> Dispatch reestablishes connection inspite of deleting the connector
> ---
>
> Key: DISPATCH-887
> URL: https://issues.apache.org/jira/browse/DISPATCH-887
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Container
>Affects Versions: 1.0.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.1.0
>
>
> There is a race condition happening when a connector is deleted.
> On connector delete, the following function is called 
> {code}
> void qd_connection_manager_delete_connector(qd_dispatch_t *qd, void *impl)
> {
> qd_connector_t *ct = (qd_connector_t*) impl;
> if (ct) {
> sys_mutex_lock(ct->lock);
> if (ct->ctx && ct->ctx->pn_conn) {
> qd_connection_invoke_deferred(ct->ctx, deferred_close, 
> ct->ctx->pn_conn);
> }
> sys_mutex_unlock(ct->lock);
> DEQ_REMOVE(qd->connection_manager->connectors, ct);
> qd_connector_decref(ct);
> }
> }
> {code}
> The deferred_close() is invoked before qd_connector_decref() is invoked hence 
> the connection's connector is still in place and the connector is 
> re-established.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests

2017-11-28 Thread ASF subversion and git services (JIRA)


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

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

Commit c401deb7e2e4c321518b0c925e653cb157e28cae 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=c401deb ]

QPID-6933: [System Tests] Fix failing test


> Factor out a JMS client neutral messaging test suite from system tests
> --
>
> Key: QPID-6933
> URL: https://issues.apache.org/jira/browse/QPID-6933
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>
> The existing system testsuite is in a poor state.
> * It is poorly structured
> * Mixes different types of test.  i.e. messaging behaviour with those that 
> test features of the Java Broker (e.g. REST).
> * Many of the tests refer directly to the implementation classes of the Qpid 
> Client 0-8..0-10 client meaning the tests cannot be run using the new client.
> As a first step, we want to factor out a separate messaging system test suite:
> * The tests in this suite will be JMS client neutral.
> * Written in terms of JNDI/JMS client
> * Configurations/Broker observations will be performed via a clean 
> Broker-neutral facade. For instance
> **  a mechanism to cause the queue to be created of a particular type.
> ** a mechanism to observe a queue depth.
> * The tests will be classified by feature (to be defined)
> * The classification system will be used to drive an exclusion feature (to be 
> defined).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

45 matches

Mail list logo