GenStage - Unexpected :ssl_closed message

genstage
troubleshooting
#1

Hi!

I have an Elixir application that is ingesting messages from a queue (AWS SQS). It is based off this design that uses GenStage.

The design is as follows:

  • GenStage Producer that fetches messages from the queue
  • GenStage Consumer that subscribes to Producer, receives the queue message and deletes it from the queue

The application runs smoothly with the exception of a failure that occurs 1-2 times every hour.
It seems that the GenStage Consumer is being sent the following message (which is not accounted for and hence fails):
{:sslsocket, {:gen_tcp, #Port<0.XXXX>, :tls_connection, :undefined}, #PID<0.XXXX.0>}}

I’m racking my brain trying to understand how this might be occurring. There are no explicit messages being sent to the consumer in my application code. The consumers are relatively simple as well - they’re simply using ExAws to make requests to AWS through their API. I don’t make any calls to :gen_tcp at any point.

I’m curious if anybody has encountered something similar or had any ideas about what might be going on.

For context:

Elixir Version:
1.5

Dependencies:

  • configparser_ex
  • credo
  • dialyxir
  • distillery
  • ex_aws
  • excoveralls
  • gen_stage
  • hackney
  • httpoison
  • mock
  • poison
  • sentry
  • sshex
  • sweet_xml
  • timex
2 Likes
#2

It may be a library that you invoke from the consumer that is sending the consumer processes unwanted messages. For example, maybe you are calling ExAWS.foo(...) and that is storing the consumer process which eventually leaks a message. Not saying it is ExAWS though, just an example.

1 Like
#3

One idea is to match on the message and use Port.info on the port and Process.info on the pid and then log the results so you can read it later on. That should give you more hints about which process is leaking them.

2 Likes
#4

That makes sense. Thanks for the leads!

I’ll continue investigating and will update with any progress made.

2 Likes
#5

Update on the investigation - it looks like calling Port.info and Process.info on the port and pid result in nil. It looks like the processes have died by the time the message is handled…

1 Like
#6

What is your erlang version? Erlang 19 has an issue with broken ssl. I’ve run into a similar issue which was fixed when I used the proper tls version :‘tlsv1.2’ (https://github.com/edgurgel/httpoison#note-about-broken-ssl-in-erlang-19)

2 Likes
#7

Unfortunately I’m on Erlang 20, I don’t know if that issue applies…

1 Like
#8

Did you find any solution to this issue? I’ve just encountered the same issue in a Genserver that consumes SQS messages using only ExAws.request()

1 Like
#9

I’m in the same boat, as well, with SQS.

#10

I believe the reason was the one mentioned above. Something is doing a request using SSL, then the connection is closed, and that leaks the ssl_closed message. The best option is to track whatever is leaking the message and fix the leakage but the leakage in itself shouldn’t be harmful.

#11

We noticed this behavior appearing after upgrading to OTP 21.2 (also using ExAWS with SQS).
Upgrading to 21.2.3+ reduced the occurances but didn’t fix it completely yet.

Some related pointers:
https://bugs.erlang.org/browse/ERL-371


2 Likes
#12

Getting the same issue using ExAWS and SQS. We just migrated our app from Heroku (Elixir 1.7.4 OTP 20.3) to AWS, upgrading at the same time the OTP version to 21.3 keeping the same Elixir version. We never saw this issue on Heroku.

#13

21.3 also had a ssl bug… please try with latest patch release… eg 21.3.8.3

you didn’t see it on heroku as you were using OTP 20.3

1 Like
#14

Thank you for the answer @outlog. We have upgraded OTP to 21.3.8.3 but we’re still seeing the issue.

#15

@antoniobg seems like it’s tracked here: https://github.com/benoitc/hackney/issues/464 - and that there is a current workaround of implementing
def handle_info({:ssl_closed, _msg}, state), do: {:noreply, state}

you could also consider using a different http client say HTTPotion:

https://hexdocs.pm/ex_aws/ExAws.Request.HttpClient.html