Re: [PR] Close transport tail when freeing connection to avoid the client application hanging when TCP FIN+ACK arrives along with TCP RST. [qpid-proton-j]

[via GitHub]

anuchandy commented on PR #44:
URL: https://github.com/apache/qpid-proton-j/pull/44#issuecomment-2110882948

   Linking to JIRA https://issues.apache.org/jira/browse/PROTON-2823


-- 
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] [Created] (PROTON-2823) Proton-J does not raise transport closed when TCP FIN+ACK arrives followed by TCP RST

[Anu Thomas (Jira)]

Anu Thomas created PROTON-2823:
--

 Summary: Proton-J does not raise transport closed when TCP FIN+ACK 
arrives followed by TCP RST
 Key: PROTON-2823
 URL: https://issues.apache.org/jira/browse/PROTON-2823
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-j
Affects Versions: proton-j-0.34.1
Reporter: Anu Thomas
 Attachments: image-2024-05-14-11-36-02-828.png

We’ve noticed that after establishing the connection to the broker, if the 
broker network initiates the "TCP connection close FIN+ACK, along with RST" 
then the Proton-J does not signal a terminal event (e.g., transport close), 
which leaves the client application unable detect such a connection termination 
and recover.

The traffic flow is –
 # TCP layer on the service side sends FIN+ACK
 # Client TCP layer respond with FIN+ACK
 # TCP layer on the service side sends TCP RST
 # The Proton-J does not propagate any terminal event (e.g., transport close) 
to the registered handler for application to react to this disconnect.

Below is a Wireshark captured view of this traffic -

!image-2024-05-14-11-36-02-828.png!

While analyzing this, when this happens, we have noticed the following 
internally to Proton-J -
 # Proton-J SimpleSslTransportWrapper layer is in fact detecting this close 
