You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2019/01/28 17:37:00 UTC

[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&focusedCommentId=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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org