gen_server not unregistering [20.1]

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

gen_server not unregistering [20.1]

Heinrich Venter-3
Hi all

I have been experiencing the strangest thing.

I am using an application (gen_rpc) that internally uses a gen_server to manage a gen_tcp outgoing socket.

On closing of the socket form the server side, the message {tcp_closed, Socket} is received in the handle_info. This handle_info returns {stop, normal, State}
BUT
The gen_server does not actually terminate. It does not call terminate and the PID remains registered locally. It actually keeps on processing messages which leads to badtcp reponses when it tires to send on the failed socket.

Has any one seen something remotely like this, or have any suggestions of how to proceed?

Links




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_server not unregistering [20.1]

Brujo Benavides-3
Not sure if this will help at all, but try trapping exits in that gen_server (i.e. process_flag(trap_exit, true).) since terminate might not be evaluated unless you’re trapping exits. Ref: http://erlang.org/doc/man/gen_server.html#Module:terminate-2

Good luck!

On 7 Mar 2018, at 09:48, Heinrich Venter <[hidden email]> wrote:

Hi all

I have been experiencing the strangest thing.

I am using an application (gen_rpc) that internally uses a gen_server to manage a gen_tcp outgoing socket.

On closing of the socket form the server side, the message {tcp_closed, Socket} is received in the handle_info. This handle_info returns {stop, normal, State}
BUT
The gen_server does not actually terminate. It does not call terminate and the PID remains registered locally. It actually keeps on processing messages which leads to badtcp reponses when it tires to send on the failed socket.

Has any one seen something remotely like this, or have any suggestions of how to proceed?

Links



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_server not unregistering [20.1]

Heinrich Venter-3
Thaks for the suggestion.

The gen_server already trap exits.

The instance I am using runs on R20.1. The instance it is communicating with runs on R19. That instance does not show the same behavior even though it uses the same code base for gen_rpc. 
I am worried that it is some strangeness in R20 that I am not aware of.


On Wed, Mar 7, 2018 at 2:52 PM, Brujo Benavides <[hidden email]> wrote:
Not sure if this will help at all, but try trapping exits in that gen_server (i.e. process_flag(trap_exit, true).) since terminate might not be evaluated unless you’re trapping exits. Ref: http://erlang.org/doc/man/gen_server.html#Module:terminate-2

Good luck!

On 7 Mar 2018, at 09:48, Heinrich Venter <[hidden email]> wrote:

Hi all

I have been experiencing the strangest thing.

I am using an application (gen_rpc) that internally uses a gen_server to manage a gen_tcp outgoing socket.

On closing of the socket form the server side, the message {tcp_closed, Socket} is received in the handle_info. This handle_info returns {stop, normal, State}
BUT
The gen_server does not actually terminate. It does not call terminate and the PID remains registered locally. It actually keeps on processing messages which leads to badtcp reponses when it tires to send on the failed socket.

Has any one seen something remotely like this, or have any suggestions of how to proceed?

Links



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions