• -]-[

    -]-[ - 2004-05-26


    I am starting development using oserl-0.2.  I must say that I am quite impressed.

    There seems to be a slight issue with shutting down a gen_esme when it is part of a supervision tree.  It would seem that the socket is never closed.  This causes the socket on the SMSC side to terminate abnormally.  Not sure if I am missing something or not.

    Further, is there a way to display the raw incoming PDU content for debugging purposes?


    • Enrique Marcote Peńa

      Hi Heinrich,

      Firstable, the easy one :)

      Currently, there's no way to display incomming PDUs (I'll consider to add a debug mode for the next version). Anyway, you may try editing gen_esme_session.erl to do so. 

      Go to function handle_event/3 (event {input, BinaryPdu, Lapse, Index})

      handle_event({input, BinaryPdu, Lapse, Index}, StateName, StateData) ->
          Timestamp = now(),
          case catch operation:esme_unpack(BinaryPdu) of

      The term <code>BinaryPdu</code>is what you're looking for to display.  Add a  <tt>io:format</tt> or whatever you find appropriate.

      Regarding the shutdown issue, I can not give you an answer right now.  I just saw your message and didn't want to delay this first answer any more.  I'll try to test it myself and send you a post in the next few days.

      Let me also say that OSERL version 1.0 is to be released by the next week, 15th June is the deadline.  I'll test this issue before the new version gets released.

      Best regards,


    • Enrique Marcote Peńa

      Now I see,

      The shutdown problem you mention is indeed due to a inappropriate design of gen_esme.erl :$  That's why I decided to completely redefine it for version 1.0 (which should be available by the next week).

      Here are the details.

      gen_esme is implemented as a gen_server, but currently, it doesn't forward any of the gen_server callbacks up to the gen_esme callback module, hiding the underlying gen_server to upper layers.  Soon this decision turned out to be a bad idea. Why?

      Because several behaviors need to be implemented in the ESME callback module (usually implementing both, gen_esme and gen_server behaviors), if we want our ESME to carry an internal State and/or comply to the OTP design principles.

      Notice how, current gen_esme implementation, enforces to (re)implemented a gen_server (or any other behavior or custom server...) in the ESME callback module... again.

      You may refer to the code_lock_esme.erl example under doc/examples to see this problem in detail ( In this particular example, the gen_esme callback module implements also the gen_fsm behavior.

      Let me use the module code_lock_esme.erl to go back to the shutdown problem. To include this weird ESME in a supervision tree, and shutdown nicely, you'd need to move the work done by the stop function, to the terminate/3 callback ***of the FSM***.  The supervisor terminates the gen_fsm, which in turn must shutdown the gen_esme in an ordered manner.

      As I already said, this will be changed in the next version, where the gen_esme behavior will be some kind of an "extended gen_server", defining also the init/1, terminate/3, code_change/3, handle_call/3...callbacks.  Indeed, what the new implementation of gen_esme does, is forwarding gen_server callbacks up to the ESME callback module, thus no several behaviors are longer needed.  This is pretty much what I saw in the dispatcher contribution at

      Imminent 1.0 release includes:

      * gen_smsc and gen_smsc_session behaviors.
      * gen_connection completely redesigned.
      * gen_esme acts now also as an "extended gen_server". There's no need to implement several behaviors separately.
      * gen_esme_session changed to adopt the new design of gen_connection.

      In addition, resulting implementation is more elegant and compact.  So please, keep an eye on it.

      Best regards,


    • Enrique Marcote Peńa

      By the way, excuse my late responses.  I had forgotten to redirect posts to an email account.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks