Hi. I am using the MC module of oserl to accept multiple connections from ESMEs. However, I get a problem with unbinding. When one of the ESMEs unbinds, the whole module goes down. Seems the unbind isn't killing just its session like it is supposed to. Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please note that gen_mc was written for testing purposes only. We wrote OSERL mainly to implement an ESME for MT based services.
You may take the current gen_mc as an example, but it is very likely that you will need to roll your own gen_mc to fit your particular needs.
In case you are using the code in the package, I would rather recommend you to fetch the latest code from the repository. It includes several important changes.
Best regards,
Quique
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aaah I see, that explains why the esme module seems more stable that the mc module.
However back to my issue, I realized the problem might be in the gen_mc_session module. Apparently finite state machines are used to handle connections to ESMEs.
Seems when two ESMEs connect, gen_mc_session uses the same instance of gen_fsm to handle the connections. So, when one ESME unbinds, the state of the FSM changes to "listen" yet the other ESME's state should be "open". This causes a conflict of stated and hence crushes the entire module.
Any ideas on how I can fix this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. I am using the MC module of oserl to accept multiple connections from ESMEs. However, I get a problem with unbinding. When one of the ESMEs unbinds, the whole module goes down. Seems the unbind isn't killing just its session like it is supposed to. Any ideas?
Hi,
Please note that gen_mc was written for testing purposes only. We wrote OSERL mainly to implement an ESME for MT based services.
You may take the current gen_mc as an example, but it is very likely that you will need to roll your own gen_mc to fit your particular needs.
In case you are using the code in the package, I would rather recommend you to fetch the latest code from the repository. It includes several important changes.
Best regards,
Quique
Aaah I see, that explains why the esme module seems more stable that the mc module.
However back to my issue, I realized the problem might be in the gen_mc_session module. Apparently finite state machines are used to handle connections to ESMEs.
Seems when two ESMEs connect, gen_mc_session uses the same instance of gen_fsm to handle the connections. So, when one ESME unbinds, the state of the FSM changes to "listen" yet the other ESME's state should be "open". This causes a conflict of stated and hence crushes the entire module.
Any ideas on how I can fix this?