[jira] [Updated] (PROTON-1998) [Proton-J] Add SASL protocol trace
[
https://issues.apache.org/jira/browse/PROTON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated PROTON-1998:
---
Summary: [Proton-J] Add SASL protocol trace (was: [Proton-J] Add SASL
proton trace)
> [Proton-J] Add SASL protocol trace
> --
>
> Key: PROTON-1998
> URL: https://issues.apache.org/jira/browse/PROTON-1998
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Reporter: Keith Wall
>Priority: Minor
>
> Unlike Proton, Proton-J does not provide SASL frame trace if environment
> variable PN_TRACE_FRM is set. It would be useful if Proton-J had this
> ability too to help diagnose SASL negotiation problem.
> Proton's SASL frame trace looks like this:
> {code:java}
> [0x7fc112c03a00]: -> SASL
> [0x7fc112c03a00]: <- SASL
> [0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"guest@Oslo.local"]
> [0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
> [0x7fc112c03a00]: -> AMQP
> [0x7fc112c03a00]:0 -> @open(16)
> [container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
> channel-max=32767]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1998) [Proton-J] Add SASL proton trace
Keith Wall created PROTON-1998:
--
Summary: [Proton-J] Add SASL proton trace
Key: PROTON-1998
URL: https://issues.apache.org/jira/browse/PROTON-1998
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Reporter: Keith Wall
Unlike Proton, Proton-J does not provide SASL frame trace if environment
variable PN_TRACE_FRM is set. It would be useful if Proton-J had this ability
too to help diagnose SASL negotiation problem.
Proton's SASL frame trace looks like this:
{code:java}
[0x7fc112c03a00]: -> SASL
[0x7fc112c03a00]: <- SASL
[0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
[0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=b"guest@Oslo.local"]
[0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
[0x7fc112c03a00]: -> AMQP
[0x7fc112c03a00]:0 -> @open(16)
[container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
channel-max=32767]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1996) Proton Client is "stalled" during SASL handshake
[
https://issues.apache.org/jira/browse/PROTON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754171#comment-16754171
]
Robbie Gemmell commented on PROTON-1996:
This seems more a discussion of vertx-proton at this point rather than the
proton-j engine, certainly any notion of timeouts would be for vertx-proton
(though in general that is left to the calling application, to your question,
though maybe this could be an exception).
That said, since youve already opened this already, and it might indicate a
router issue, it might be interesting if you could grab a frame trace from the
router side to see what it indicates (set env variable PN_TRACE_FRM=1).
Enabling the netty-level transport logging on the vertx-proton side might be
useful to see the bytes there (I don't recall how, just know its there). Using
a more recent proton-j might also be good, though I don't know of a particular
reason it would make a difference.
> Proton Client is "stalled" during SASL handshake
>
>
> Key: PROTON-1996
> URL: https://issues.apache.org/jira/browse/PROTON-1996
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.25.0
>Reporter: Daniel Maier
>Priority: Major
>
> Hi,
> When I try to connect with proton vertx client to an AMQP server, the client
> seems to come sporadically in some kind of "stalled" state. The logs, see
> below, look like the server just not responds anymore which cause the client
> to be stalled. There are no more logs regarding SASL handshake.
> Used server is qdrouter.
> Would it make sense from your point of view to introduce a timeout here? Or
> is the responsibility for this in the calling application?
> {code}
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
> io.netty.handler.ssl.SslHandler - [id: 0x429f2c43, L:/100.100.0.6:45982 -
> R:xxx.com/xxx:443] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
> state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
> 08:32:49.418 [vert.x-eventloop-thread-0] TRACE
> io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> 08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
> o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
> Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
> {code}
> Thanks
> Daniel
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-442) Ability to bind local address and port while connecting to Broker
[ https://issues.apache.org/jira/browse/QPIDJMS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-442. Resolution: Fixed Assignee: Robbie Gemmell Fix Version/s: 0.41.0 > Ability to bind local address and port while connecting to Broker > - > > Key: QPIDJMS-442 > URL: https://issues.apache.org/jira/browse/QPIDJMS-442 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: Rahul B >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.41.0 > > > When qpid-jms-client connect to broker it picks available local port > randomly(actually Netty libraries do this). I would like to control from > which port qpid-jms-client make the connection. > > Looking at the qpid-jms-client this can be achieved by configuring the > io.netty.bootstrap.Bootstrap class. But this class is being instantiated > inside org.apache.qpid.jms.transports.netty.NettyTcpTransport and only > configured with Channel Options. > PS this is the first time I'm posting an issue, so let me know if I need to > provide some more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-442) ability to configure local address and port while connecting
[ https://issues.apache.org/jira/browse/QPIDJMS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-442: --- Summary: ability to configure local address and port while connecting (was: Ability to bind local address and port while connecting to Broker) > ability to configure local address and port while connecting > > > Key: QPIDJMS-442 > URL: https://issues.apache.org/jira/browse/QPIDJMS-442 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: Rahul B >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.41.0 > > > When qpid-jms-client connect to broker it picks available local port > randomly(actually Netty libraries do this). I would like to control from > which port qpid-jms-client make the connection. > > Looking at the qpid-jms-client this can be achieved by configuring the > io.netty.bootstrap.Bootstrap class. But this class is being instantiated > inside org.apache.qpid.jms.transports.netty.NettyTcpTransport and only > configured with Channel Options. > PS this is the first time I'm posting an issue, so let me know if I need to > provide some more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-442) Ability to bind local address and port while connecting to Broker
[ https://issues.apache.org/jira/browse/QPIDJMS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-442: --- Priority: Minor (was: Major) > Ability to bind local address and port while connecting to Broker > - > > Key: QPIDJMS-442 > URL: https://issues.apache.org/jira/browse/QPIDJMS-442 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: Rahul B >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.41.0 > > > When qpid-jms-client connect to broker it picks available local port > randomly(actually Netty libraries do this). I would like to control from > which port qpid-jms-client make the connection. > > Looking at the qpid-jms-client this can be achieved by configuring the > io.netty.bootstrap.Bootstrap class. But this class is being instantiated > inside org.apache.qpid.jms.transports.netty.NettyTcpTransport and only > configured with Channel Options. > PS this is the first time I'm posting an issue, so let me know if I need to > provide some more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-442) Ability to bind local address and port while connecting to Broker
[ https://issues.apache.org/jira/browse/QPIDJMS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754110#comment-16754110 ] ASF GitHub Bot commented on QPIDJMS-442: gemmellr commented on issue #27: QPIDJMS-442 - Options to bind local address and port URL: https://github.com/apache/qpid-jms/pull/27#issuecomment-458199926 Thanks for the PR. I have pushed a change based on it, with some modifications and more tests, feel free to give it a try out. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ability to bind local address and port while connecting to Broker > - > > Key: QPIDJMS-442 > URL: https://issues.apache.org/jira/browse/QPIDJMS-442 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: Rahul B >Priority: Major > > When qpid-jms-client connect to broker it picks available local port > randomly(actually Netty libraries do this). I would like to control from > which port qpid-jms-client make the connection. > > Looking at the qpid-jms-client this can be achieved by configuring the > io.netty.bootstrap.Bootstrap class. But this class is being instantiated > inside org.apache.qpid.jms.transports.netty.NettyTcpTransport and only > configured with Channel Options. > PS this is the first time I'm posting an issue, so let me know if I need to > provide some more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] gemmellr commented on issue #27: QPIDJMS-442 - Options to bind local address and port
gemmellr commented on issue #27: QPIDJMS-442 - Options to bind local address and port URL: https://github.com/apache/qpid-jms/pull/27#issuecomment-458199926 Thanks for the PR. I have pushed a change based on it, with some modifications and more tests, feel free to give it a try out. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-442) Ability to bind local address and port while connecting to Broker
[ https://issues.apache.org/jira/browse/QPIDJMS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754106#comment-16754106 ] ASF subversion and git services commented on QPIDJMS-442: - Commit 0597ab62f79618cf1339e165e61d84ae7e55f056 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=0597ab6 ] QPIDJMS-442: transport options to configure local address and/or port used in connect Based on PR from rahul.b...@gmail.com, but with changes and more tests from me. This closes #27. > Ability to bind local address and port while connecting to Broker > - > > Key: QPIDJMS-442 > URL: https://issues.apache.org/jira/browse/QPIDJMS-442 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.40.0 >Reporter: Rahul B >Priority: Major > > When qpid-jms-client connect to broker it picks available local port > randomly(actually Netty libraries do this). I would like to control from > which port qpid-jms-client make the connection. > > Looking at the qpid-jms-client this can be achieved by configuring the > io.netty.bootstrap.Bootstrap class. But this class is being instantiated > inside org.apache.qpid.jms.transports.netty.NettyTcpTransport and only > configured with Channel Options. > PS this is the first time I'm posting an issue, so let me know if I need to > provide some more information. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1997) [Python] Urls class is not exported by reactor
Radim Kubis created PROTON-1997: --- Summary: [Python] Urls class is not exported by reactor Key: PROTON-1997 URL: https://issues.apache.org/jira/browse/PROTON-1997 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: proton-c-0.25.0 Reporter: Radim Kubis Assignee: Andrew Stitcher Fix For: proton-c-0.26.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1997) [Python] Urls class is not exported by reactor
[ https://issues.apache.org/jira/browse/PROTON-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kubis updated PROTON-1997: Affects Version/s: (was: proton-c-0.25.0) proton-c-0.26.0 > [Python] Urls class is not exported by reactor > -- > > Key: PROTON-1997 > URL: https://issues.apache.org/jira/browse/PROTON-1997 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.26.0 >Reporter: Radim Kubis >Assignee: Andrew Stitcher >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1997) [Python] Urls class is not exported by reactor
[ https://issues.apache.org/jira/browse/PROTON-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Kubis updated PROTON-1997: Fix Version/s: (was: proton-c-0.26.0) > [Python] Urls class is not exported by reactor > -- > > Key: PROTON-1997 > URL: https://issues.apache.org/jira/browse/PROTON-1997 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.25.0 >Reporter: Radim Kubis >Assignee: Andrew Stitcher >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1996) Proton Client is "stalled" during SASL handshake
[
https://issues.apache.org/jira/browse/PROTON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Maier updated PROTON-1996:
-
Description:
Hi,
When I try to connect with proton vertx client to an AMQP server, the client
seems to come sporadically in some kind of "stalled" state. The logs, see
below, look like the server just not responds anymore which cause the client to
be stalled. There are no more logs regarding SASL handshake.
Used server is qdrouter.
Would it make sense from your point of view to introduce a timeout here? Or is
the responsibility for this in the calling application?
{code}
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler
- [id: 0x429f2c43, L:/100.100.0.6:45982 - R:xxx.com/xxx:443] HANDSHAKEN:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
08:32:49.418 [vert.x-eventloop-thread-0] TRACE
io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
{code}
Thanks
Daniel
was:
Hi,
When I try to connect with proton vertx client to an AMQP server, the client
seems to come in some kind of "stalled" state. The logs, see below, look like
the server just not responds anymore which cause the client to be stalled.
There are no more logs regarding SASL handshake.
Used server is qdrouter.
Would it make sense from your point of view to introduce a timeout here? Or is
the responsibility for this in the calling application?
{code}
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler
- [id: 0x429f2c43, L:/100.100.0.6:45982 - R:xxx.com/xxx:443] HANDSHAKEN:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
08:32:49.418 [vert.x-eventloop-thread-0] TRACE
io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing
[jira] [Updated] (PROTON-1996) Proton Client is "stalled" during SASL handshake
[
https://issues.apache.org/jira/browse/PROTON-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Maier updated PROTON-1996:
-
Description:
Hi,
When I try to connect with proton vertx client to an AMQP server, the client
seems to come in some kind of "stalled" state. The logs, see below, look like
the server just not responds anymore which cause the client to be stalled.
There are no more logs regarding SASL handshake.
Used server is qdrouter.
Would it make sense from your point of view to introduce a timeout here? Or is
the responsibility for this in the calling application?
{code}
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler
- [id: 0x429f2c43, L:/100.100.0.6:45982 - R:xxx.com/xxx:443] HANDSHAKEN:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
08:32:49.418 [vert.x-eventloop-thread-0] TRACE
io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
{code}
Thanks
Daniel
was:
Hi,
When I try to connect with proton vertx client to an AMQP server, the client
seems to come in some kind of "stalled" state. The logs, see below, look like
the server just not responds anymore which cause the client to be stalled.
Used server is qdrouter.
Would it make sense from your point of view to introduce a timeout here? Or is
the responsibility for this in the calling application?
{code}
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler
- [id: 0x429f2c43, L:/100.100.0.6:45982 - R:xxx.com/xxx:443] HANDSHAKEN:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
08:32:49.418 [vert.x-eventloop-thread-0] TRACE
io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0
[jira] [Created] (PROTON-1996) Proton Client is "stalled" during SASL handshake
Daniel Maier created PROTON-1996:
Summary: Proton Client is "stalled" during SASL handshake
Key: PROTON-1996
URL: https://issues.apache.org/jira/browse/PROTON-1996
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: proton-j-0.25.0
Reporter: Daniel Maier
Hi,
When I try to connect with proton vertx client to an AMQP server, the client
seems to come in some kind of "stalled" state. The logs, see below, look like
the server just not responds anymore which cause the client to be stalled.
Used server is qdrouter.
Would it make sense from your point of view to introduce a timeout here? Or is
the responsibility for this in the calling application?
{code}
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=8 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.412 [vert.x-eventloop-thread-0] DEBUG io.netty.handler.ssl.SslHandler
- [id: 0x429f2c43, L:/100.100.0.6:45982 - R:xxx.com/xxx:443] HANDSHAKEN:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - SaslImpl [_outcome=PN_SASL_NONE,
state=PN_SASL_IDLE, done=false, role=CLIENT] about to call input.
08:32:49.418 [vert.x-eventloop-thread-0] TRACE
io.vertx.proton.impl.ProtonTransport - New Proton Event: CONNECTION_INIT
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
08:32:49.418 [vert.x-eventloop-thread-0] DEBUG
o.a.qpid.proton.engine.impl.SaslImpl - Finished writing SASL output. Output
Buffer : java.nio.HeapByteBuffer[pos=0 lim=512 cap=512]
{code}
Thanks
Daniel
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