[here|https://github.com/apache/qpid-proton-j/blob/adb9ebcc1cf76e18f1ef176fd77a4ae6a73cd557/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ssl/SimpleSslTransportWrapper.java#L232]
 and it marks its _head_closed flag as true indicating the outbound is closed.
 # Proton-J TrasportImpl even generate TRANSPORT_HEAD_CLOSED event but it never 
generates TRANSPORT_TAIL_CLOSED event, or TRANSPORT_CLOSED event which requires 
tail_close also to happen.
 # The Proton-J also frees all the internally registered Selectables, for 
example the Selectable associated with the TCP Connection and gracefully shut 
down these resources (and associated channels, timers tracking idle timeout).
 # We can also see that the internal 
[connectionFree|https://github.com/apache/qpid-proton-j/blob/adb9ebcc1cf76e18f1ef176fd77a4ae6a73cd557/proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java#L319]
 handler in the IOHandler is invoked (note: none of the other terminal handlers 
(connectionError, connectionExpired) are invoked)

 

I created below PR to address this - where it closes the transport tail when 
connection is free-ed, resulting in Proton-J signaling the transport 
termination to the application handlers. With this fix, the application is able 
to detect the connection drop and recover.

[Close transport tail when freeing connection to avoid the client application 
hanging when TCP FIN+ACK arrives along with TCP RST. by anuchandy · Pull 
Request #44 · apache/qpid-proton-j 
(github.com)|https://github.com/apache/qpid-proton-j/pull/44]

 

Can please experts from the Proton-J community take a look at this / fix?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[PR] Close transport tail when freeing connection to avoid the client application hanging when TCP FIN+ACK arrives along with TCP RST. [qpid-proton-j]

[via GitHub]

anuchandy opened a new pull request, #44:
URL: https://github.com/apache/qpid-proton-j/pull/44

   We’ve noticed that after establishing the connection to the broker, if the 
broker network initiates the "TCP connection close FIN+ACK, along with RST" 
then the Proton-J does not signal a terminal event (e.g., transport close), 
which leaves the client application unable detect such a connection termination 
and recover.
   
   The traffic flow is –
   1.   TCP layer on the service side sends FIN+ACK
   2.   Client TCP layer respond with FIN+ACK
   3.   TCP layer on the service side sends TCP RST
   4.   The Proton-J does not propagate any terminal event (e.g., transport 
close) to the registered handler for application to react to this disconnect.
   
   Below is a Wireshark captured view of this traffic -
   
   
![image](https://github.com/apache/qpid-proton-j/assets/1471612/5eedaa6b-e804-44c1-8d65-9abefc643f01)
   
   Below are the logs from the Proton-J in response to this traffic, Proton-J 
no longer emits any other logs post this –
   
   ```
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = input [SSLEngineResult status = CLOSED 
handshakeStatus = NEED_WRAP bytesConsumed = 31 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 31]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   FINEST o.a.q.p.e.i.s.SimpleSslTransportWrapper [reactor-executor-1] 
useClientMode = true direction = output [SSLEngineResult status = CLOSED 
handshakeStatus = NOT_HANDSHAKING bytesConsumed = 0 bytesProduced = 0]
   
   ```
   
   While analyzing this, when this happens, we have noticed the following 
internally to Proton-J - 
   1.   Proton-J SimpleSslTransportWrapper layer is in fact detecting this 
close 
[here](https://github.com/apache/qpid-proton-j/blob/adb9ebcc1cf76e18f1ef176fd77a4ae6a73cd557/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/ssl/SimpleSslTransportWrapper.java#L232)
 and it marks its _head_closed flag as true indicating the outbound is closed.  
   2.   Proton-J TrasportImpl even generate TRANSPORT_HEAD_CLOSED event but it 
never generates TRANSPORT_TAIL_CLOSED event, or TRANSPORT_CLOSED event which 
requires tail_close also to happen.
   3.   The Proton-J also frees all the internally registered Selectables, for 
example the Selectable associated with the TCP Connection and gracefully shut 
down these resources (and associated channels, timers tracking idle timeout).
   4.   We can also see that the internal 
[connectionFree](https://github.com/apache/qpid-proton-j/blob/adb9ebcc1cf76e18f1ef176fd77a4ae6a73cd557/proton-j/src/main/java/org/apache/qpid/proton/reactor/impl/IOHandler.java#L319)
 handler in the IOHandler is invoked (note: none of the other terminal handlers 
(connectionError, connectionExpired) are invoked)
   
   This is a PR to address this - where it closes the transport tail when 
connection is free-ed, resulting in Proton-J signaling the transport 
termination to the application handlers. With this fix, the application is able 
to detect the connection drop and recover.
   
   I’m new to the Proton-J code base, so can please experts (\\\cc @gemmellr)  
from the Proton-J community take a look at this / fix?
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the messag

Re: qpid-proton-cpp Connection issue

[Andrew Stitcher]

It's unclear from your message whether you're aware of this or not: but
there is an example of using qpid proton c++ to connect to service bus in
the provided c++ examples with qpid proton.
You will find this in the source tree:
https://github.com/apache/qpid-proton/blob/main/cpp/examples/service_bus.cpp

>From a brief search of the qpid code I don't think the error message is
coming from the qpid code so I think it is coming from the the Azure end -
you could substantiate this by running your client code with from logging
turned on - use the PN_LOG environment variable set to "frame".

If it is coming from the Azure end, the most likely reason I think is
probably an issue with quoting conventions in your connection string if
you're already using the same string with different APIs.

Hope this is helpful.

Andrew

On Wed, May 8, 2024 at 2:34 PM Alugoju, Shailaja (She/Her/Hers)
 wrote:

> Hi ,
>
> I am using qpid-proton-cpp library to integrate Azure service bus support
> into our application.
> I am getting the error "proton:io: The specified class was not found"
> I know this suggests there's a problem with the connection configuration.
> For Azure Service Bus, the correct format for the connection string
> typically includes the necessary authentication information. Here's how you
> can format the connection string:
> Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=
> ;SharedAccessKey=
> Where:
>  is your Azure Service Bus namespace.
>  is the name of your shared access policy.
>  is the shared access key associated with the policy.
>
> I did make sure you're using the correct values for ,
> , and  in your connection string.
> The connection string works fine in the Java version of Microsoft SDK for
> Azure.
>
> I am sure the problem is not the connection string.
>
> I believe the way I am using qpid-proton-cpp library might be the issue.
>
> Do you have any example of connecting to a service bus to send/receive
> messages via topics and queues?
> Any help is highly appreciated.
>
> Thanks in advance!
>
>
> Shailaja Alugoju
> Advanced Software Engr
> Honeywell Intelligrated
> Mobile: 513.341.0970
>
> shailaja.alug...@honeywell.com
> www.intelligrated.com
> Intelligrated.com | Twitter<
> https://twitter.com/intelligrated> | Facebook<
> https://www.facebook.com/pages/Intelligrated/154027751275774> | LinkedIn<
> http://www.linkedin.com/company/intelligrated> | YouTube<
> https://www.youtube.com/honeywellintelligrated> | HoneywellAIDC.com<
> http://www.honeywellaidc.com/>
>
>
>

Community over Code EU 2024: The countdown has started!

[Ryan Skraba]

[Note: You're receiving this email because you are subscribed to one
or more project dev@ mailing lists at the Apache Software Foundation.]

We are very close to Community Over Code EU -- check out the amazing
program and the special discounts that we have for you.

Special discounts

You still have the opportunity to secure your ticket for Community
Over Code EU. Explore the various options available, including the
regular pass, the committer and groups pass, and now introducing the
one-day pass tailored for locals in Bratislava.

We also have a special discount for you to attend both Community Over
Code and Berlin Buzzwords from June 9th to 11th. Visit our website to
find out more about this opportunity and contact te...@sg.com.mx to
get the discount code.

Take advantage of the discounts and register now!
https://eu.communityovercode.org/tickets/

Check out the full program!

This year Community Over Code Europe will bring to you three days of
keynotes and sessions that cover topics of interest for ASF projects
and the greater open source ecosystem including data engineering,
performance engineering, search, Internet of Things (IoT) as well as
sessions with tips and lessons learned on building a healthy open
source community.

Check out the program: https://eu.communityovercode.org/program/

Keynote speaker highlights for Community Over Code Europe include:

* Dirk-Willem Van Gulik, VP of Public Policy at the Apache Software
Foundation, will discuss the Cyber Resiliency Act and its impact on
open source (All your code belongs to Policy Makers, Politicians, and
the Law).

* Dr. Sherae Daniel will share the results of her study on the impact
of self-promotion for open source software developers (To Toot or not
to Toot, that is the question).

* Asim Hussain, Executive Director of the Green Software Foundation
will present a framework they have developed for quantifying the
environmental impact of software (Doing for Sustainability what Open
Source did for Software).

* Ruth Ikegah will  discuss the growth of the open source movement in
Africa (From Local Roots to Global Impact: Building an Inclusive Open
Source Community in Africa)

* A discussion panel on EU policies and regulations affecting
specialists working in Open Source Program Offices

Additional activities

* Poster sessions: We invite you to stop by our poster area and see if
the ideas presented ignite a conversation within your team.

* BOF time: Don't miss the opportunity to discuss in person with your
open source colleagues on your shared interests.

* Participants reception: At the end of the first day, we will have a
reception at the event venue. All participants are welcome to attend!

* Spontaneous talks: There is a dedicated room and social space for
having spontaneous talks and sessions. Get ready to share with your
peers.

* Lighting talks: At the end of the event we will have the awaited
Lighting talks, where every participant is welcome to share and
enlighten us.

Please remember:  If you haven't applied for the visa, we will provide
the necessary letter for the process. In the unfortunate case of a
visa rejection, your ticket will be reimbursed.

See you in Bratislava,

Community Over Code EU Team

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