[jira] [Updated] (DISPATCH-2254) Routes messages to broker with large header
[ https://issues.apache.org/jira/browse/DISPATCH-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekta updated DISPATCH-2254: --- Description: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying to process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. After filtering out the headers to a smaller size, we could see the issue is resolved. If there a way to handle this a little better on on amq incase it is not possible on qpid layer, we would also consider that. Appreciate any feedback if anyone have faced this issue before as it could happen again in future. Below are some of the exceptions we saw related to above issue. Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is bigger than the max record size of 501,760 bytes. You should try to move large application properties to the message body. [condition = failed] 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] AMQ222086: error handling packet ReplicationSyncFileMessage(LARGE_MESSAGE, id=*) for replication: java.io.FileNotFoundException: /app/test/large-messages/*.msg (Too many open files) Thanks was: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying to process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. After filtering out the headers to a smaller size, we could see the issue is resolved. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before as it could again happen in future. Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is bigger than the max record size of 501,760 bytes. You should try to move large application properties to the message body. [condition = failed] 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] AMQ222086: error handling packet ReplicationSyncFileMessage(LARGE_MESSAGE, id=*) for replication: java.io.FileNotFoundException: /app/test/large-messages/*.msg (Too many open files) Thanks > Routes messages to broker with large header > --- > > Key: DISPATCH-2254 > URL: https://issues.apache.org/jira/browse/DISPATCH-2254 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.16.0 > Environment: PROD >Reporter: Ekta >Priority: Major > > Hello, > Below is what our application and messaging architecture looks like. > We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) > We recently saw a scenario where a java microservice application pushed a few > messages to our amq brokers where the message was containing a larger header > than the normal size header, which led to a very big disaster and caused our > whole amq env to shutdown. To avoid such cases like these, is there a way to > discard a message or handle this situation at the qpid layer so that it does > not endup on our brokers as qpid for us is basically acting like a proxy and > simply routes the traffic to brokers. Though the broker rejects this large > header message but still stores it in its memory and goes in a infinite loop > and keeps retrying to process the message wh
[jira] [Updated] (DISPATCH-2254) Routes messages to broker with large header
[ https://issues.apache.org/jira/browse/DISPATCH-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekta updated DISPATCH-2254: --- Description: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying to process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. After filtering out the headers to a smaller size, we could see the issue is resolved. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before as it could again happen in future. Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is bigger than the max record size of 501,760 bytes. You should try to move large application properties to the message body. [condition = failed] 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] AMQ222086: error handling packet ReplicationSyncFileMessage(LARGE_MESSAGE, id=*) for replication: java.io.FileNotFoundException: /app/test/large-messages/*.msg (Too many open files) Thanks was: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying the process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. After filtering out the headers to a smaller size, we could see the issue is resolved. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before as it could again happen in future. Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is bigger than the max record size of 501,760 bytes. You should try to move large application properties to the message body. [condition = failed] 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] AMQ222086: error handling packet ReplicationSyncFileMessage(LARGE_MESSAGE, id=*) for replication: java.io.FileNotFoundException: /app/test/large-messages/*.msg (Too many open files) Thanks > Routes messages to broker with large header > --- > > Key: DISPATCH-2254 > URL: https://issues.apache.org/jira/browse/DISPATCH-2254 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.16.0 > Environment: PROD >Reporter: Ekta >Priority: Major > > Hello, > Below is what our application and messaging architecture looks like. > We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) > We recently saw a scenario where a java microservice application pushed a few > messages to our amq brokers where the message was containing a larger header > than the normal size header, which led to a very big disaster and caused our > whole amq env to shutdown. To avoid such cases like these, is there a way to > discard a message or handle this situation at the qpid layer so that it does > not endup on our brokers as qpid for us is basically acting like a proxy and > simply routes the traffic to brokers. Though the broker rejects this large > header message but still stores it in its memory and goes in a infinite loop > and keeps retrying to process the message which causes a over head on the > brokers and immediately all the brokers go in shutdown
[jira] [Updated] (DISPATCH-2254) Routes messages to broker with large header
[ https://issues.apache.org/jira/browse/DISPATCH-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekta updated DISPATCH-2254: --- Description: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying the process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. After filtering out the headers to a smaller size, we could see the issue is resolved. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before as it could again happen in future. Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is bigger than the max record size of 501,760 bytes. You should try to move large application properties to the message body. [condition = failed] 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] AMQ222086: error handling packet ReplicationSyncFileMessage(LARGE_MESSAGE, id=*) for replication: java.io.FileNotFoundException: /app/test/large-messages/*.msg (Too many open files) Thanks was: Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying the process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before. Thanks > Routes messages to broker with large header > --- > > Key: DISPATCH-2254 > URL: https://issues.apache.org/jira/browse/DISPATCH-2254 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Affects Versions: 1.16.0 > Environment: PROD >Reporter: Ekta >Priority: Major > > Hello, > Below is what our application and messaging architecture looks like. > We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) > We recently saw a scenario where a java microservice application pushed a few > messages to our amq brokers where the message was containing a larger header > than the normal size header, which led to a very big disaster and caused our > whole amq env to shutdown. To avoid such cases like these, is there a way to > discard a message or handle this situation at the qpid layer so that it does > not endup on our brokers as qpid for us is basically acting like a proxy and > simply routes the traffic to brokers. Though the broker rejects this large > header message but still stores it in its memory and goes in a infinite loop > and keeps retrying the process the message which causes a over head on the > brokers and immediately all the brokers go in shutdown state. > After filtering out the headers to a smaller size, we could see the issue is > resolved. If there a way to handle this a little better on on amq incase it > is not possible on qpid layer. Would appreciate any feedback if anyone have > faced this issue before as it could again happen in future. > Caused by: javax.jms.JMSException: AMQ149005: Message of 564,590 bytes is > bigger than the max record size of 501,760 bytes. You should try to move > large application properties to the message body. [condition = failed] > 2021-09-22 07:37:01,092 WARN [org.apache.activemq.artemis.core.server] > AMQ
[jira] [Created] (DISPATCH-2254) Routes messages to broker with large header
Ekta created DISPATCH-2254: -- Summary: Routes messages to broker with large header Key: DISPATCH-2254 URL: https://issues.apache.org/jira/browse/DISPATCH-2254 Project: Qpid Dispatch Issue Type: Improvement Components: Routing Engine Affects Versions: 1.16.0 Environment: PROD Reporter: Ekta Hello, Below is what our application and messaging architecture looks like. We have a Microservice --> nlb --> qpid ---> amq brokers (Master/slave) We recently saw a scenario where a java microservice application pushed a few messages to our amq brokers where the message was containing a larger header than the normal size header, which led to a very big disaster and caused our whole amq env to shutdown. To avoid such cases like these, is there a way to discard a message or handle this situation at the qpid layer so that it does not endup on our brokers as qpid for us is basically acting like a proxy and simply routes the traffic to brokers. Though the broker rejects this large header message but still stores it in its memory and goes in a infinite loop and keeps retrying the process the message which causes a over head on the brokers and immediately all the brokers go in shutdown state. If there a way to handle this a little better on on amq incase it is not possible on qpid layer. Would appreciate any feedback if anyone have faced this issue before. Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2393) Enhancments to the AMQP Test driver
[ https://issues.apache.org/jira/browse/PROTON-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419362#comment-17419362 ] ASF subversion and git services commented on PROTON-2393: - Commit 92a0616cdae9dddc333220536d4d3a1e4ca72b29 in qpid-protonj2's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=qpid-protonj2.git;h=92a0616 ] PROTON-2393 Fix test peer session tracking of last remote open session > Enhancments to the AMQP Test driver > --- > > Key: PROTON-2393 > URL: https://issues.apache.org/jira/browse/PROTON-2393 > Project: Qpid Proton > Issue Type: Task > Components: protonj2 >Affects Versions: protonj2-1.0.0-M2 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Minor > Fix For: protonj2-1.0.0-M3 > > > Continue ongoing development of the AMQP test driver included in with the > ProtonJ2 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] kgiusti closed pull request #558: Dispatch 1403
kgiusti closed pull request #558: URL: https://github.com/apache/qpid-dispatch/pull/558 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-2065) AttributeError: 'DeleteConnectionWithReceiver' object has no attribute 'n_sent'
[
https://issues.apache.org/jira/browse/DISPATCH-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk reassigned DISPATCH-2065:
Assignee: (was: Jiri Daněk)
> AttributeError: 'DeleteConnectionWithReceiver' object has no attribute
> 'n_sent'
> ---
>
> Key: DISPATCH-2065
> URL: https://issues.apache.org/jira/browse/DISPATCH-2065
> Project: Qpid Dispatch
> Issue Type: Test
> Components: Tests
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Minor
> Fix For: 1.18.0
>
>
> https://github.com/apache/qpid-dispatch/pull/1052/checks?check_run_id=2394806073#step:9:2728
> The stacktrace below is caused by a copy-paste error. The test object does
> not have the attributes that are accessed.
> Furthermore, the test output does not provide any useful diagnostics in its
> output to investigate why the timeout happened.
> {noformat}
> 34: ==
> 34: ERROR: test_21_delete_connection_with_receiver
> (system_tests_two_routers.TwoRouterTest)
> 34: --
> 34: Traceback (most recent call last):
> 34: File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_two_routers.py",
> line 377, in test_21_delete_connection_with_receiver
> 34: test.run()
> 34: File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_two_routers.py",
> line 496, in run
> 34: Container(self).run()
> 34: File
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_reactor.py",
> line 182, in run
> 34: while self.process():
> 34: File
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_reactor.py",
> line 240, in process
> 34: event.dispatch(handler)
> 34: File
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
> line 162, in dispatch
> 34: _dispatch(handler, type.method, self)
> 34: File
> "/opt/hostedtoolcache/Python/3.7.10/x64/lib/python3.7/site-packages/proton/_events.py",
> line 123, in _dispatch
> 34: m(*args)
> 34: File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_test.py",
> line 1327, in on_timer_task
> 34: self.parent.timeout()
> 34: File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_two_routers.py",
> line 432, in timeout
> 34: self.error = "Timeout Expired: sent=%d, received=%d" % (self.n_sent,
> self.n_received)
> 34: AttributeError: 'DeleteConnectionWithReceiver' object has no attribute
> 'n_sent'
> 34:
> 34: --
> 34: Ran 32 tests in 124.158s
> 34:
> 34: FAILED (errors=1)
> 34:
> 18/37 Test #34: system_tests_two_routers ..***Failed
> 124.31 sec
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-2253) system_tests_two_router failing with missing attribute error
[
https://issues.apache.org/jira/browse/DISPATCH-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk closed DISPATCH-2253.
Resolution: Duplicate
> system_tests_two_router failing with missing attribute error
>
>
> Key: DISPATCH-2253
> URL: https://issues.apache.org/jira/browse/DISPATCH-2253
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.17.0
>Reporter: Ganesh Murthy
>Priority: Major
>
> {noformat}
> ==
> ERROR: test_21_delete_connection_with_receiver
> (system_tests_two_routers.TwoRouterTest)
> --
> Traceback (most recent call last):
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
> line 374, in test_21_delete_connection_with_receiver
> test.run()
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
> line 493, in run
> Container(self).run()
> File "/usr/lib64/python3.6/site-packages/proton/_reactor.py", line 194, in
> run
> while self.process():
> File "/usr/lib64/python3.6/site-packages/proton/_reactor.py", line 257, in
> process
> event.dispatch(handler)
> File "/usr/lib64/python3.6/site-packages/proton/_events.py", line 161, in
> dispatch
> _dispatch(handler, type.method, self)
> File "/usr/lib64/python3.6/site-packages/proton/_events.py", line 128, in
> _dispatch
> m(*args)
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_test.py",
> line 1312, in on_timer_task
> self.parent.timeout()
> File
> "/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
> line 429, in timeout
> self.error = "Timeout Expired: sent=%d, received=%d" % (self.n_sent,
> self.n_received)
> AttributeError: 'DeleteConnectionWithReceiver' object has no attribute
> 'n_sent' {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-2253) system_tests_two_router failing with missing attribute error
Ganesh Murthy created DISPATCH-2253:
---
Summary: system_tests_two_router failing with missing attribute
error
Key: DISPATCH-2253
URL: https://issues.apache.org/jira/browse/DISPATCH-2253
Project: Qpid Dispatch
Issue Type: Bug
Components: Tests
Affects Versions: 1.17.0
Reporter: Ganesh Murthy
{noformat}
==
ERROR: test_21_delete_connection_with_receiver
(system_tests_two_routers.TwoRouterTest)
--
Traceback (most recent call last):
File
"/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
line 374, in test_21_delete_connection_with_receiver
test.run()
File
"/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
line 493, in run
Container(self).run()
File "/usr/lib64/python3.6/site-packages/proton/_reactor.py", line 194, in run
while self.process():
File "/usr/lib64/python3.6/site-packages/proton/_reactor.py", line 257, in
process
event.dispatch(handler)
File "/usr/lib64/python3.6/site-packages/proton/_events.py", line 161, in
dispatch
_dispatch(handler, type.method, self)
File "/usr/lib64/python3.6/site-packages/proton/_events.py", line 128, in
_dispatch
m(*args)
File
"/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_test.py",
line 1312, in on_timer_task
self.parent.timeout()
File
"/home/jenkins/workspace/rh-qpid-dispatch-dist-el7-main/build/BUILD/qpid-dispatch-1.18.0/tests/system_tests_two_routers.py",
line 429, in timeout
self.error = "Timeout Expired: sent=%d, received=%d" % (self.n_sent,
self.n_received)
AttributeError: 'DeleteConnectionWithReceiver' object has no attribute 'n_sent'
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8563) [Broker-J] Purge all queues
Marek Laca created QPID-8563: Summary: [Broker-J] Purge all queues Key: QPID-8563 URL: https://issues.apache.org/jira/browse/QPID-8563 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Marek Laca It looks like that there is no way to instruct a broker to purge all queues. This story will implement such functionality. Two functions can be added to virtual host: # clearMatchingQueues with regular expression as input parameter. Every queue with the name that matches the regular expression should be cleared. # clearQueues with the list of queue IDs or names as input parameter. There can be a new button "Clear Queue" on the VirtualHost pane in Broker GUI that executes clearQueues function with selected queue IDs as the input parameter. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2252) Document router shutdown process
[ https://issues.apache.org/jira/browse/DISPATCH-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419066#comment-17419066 ] michael goulish commented on DISPATCH-2252: --- ...And if I see along the way anything that clearly needs improvement or investigation, Jira that too. > Document router shutdown process > > > Key: DISPATCH-2252 > URL: https://issues.apache.org/jira/browse/DISPATCH-2252 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: michael goulish >Assignee: michael goulish >Priority: Minor > > Investigate the router shutdown process in detail, and produce a document in > the docs directory. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
