hectorsq
Hi,
I’ve developed a Phoenix application that functions as a REST to SOAP converter. Instead of using a SOAP client package, I’ve implemented it using pure HTTP.
The application receives a JSON message from the client approximately every two seconds, converts it to XML, and forwards it to a SOAP server (SAP).
I’m utilizing Req, which in turn utilizes Finch and Mint.
After successfully sending several hundred messages, I encounter the following errors:
%Finch.Error{reason: :read_only}
03:43:47.343 [error] #PID<0.3996.0> running ErpInterfaceWeb.Endpoint (connection #PID<0.3995.0>, stream id 1) terminated
Restarting my app, which is hosted on Fly.io, resolves the issue.
I’m unsure if there’s a problem with my application, if the external server is blocking me, or if there’s an issue with Finch.
I’ve researched the “read_only” error but haven’t found any useful information. I’m uncertain whether this signifies a problem within my app or with the external server.
I’m considering replacing Req with Tesla, hoping it might resolve the issue.
Any insights would be greatly appreciated.
Regards,
Hector Sansores
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
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
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #blog-post
- #elixirconf-us
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync. Next: ElixirConf EU 2027
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
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 2- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
According to a quick GitHub search, “the connection is closed for writing”.
This file (the first of two matches in the GitHub search) has 26 matches of
read_only, I’d go read it in more detail. (Some of the matches are actually in the symbols outline on the right but still, at least 15 matches in the file from what I’ve seen.)And this file (the second match) implies that the server “has sent GOAWAY and then replies, we get the replies but are closed for writing” which might be I don’t know, rate limit hit? Or maybe you have inadvertently opened it in HTTP2 streaming mode without the option to write to the connection (as one of the code matches implies)?
al2o3cr
Sounds like what would happen if you were using a connection kept open with HTTP Keepalive and the remote end decided to close anyways.
For instance, if the remote service wants to deploy a new version of their code they’d likely “drain” persistent connections to the old servers.
I wouldn’t expect that kind of thing to require a reboot though - something should be supervising the connections and reconnect them afterwards.