xmpp: Serve returns error when connection is closed #248

New Issue

Open

opened 2022-02-01 12:57:46 +00:00 by SamWhited · 1 comment

SamWhited commented

2022-02-01 12:57:46 +00:00

Owner

When doing something like the following common pattern:

session, err := xmpp.DialClientSession(…)

defer func() {
	if err := session.Close(); err != nil {
		…
	}
	if err := session.Conn().Close(); err != nil {
		…
	}
}()

go func() {
	err := session.Serve(mux)
	if err != nil {
		…
	}
}()

After the deferred function is run, Serve returns an error:

error handling session responses: read tcp xxx->xxx: use of closed network connection"

This is probably a blocked call to Read in the token decoder returning and is an expected error that can be ignored. However, this means that session.Close() did not unblock the read call. We should dig in and confirm that this is what's happening, and make sure Reads get unblocked cleanly if possible.

When doing something like the following common pattern: ```go session, err := xmpp.DialClientSession(…) defer func() { if err := session.Close(); err != nil { … } if err := session.Conn().Close(); err != nil { … } }() go func() { err := session.Serve(mux) if err != nil { … } }() ``` After the deferred function is run, `Serve` returns an error: > error handling session responses: read tcp xxx->xxx: use of closed network connection" This is probably a blocked call to `Read` in the token decoder returning and is an expected error that can be ignored. However, this means that `session.Close()` did not unblock the read call. We should dig in and confirm that this is what's happening, and make sure Reads get unblocked cleanly if possible.

SamWhited commented

2022-02-01 14:12:11 +00:00

Poster

Owner

It looks like *Session.Close() returns immediately after sending the stream close element. It should probably block until it receives a </stream:stream> in reply. This may not be easy with the current architecture though, and I'm not 100% sure that it will matter to fixing this problem either way.

7ce4904317/session.go (L824-L854)

It looks like `*Session.Close()` returns immediately after sending the stream close element. It should probably block until it receives a `</stream:stream>` in reply. This may not be easy with the current architecture though, and I'm not 100% sure that it will matter to fixing this problem either way. https://github.com/mellium/xmpp/blob/7ce490431777e7ed1e641442e65c3007abb3875b/session.go#L824-L854