[jira] [Commented] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277388#comment-15277388
]
ASF GitHub Bot commented on DISPATCH-321:
-
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/71
DISPATCH-321 - Removed qdpn_connector_close call from process_connect…
…or. This will prevent premature closing of connection
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-321
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/71.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 #71
commit e9f1dd4951970ff6110229614f312ee5809979ec
Author: Ganesh Murthy
Date: 2016-05-10T00:08:39Z
DISPATCH-321 - Removed qdpn_connector_close call from process_connector.
This will prevent premature closing of connection
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-321 - Removed qdpn_connector_...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/71 DISPATCH-321 - Removed qdpn_connector_close call from process_connect⦠â¦or. This will prevent premature closing of connection You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-321 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/71.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 #71 commit e9f1dd4951970ff6110229614f312ee5809979ec Author: Ganesh Murthy Date: 2016-05-10T00:08:39Z DISPATCH-321 - Removed qdpn_connector_close call from process_connector. This will prevent premature closing of connection --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.
[ https://issues.apache.org/jira/browse/QPIDJMS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277274#comment-15277274 ] ASF subversion and git services commented on QPIDJMS-175: - Commit 18f7a894c343ea7bd53d979603ef3892bfc4eb9a in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=18f7a89 ] QPIDJMS-175 Set the resource's failure cause early to better reflect state prior to the async task closing the resource and other cleanup work. > Add support for a timeout value for drain requests. > --- > > Key: QPIDJMS-175 > URL: https://issues.apache.org/jira/browse/QPIDJMS-175 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add an additional timeout value in the AMQP consumer to deal with a remote > that doesn't respond to a drain request. The timeout handler should close > the MessageConsumer that is awaiting the drain with an exception since we > don't know what the remote state is following a lack of response to the > drain. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-330) Access control policy should return more suitable errors
Jakub Scholz created DISPATCH-330: - Summary: Access control policy should return more suitable errors Key: DISPATCH-330 URL: https://issues.apache.org/jira/browse/DISPATCH-330 Project: Qpid Dispatch Issue Type: Bug Components: Policy Engine Affects Versions: 0.6.0 Reporter: Jakub Scholz Currently, if some action is denied by the access control policy, it always returns amqp:resource-limit-exceeded error. This is fine when the deny was issues because of a limit (e.g.number of connections, sessions etc.). But when the action is denied for different reasons - e.g. because of unallowed target / source, amqp:unauthorized-access would be much more suitable than amqp:resource-limit-exceeded. As an example, see the situation below. Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 <- @attach(18) [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="request.ABCFR_ABCFRALMMACC1", durable=0, timeout=0, dynamic=false], target=@target(41) [address="request.ABCFR_ABCFRALMMACC1", durable=0, timeout=0, dynamic=false, capabili ties=:topic], initial-delivery-count=0] Mon May 9 09:12:47 2016 POLICY (info) DENY AMQP Attach sender link 'request.ABCFR_ABCFRALMMACC1' for user 'admin@QPID', host '127.0.0.1', app '(null)' based on link target name Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @attach(18) [name="request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: "\x00\x00\x00\x8f\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x7f\x00\x00\x00\x0a\xa1@request.ABCFR_ABCFRALMMACC1_113876ee-c7a3-4760-8e97-32d66e8ff0f1R\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00\x11\x00\x00\x00\x0b@R\x00@R\x00B@@\x00S)\xd0\x00\x00\x00\x0d\x00\x00\x00\x07@R\x00@R\x00BR\x00" Mon May 9 09:12:47 2016 SERVER (trace) [4]:0 -> @detach(22) [handle=0, closed=true, error=@error(29) [condition=:"amqp:resource-limit-exceeded", description="link disallowed by local policy"]] Mon May 9 09:12:47 2016 SERVER (trace) [4]:RAW: "\x00\x00\x00c\x02\x00\x00\x00\x00S\x16\xd0\x00\x00\x00S\x00\x00\x00\x03R\x00A\x00S\x1d\xd0\x00\x00\x00D\x00\x00\x00\x03\xa3\x1camqp:resource-limit-exceeded\xa1\x1flink disallowed by local policy@" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-329) Javascript error when clicking line between node and client
Ernest Allen created DISPATCH-329: - Summary: Javascript error when clicking line between node and client Key: DISPATCH-329 URL: https://issues.apache.org/jira/browse/DISPATCH-329 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen On the topology page, if you click on the small line between a node and a client, you'll get a javascript error popup. Clicking on the line should have no effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-321:
--
Assignee: Ganesh Murthy
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-328) Add spout/drain
Ernest Allen created DISPATCH-328: - Summary: Add spout/drain Key: DISPATCH-328 URL: https://issues.apache.org/jira/browse/DISPATCH-328 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Add a dialog that allows messages to be sent and received to an address. On the topology page, add a menu item to the node's right-click context menu that displays a dialog that can send /receive messages. The dialog's features are: - Choose to send or receive messages - Show all existing local address in a dropdown - Allow the specification of a new address - If the node already has normal listeners show them in a dropdown - Allow the creation of a new listener by entering a new port number - Enter message body - If sending messages: - Enter the number of messages to send - Enter the delay between messages - Optionally show a graph of the number of messages sent over time - If receiving messages: - Optionally show a graph of the number of messages received over time - Allow the dialog to be minimized. Show minimized dialogs as clients attached to that node. Re-expand minimized dialogs when double clicked. - If a new listener was created, delete it when closing the dialog - Allow a dialog's settings to be saved, re-used, deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-321:
---
Description:
Setup a listener with SASL PLAIN authentication on dispatch and use a client to
connect to the listener using the wrong PLAIN username/password.
Dispatch closes the connection without sending the SASL-OUTCOME frame.
Here is the trace from the client connecting to the router
{noformat}
Dispatch:
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
{noformat}
Here is the trace from the router with PN_TRACE_FRM=1. This router is acting as
a client trying to connect to another router acting as a server.
{noformat}
[0x25bd9e0]: -> SASL
[0x25bd9e0]: <- SASL
[0x25bd9e0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
[0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00t...@domain.com\x00password1"]
[0x25bd9e0]: <- EOS
[0x25bd9e0]: -> EOS
Closed 127.0.0.1:24976
{noformat}
The above clearly shows that the router is not receiving a SASL-OUTCOME frame.
It looks like the server prematurely closes the connection.
was:
Setup a listener with SASL PLAIN authentication on dispatch and use a client to
connect to the listener using the wrong PLAIN username/password.
Dispatch closes the connection without sending the SASL-OUTCOME frame.
Here is the trace from the client connecting to the router
{noformat}
Dispatch:
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
{noformat}
Here is the trace from the router side with PN_TRACE_FRM=1
{noformat}
[0x25bd9e0]: -> SASL
[0x25bd9e0]: <- SASL
[0x25bd9e0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
[0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00t...@domain.com\x00password1"]
[0x25bd9e0]: <- EOS
[0x25bd9e0]: -> EOS
Closed 127.0.0.1:24976
{noformat}
The above clearly shows that the router is not sending a SASL-OUTCOME but
prematurely closes the connection.
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router with PN_TRACE_FRM=1. This router is acting
> as a client trying to connect to another router acting as a server.
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not receiving a SASL-OUTCOME
> frame. It looks like the server prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional command
[jira] [Created] (DISPATCH-327) Locally stored variables should be keyed by the connected host
Ernest Allen created DISPATCH-327: - Summary: Locally stored variables should be keyed by the connected host Key: DISPATCH-327 URL: https://issues.apache.org/jira/browse/DISPATCH-327 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Currently, the same stored values are used regardless of the connected router's host. This leads to problem when you switch to a different router network: - charts cause errors - the entity page has no selected router node Any variables stored in localstorage should be associated to the host name of the connected router. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-326) Sliders are missing on the chart configuration page
Ernest Allen created DISPATCH-326: - Summary: Sliders are missing on the chart configuration page Key: DISPATCH-326 URL: https://issues.apache.org/jira/browse/DISPATCH-326 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen On the charts configuration page, the slider for setting the rate period and the chart duration are missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-325) Allow charts to be configured before added them to the dashboard
Ernest Allen created DISPATCH-325: - Summary: Allow charts to be configured before added them to the dashboard Key: DISPATCH-325 URL: https://issues.apache.org/jira/browse/DISPATCH-325 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Priority: Minor Charts can only be configured after they are added to a dashboard. It would be good to configure charts before they are added as well -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-324) Improve initial layout of topology node
Ernest Allen created DISPATCH-324: - Summary: Improve initial layout of topology node Key: DISPATCH-324 URL: https://issues.apache.org/jira/browse/DISPATCH-324 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Priority: Minor When a new network of routers is encountered, the nodes on the topology page are initially placed on a line. The d3 library's force graph then moves them into n configuration (which can then be adjusted by the user). That initial layout is a bit messy when there are more than 4 nodes. It would be cleaner to initially layout the nodes in a circle. The d3 library could then discover a more pleasing layout. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-323) Separate the websockify installation instruction from the usage instructions
Ernest Allen created DISPATCH-323: - Summary: Separate the websockify installation instruction from the usage instructions Key: DISPATCH-323 URL: https://issues.apache.org/jira/browse/DISPATCH-323 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Priority: Trivial For console/README.md The instructions for manually running a proxy using websockify contain the instructions for how to install websockify. Since you need to install websockify whether you use the manual method or the automatic method, the installation instruction should be separate. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-313) Tree on left side of entity page scrolls back to top after data is updated
[ https://issues.apache.org/jira/browse/DISPATCH-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-313: -- Affects Version/s: (was: 0.6.0) 0.7.0 > Tree on left side of entity page scrolls back to top after data is updated > --- > > Key: DISPATCH-313 > URL: https://issues.apache.org/jira/browse/DISPATCH-313 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > If the tree on the left side of the entity page is expanded and scrolled > down, then when the tree data is automatically updated the tree is scrolled > back to the top. This makes navigating around the tree difficult. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-314) If a router has a normal listener, show it in a different color on the topology page
[ https://issues.apache.org/jira/browse/DISPATCH-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-314: -- Affects Version/s: (was: 0.6.0) 0.7.0 > If a router has a normal listener, show it in a different color on the > topology page > > > Key: DISPATCH-314 > URL: https://issues.apache.org/jira/browse/DISPATCH-314 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Minor > > It would be nice see which routers can have clients attached to them at a > glance on the topology page. > Currently all routers are displayed with a gray background. Routers that have > a normal listener can be displayed with a different background color. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-315) Handle saved charts from other router networks
[ https://issues.apache.org/jira/browse/DISPATCH-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-315: -- Affects Version/s: (was: 0.6.0) 0.7.0 > Handle saved charts from other router networks > -- > > Key: DISPATCH-315 > URL: https://issues.apache.org/jira/browse/DISPATCH-315 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > Javascript errors occur when a chart is saved when connected to a router > network and then displayed when connected to a different router network. > To reproduce: > - Connect to the 2 node router network from tests/config-2 > - Save a chart to the dashboard > - Disconnect and connect to a different router network e.g. tests/config-6 > - View the dashboard > Javascript errors will occur because the saved chart requests don't match the > connected router network. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-322) Graph icon is missing when browser window is narrow
Ernest Allen created DISPATCH-322: - Summary: Graph icon is missing when browser window is narrow Key: DISPATCH-322 URL: https://issues.apache.org/jira/browse/DISPATCH-322 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen When the browser window is less than 1024 px wide, the graph icon for aggregate values on the entity page is truncated and not reachable. Either use a horizontal scroll bar or resize the column width to allow the graph icon to be visible and therefore clickable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-269) Policy denial logs at wrong level
[ https://issues.apache.org/jira/browse/DISPATCH-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-269. -- Resolution: Fixed Fix Version/s: 0.6.0 Fixed at Commit 150a053 > Policy denial logs at wrong level > - > > Key: DISPATCH-269 > URL: https://issues.apache.org/jira/browse/DISPATCH-269 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 0.6.0 >Reporter: Chuck Rolke > Fix For: 0.6.0 > > > Both accept and deny messages are at 'debug'. The proposal is to lower accept > messages to 'trace' and raise deny messages to 'info'. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-267) Policy does not increment denial statistics
[ https://issues.apache.org/jira/browse/DISPATCH-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed DISPATCH-267. Resolution: Fixed Fix Version/s: 0.6.0 Fixed at Commit fd38b72 > Policy does not increment denial statistics > --- > > Key: DISPATCH-267 > URL: https://issues.apache.org/jira/browse/DISPATCH-267 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-175) Add support for a timeout value for drain requests.
[ https://issues.apache.org/jira/browse/QPIDJMS-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276389#comment-15276389 ] ASF subversion and git services commented on QPIDJMS-175: - Commit 144e690a3ce3d892965b8d4147af578409e05b98 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=144e690 ] QPIDJMS-175 Improve test reliability. > Add support for a timeout value for drain requests. > --- > > Key: QPIDJMS-175 > URL: https://issues.apache.org/jira/browse/QPIDJMS-175 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add an additional timeout value in the AMQP consumer to deal with a remote > that doesn't respond to a drain request. The timeout handler should close > the MessageConsumer that is awaiting the drain with an exception since we > don't know what the remote state is following a lack of response to the > drain. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-321:
---
Description:
Setup a listener with SASL PLAIN authentication on dispatch and use a client to
connect to the listener using the wrong PLAIN username/password.
Dispatch closes the connection without sending the SASL-OUTCOME frame.
Here is the trace from the client connecting to the router
{noformat}
Dispatch:
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
{noformat}
Here is the trace from the router side with PN_TRACE_FRM=1
{noformat}
[0x25bd9e0]: -> SASL
[0x25bd9e0]: <- SASL
[0x25bd9e0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
[0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00t...@domain.com\x00password1"]
[0x25bd9e0]: <- EOS
[0x25bd9e0]: -> EOS
Closed 127.0.0.1:24976
{noformat}
The above clearly shows that the router is not sending a SASL-OUTCOME but
prematurely closes the connection.
was:
Setup a listener with SASL PLAIN authentication on dispatch and use a client to
connect to the listener using the wrong PLAIN username/password.
Dispatch closes the connection without sending the SASL-OUTCOME frame.
Here is the trace from the client connecting to the router
{noformat}
Dispatch:
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
{noformat}
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
> Here is the trace from the router side with PN_TRACE_FRM=1
> {noformat}
> [0x25bd9e0]: -> SASL
> [0x25bd9e0]: <- SASL
> [0x25bd9e0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:"DIGEST-MD5", :PLAIN]]
> [0x25bd9e0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00t...@domain.com\x00password1"]
> [0x25bd9e0]: <- EOS
> [0x25bd9e0]: -> EOS
> Closed 127.0.0.1:24976
> {noformat}
> The above clearly shows that the router is not sending a SASL-OUTCOME but
> prematurely closes the connection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7251) [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
[
https://issues.apache.org/jira/browse/QPID-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276371#comment-15276371
]
Lorenz Quack commented on QPID-7251:
It seems that specifying the {{response}} parameter is broken as well.
> [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then
> PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
> --
>
> Key: QPID-7251
> URL: https://issues.apache.org/jira/browse/QPID-7251
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Reporter: Alex Rudyy
>Assignee: Lorenz Quack
>
> Before adding the ability to negotiate SASL mechanism (in QPID-6116) the
> required mechanism could be specified with parameter 'mechanism' in
> Client.start(...). The client still support this parameter but sasl object is
> not created and receipt of connection.start results in error as the one below:
> {noformat}
> Error in handler: connection_start
> Traceback (most recent call last):
> File "/home/alex/qpid/python/qpid/delegate.py", line 47, in __call__
> return handler(channel, frame)
> File "/home/alex/qpid/python/qpid/client.py", line 167, in connection_start
> self.client.response = self.client.sasl.initialResponse()
> AttributeError: 'NoneType' object has no attribute 'initialResponse'
> {noformat}
> In general, it is not good idea to specify the mechanism explicitly. The
> client application should rely on existing negotiation logic. However, the
> client should keep backward compatibility and should respect the provided
> mechanism: at least it can check whether mechanism is supported by the broker
> and create sasl object to drive sasl negotiation if mechanism is supported;
> otherwise, throw sasl exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
Ganesh Murthy created DISPATCH-321:
--
Summary: Dispatch does not send out SASL-OUTCOME frame on sasl
failure
Key: DISPATCH-321
URL: https://issues.apache.org/jira/browse/DISPATCH-321
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.6.0
Reporter: Ganesh Murthy
Setup a listener with SASL PLAIN authentication on dispatch and use a client to
connect to the listener using the wrong PLAIN username/password.
Dispatch closes the connection without sending the SASL-OUTCOME frame.
Here is the trace from the client connecting to the router
{noformat}
Dispatch:
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
header: 1-0
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-321) Dispatch does not send out SASL-OUTCOME frame on sasl failure
[
https://issues.apache.org/jira/browse/DISPATCH-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276352#comment-15276352
]
Ganesh Murthy commented on DISPATCH-321:
This issue was reported by Jakub Scholz
> Dispatch does not send out SASL-OUTCOME frame on sasl failure
> -
>
> Key: DISPATCH-321
> URL: https://issues.apache.org/jira/browse/DISPATCH-321
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>
> Setup a listener with SASL PLAIN authentication on dispatch and use a client
> to connect to the listener using the wrong PLAIN username/password.
> Dispatch closes the connection without sending the SASL-OUTCOME frame.
> Here is the trace from the client connecting to the router
> {noformat}
> Dispatch:
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 writing protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 read protocol
> header: 1-0
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Received
> SASL-MECHANISMS(PLAIN DIGEST-MD5 CRAM-MD5 )
> 2016-05-09 03:08:00 [Protocol] debug tcp:localhost:5672 Sent
> SASL-INIT(PLAIN, \x00admin@QPID\x00adminxxx, localhost)
> qpid-receive: Connect failed to amqp:tcp:localhost:5672: Reconnect disabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-320) SSL enabled connector does not do hostname verification
[ https://issues.apache.org/jira/browse/DISPATCH-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276325#comment-15276325 ] Ganesh Murthy commented on DISPATCH-320: This issue was reported by Jakub Scholz > SSL enabled connector does not do hostname verification > --- > > Key: DISPATCH-320 > URL: https://issues.apache.org/jira/browse/DISPATCH-320 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.6.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > > When a connector is ssl enabled (contains an sslProfile), dispatch does not > do hostname verification. > Dispatch must ensure that the host name in the URL to which it connects > matches the host name in the digital certificate that the server sends back > as part of the SSL connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-320) SSL enabled connector does not do hostname verification
Ganesh Murthy created DISPATCH-320: -- Summary: SSL enabled connector does not do hostname verification Key: DISPATCH-320 URL: https://issues.apache.org/jira/browse/DISPATCH-320 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.6.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy When a connector is ssl enabled (contains an sslProfile), dispatch does not do hostname verification. Dispatch must ensure that the host name in the URL to which it connects matches the host name in the digital certificate that the server sends back as part of the SSL connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-173) Provide for finer grained control over automatic presettling of received messages
[ https://issues.apache.org/jira/browse/QPIDJMS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276245#comment-15276245 ] ASF subversion and git services commented on QPIDJMS-173: - Commit 9a8a9c1c6612171519fc64ec735024290b5fd58d in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=9a8a9c1 ] QPIDJMS-173: give more time to avoid issues on slow shared CI systems > Provide for finer grained control over automatic presettling of received > messages > - > > Key: QPIDJMS-173 > URL: https://issues.apache.org/jira/browse/QPIDJMS-173 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Allow for configuration on a policy level for controlling automatic settling > of incoming messages. This make sense in cases such as Topic receivers etc > where the message loss is non-critical. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7253) [Java Client 0-10] Application allowed to create new JMS session whilst failover is in progress
[
https://issues.apache.org/jira/browse/QPID-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276240#comment-15276240
]
ASF subversion and git services commented on QPID-7253:
---
Commit 1742926 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1742926 ]
QPID-7253: [Java Client, 0-10] Take failover mutex when executing operations
that may be interrupted by failover
> [Java Client 0-10] Application allowed to create new JMS session whilst
> failover is in progress
> ---
>
> Key: QPID-7253
> URL: https://issues.apache.org/jira/browse/QPID-7253
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.2
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.0.3, qpid-java-6.1
>
>
> Unlike the 0-8 path, creating a JMS session {{Connection#createSession()}}
> does not take the failover mutex. This means that an application's call to
> createSession does not block whilst failover is in flight. This gives rise
> to a race between application's creation of the new session and the
> re-subscription of the existing sessions. In an unlucky case, this may cause
> the client to try and attach the same session twice. This will be rejected
> by the Broker with a SESSION_BUSY.
> Following annotated log excerpt is from 6.0.2.
> {noformat}
> # Failover has just reconnected an application with existing JMS sessions,
> but failover is not yet 'finished'
> 2016-05-04 17:31:26,778 DEBUG [com/192.168.0.1:18575] [
>Connection] RECV: [conn:eb35720] ch=0 ConnectionOpenOk(knownHosts=[])
> 2016-05-04 17:31:26,779 INFO [com/192.168.0.1:18575] [
> AMQConnection] Connection 1 now connected from /192.168.0.2:48956 to
> myhost.example.com/192.168.0.1:18
> 575
> # Application thread gets in and creates a new session
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] SEND: [conn:eb35720] ch=2
> SessionAttach(name="916a6c14-069f-4cd0-ba8b-dde789766864")
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,779 DEBUG [ app-listener-thread:01] [
>Connection] SEND: [conn:eb35720] ch=2
> SessionRequestTimeout(timeout=0)
> # Failover begins to 'rewire' the existing JMS objects
> 2016-05-04 17:31:26,780 INFO [com/192.168.0.1:18575] [
> AMQConnectionDelegate_0_10] Resuming connection
> 2016-05-04 17:31:26,780 DEBUG [ app-listener-thread:01] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionAttach(name="edd4afef-052f-4dfc-8af0-ca96a887977c")
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 SessionRequestTimeout(timeout=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionCommandPoint(commandId=12383, commandOffset=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 id=12383 ExecutionSync()
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3
> SessionCommandPoint(commandId=12384, commandOffset=0)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 SessionFlush(completed=true)
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] FLUSH: [conn:eb35720]
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] SEND: [conn:eb35720] ch=3 id=12384 TxSelect()
> 2016-05-04 17:31:26,781 DEBUG [com/192.168.0.1:18575] [
>Connection] F
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276214#comment-15276214 ] Flavio Baronti commented on QPID-7237: -- Keith, unfortunately I had this behavior only in the production environment, where I can't take the risk to test the new implementation. I reviewed your proposal, and I agree it would avoid the error I got after the client spawned over 8k threads. However, in the situation I observed, it would create tasks in the executor service queue, which might get out of control anyway - and filling the heap rather than exhausting the available threads, so the likelihood of this happening is quite lower. > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti >Assignee: Keith Wall > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7251) [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
[
https://issues.apache.org/jira/browse/QPID-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack reassigned QPID-7251:
--
Assignee: Lorenz Quack
> [Python Client for AMQP 0-8...0-91] Setting of SASL mechanism (other then
> PLAIN) explicitly does not work in python client for AMQP 0-8...0-91
> --
>
> Key: QPID-7251
> URL: https://issues.apache.org/jira/browse/QPID-7251
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Reporter: Alex Rudyy
>Assignee: Lorenz Quack
>
> Before adding the ability to negotiate SASL mechanism (in QPID-6116) the
> required mechanism could be specified with parameter 'mechanism' in
> Client.start(...). The client still support this parameter but sasl object is
> not created and receipt of connection.start results in error as the one below:
> {noformat}
> Error in handler: connection_start
> Traceback (most recent call last):
> File "/home/alex/qpid/python/qpid/delegate.py", line 47, in __call__
> return handler(channel, frame)
> File "/home/alex/qpid/python/qpid/client.py", line 167, in connection_start
> self.client.response = self.client.sasl.initialResponse()
> AttributeError: 'NoneType' object has no attribute 'initialResponse'
> {noformat}
> In general, it is not good idea to specify the mechanism explicitly. The
> client application should rely on existing negotiation logic. However, the
> client should keep backward compatibility and should respect the provided
> mechanism: at least it can check whether mechanism is supported by the broker
> and create sasl object to drive sasl negotiation if mechanism is supported;
> otherwise, throw sasl exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7254) [Python Client] Perform SSL hostname verification
[ https://issues.apache.org/jira/browse/QPID-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reassigned QPID-7254: -- Assignee: Lorenz Quack > [Python Client] Perform SSL hostname verification > - > > Key: QPID-7254 > URL: https://issues.apache.org/jira/browse/QPID-7254 > Project: Qpid > Issue Type: Improvement > Components: Python Client >Reporter: Lorenz Quack >Assignee: Lorenz Quack > > Currently the Python client does not perform hostname verification. > We should add this ability. Ideally it should respect hostnames from both CN > and SANs and support wildcards. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7254) [Python Client] Perform SSL hostname verification
[ https://issues.apache.org/jira/browse/QPID-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276169#comment-15276169 ] Lorenz Quack commented on QPID-7254: SSL support in Python has historically (pre 2.6) been limited. This should be handled reasonably. I propose to throw an exception if Python does not support hostname verification unless a flag is passed explicitly disabling hostname verification. There should be no hard dependency on this ability. > [Python Client] Perform SSL hostname verification > - > > Key: QPID-7254 > URL: https://issues.apache.org/jira/browse/QPID-7254 > Project: Qpid > Issue Type: Improvement > Components: Python Client >Reporter: Lorenz Quack > > Currently the Python client does not perform hostname verification. > We should add this ability. Ideally it should respect hostnames from both CN > and SANs and support wildcards. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7254) [Python Client] Perform SSL hostname verification
Lorenz Quack created QPID-7254: -- Summary: [Python Client] Perform SSL hostname verification Key: QPID-7254 URL: https://issues.apache.org/jira/browse/QPID-7254 Project: Qpid Issue Type: Improvement Components: Python Client Reporter: Lorenz Quack Currently the Python client does not perform hostname verification. We should add this ability. Ideally it should respect hostnames from both CN and SANs and support wildcards. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7237: - Fix Version/s: qpid-java-6.1 qpid-java-6.0.3 > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276149#comment-15276149 ] Keith Wall commented on QPID-7237: -- Flavio, I changed the code to use a thread pool rather than spawning new threads. I think this should resolve your problem. Would you mind testing the change from trunk and confirming? > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7237: Assignee: Keith Wall > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti >Assignee: Keith Wall > Fix For: qpid-java-6.0.3, qpid-java-6.1 > > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7237) Excessive threads creation when suspending/resuming flow
[ https://issues.apache.org/jira/browse/QPID-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276145#comment-15276145 ] ASF subversion and git services commented on QPID-7237: --- Commit 1742900 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1742900 ] QPID-7237: [Java Client] Use single thread thread-pool to perform flow control on no-ack sessions * Avoids spawning new thread for each state change > Excessive threads creation when suspending/resuming flow > > > Key: QPID-7237 > URL: https://issues.apache.org/jira/browse/QPID-7237 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.24, qpid-java-6.0.2 >Reporter: Flavio Baronti > Attachments: QPID-7237.patch > > > In high load situations, with a NO_ACKNOWLEDGE session, it is possible for > the client to create an excessive amount of threads to suspend/resume the > channel. > I'm providing a patch to avoid creating a new thread if the previous thread > has not completed its operation. This patch appears to avoid the problem in > our environment. Notice we are using version 0.24, but the code is the same > in the latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
