Open brianmay opened 10 months ago
Here is the trace log:
2023-10-22T08:09:41.143415Z TRACE mio::poll: registering event source with poller: token=Token(140525491503488), interests=READABLE | WRITABLE
2023-10-22T08:09:41.143483Z TRACE tokio_util::codec::framed_impl: flushing framed transport
2023-10-22T08:09:41.143491Z TRACE tokio_util::codec::framed_impl: writing; remaining=9
2023-10-22T08:09:41.143557Z TRACE tokio_util::codec::framed_impl: flushing framed transport
2023-10-22T08:09:41.143564Z TRACE tokio_util::codec::framed_impl: writing; remaining=9
2023-10-22T08:09:41.143628Z TRACE tokio_util::codec::framed_impl: framed transport flushed
2023-10-22T08:09:45.756536Z TRACE freeswitch_esl::io: decode
2023-10-22T08:09:45.756613Z TRACE freeswitch_esl::io: get_header_end:=>b""
Suspect somewhere it is getting confused the the premature disconnection and hanging.
Hi @brianmay
Thank you for trying out this crate.
There was a problem with how the library was designed. It was only accepting a second connection after the first one was successfully established with FreeSWITCH.
To fix this, I have made some breaking changes in the crate to allow multiple connections.
You can check the relevant commit for the breaking change here: here
PR link for all changes
Let me know if you find any issues.
Some background:
I currently have a Freeswitch server running a custom Python script using the mod_python plugin that will query the phone number in my phone_db database, and announce it to my IOT system robotica_rust.
But I wanted to port this to Nixos. However, I quickly noticed that the nixos freeswitch package does not have mod_python. So I tried to fix this myself, but found that mod_python is broken, and won't build even with Python 3.9, the oldest version in Nixos due to use of legacy Python APIs. I think noticed that there are a number of python specific bugs open in freeswitch, and nothing seems to be happening fast to resolve them.
So I went looking for alternatives, and found mod_event_socket
. It makes sense for me to write this daemon in Rust, because my IOT libraries are already in Rust. At this point I found this project.
Thank you for this crate!
And I don't mind breaking changes. Much better then the alternative, finding that the project is dead.
Which reminds me, that phone_db which I project - which I mentioned above - currently depends on a dead and suspect LDAP library, I really should fix that.
Back on topic: After testing this fix, the server now accepts new connections when the connection is prematurely closed. But I think the connection is still getting stuck, and the server thread is still waiting on the dead connection.
Probably already aware, but some of these unwraps()
need fixing. Crashed a server just by pushing enter a lot of times.
Oct 23 12:03:34 canidae freeswitch[1422114]: The application panicked (crashed).
Oct 23 12:03:34 canidae freeswitch[1422114]: Message: called `Option::unwrap()` on a `None` value
Oct 23 12:03:34 canidae freeswitch[1422114]: Location: /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-vendor-cargo-deps/94068d81da238b117422c7d912d9d145b0c37151009a84e7d60ebbaaac4b2735/freeswitch-esl-0.1.0/src/connection.rs:183
Oct 23 12:03:34 canidae freeswitch[1422114]: Backtrace omitted.
Oct 23 12:03:34 canidae freeswitch[1422114]: Run with RUST_BACKTRACE=1 environment variable to display it.
Oct 23 12:03:34 canidae freeswitch[1422114]: Run with RUST_BACKTRACE=full to include source snippets.
I think normally a panic in a thread won't cause the application to fail, but this is self-inflected :-) - I set things up to do so.
If I connect manually to outbound connection it does the correct thing:
Then on my next connection attempt, the server hangs and fails to respond:
I haven't yet had a chance to debug this in more detail.