itsachen
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
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
josevalim
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.josevalim
One idea is to match on the message and use
Port.infoon the port andProcess.infoon 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.itsachen
That makes sense. Thanks for the leads!
I’ll continue investigating and will update with any progress made.
itsachen
Update on the investigation - it looks like calling
Port.infoandProcess.infoon the port and pid result innil. It looks like the processes have died by the time the message is handled…minhajuddin
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’ (GitHub - edgurgel/httpoison: Yet Another HTTP client for Elixir powered by hackney · GitHub)
itsachen
Unfortunately I’m on Erlang 20, I don’t know if that issue applies..
alex88
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()andersonmcook
I’m in the same boat, as well, with SQS.
josevalim
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.
eurico
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://github.com/benoitc/hackney/issues/464
https://github.com/ex-aws/ex_aws/issues/533