when you call session = switch_core_session_locate(uuid);
if session is not NULL you MUST switch_core_session_rwunlock(session) before
you exit your function.
I have already pointed out 2 times now that you should not try to
session_locate the session, you should be using the data for the event for
this, and dup the event and hand the info to a backend thread over a fifo
queue?
On Mon, Feb 2, 2009 at 6:02 AM, Apostolos Pantsiopoulos <r...@kinetix.gr>wrote:
> Anthony,
>
> I need your help in clarifying something.
>
> I my module load function I am using this to bind a handler to a specific
> event (channel create) :
>
> if (switch_event_bind(modname, SWITCH_EVENT_CHANNEL_CREATE,
> SWITCH_EVENT_SUBCLASS_ANY, my_on_create_handler, NULL) !=
> SWITCH_STATUS_SUCCESS) {
> switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_ERROR,
> "Couldn't bind!\n");
> return SWITCH_STATUS_GENERR;
> }
>
> Then in my my_on_create_handler routine I have :
>
> static void my_on_create_handler(switch_event_t *event) {
>
> char* uuid = switch_event_get_header(event, "Unique-ID");
>
> switch_core_session_t *session;
>
> session = switch_core_session_locate(uuid);
> }
>
> this is only for test purposes. My handler does nothing else than creating
> a pointer to the session that
> triggered the event. Everything compiles just fine. When I am running
> freeswitch everything goes
> as expected (my handling routine is called and a session is indeed returned
> on my local session variable)
> except from one thing : I can see doing a "ps -eLf" that the session
> threads of my call get stuck and never get terminated.
>
> I can also tell that they are stuck by that error message in my console :
>
> switch_core_session_hupall() Giving up with 42 sessions remaining
>
> which makes sense since I initiated 21 bridged calls.
>
> Is the reference (pointer) to the session the cause of all these? Does FS
> considers that
> since there are still references to a session the session should not be
> terminated? If yes,
> how can I destroy this reference (after I have used it)?
>
>
> Anthony Minessale wrote:
>
> No problem, I have the advantage That I have implemented this technique all
> over the place ;)
> Your event handler is the recipient end of that same algorithm.
>
> In fact the events are a very good thing to pass into queues.
>
> You could clone the event and insert the clone into the queue and when you
> pop it from the
> backend thread you can just destroy it there then.
>
>
>
> On Fri, Jan 30, 2009 at 8:27 AM, Apostolos Pantsiopoulos
> <r...@kinetix.gr>wrote:
>
>> Wow. I didn't expect so much detailing :)
>>
>> Thanks for the idea.
>>
>> My implementation is different though, but yours seems to be better.
>>
>> I will conclude what I started doing now and get back to you with the
>> results.
>>
>> If something is wrong against my implementation I will try doing it your
>> way.
>>
>> Thanks again!
>>
>> Anthony Minessale wrote:
>>
>> use a queue object to send the data in a dynamic struct to the other
>> thread.
>>
>> 1) create a global queue.
>> 2) create a struct with all the info you need to send.
>>
>> on the event handler.
>>
>> 1) malloc a new struct of that type.
>> 2) memset it to all 0.
>> 3) populate the struct.
>> 4) write the data into the queue.
>>
>> launch a thread at startup that does a blocking wait on the same queue
>>
>> 1) pop the void pointer off the queue.
>> 2) cast it into your struct.
>> 3) extract the data from the struct and send it over radius.
>> 4) destroy the struct with free and loop.
>>
>>
>> On Fri, Jan 30, 2009 at 5:14 AM, Apostolos Pantsiopoulos <r...@kinetix.gr
>> > wrote:
>>
>>> Hi,
>>>
>>> I am tweaking the mod_radius_cdr module to archive the behavior
>>> that most NASes have (i.e. accounting packets are sent in a separate
>>> thread so that the submission does not interfere with the execution of
>>> the call). While doing that, however, I bumped into another behavior of
>>> the module that I think is not desirable (at least by me) :
>>>
>>> While on a bridge, the module sends one acct start packet at the
>>> beginning of the originating
>>> leg (on_routing event handler) and two acct stop packets at the end of
>>> each leg
>>> (inbound and outbound). My opinion is that it should send one accounting
>>> start
>>> packet at the beginning of each call leg (inbound, outbound) resulting
>>> to a total
>>> number of two acct start packets. It is generally accepted that acct
>>> start/stop packets
>>> come in pairs so that billing applications can handle them accordingly.
>>>
>>> Some NAS's radius radius implementations have some other
>>> configuration modes
>>> like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco
>>> NAS
>>> sends only an accounting start/stop pair at the end of a final dialpeer
>>> attempt (and suppresses
>>> all the previous failed dialpeer attempts) thus resulting to less
>>> network traffic. Other
>>> NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a
>>> start/stop
>>> pair for each end to end call, depending on the configuration. Opensips
>>> follows
>>> the star/stop pair by call leg paradigm. No matter what the
>>> implementation, all of them
>>> always send a acct start/stop pair. This is a common thing. And all the
>>> billing platforms
>>> can deal only with paired start/stops.
>>>
>>> The current module behavior (one start two stops) can complicate
>>> things since the
>>> radius server would not know how to match the second stop packet with
>>> its equivalent start.
>>>
>>> Before I get the infamous answer "pathes welcomed" I would like to
>>> state that I am
>>> already involved in changing this behavior (through a patch). So my real
>>> question is this :
>>>
>>> I noticed that the module uses the switch_core_add_state_handler
>>> function to register
>>> its handler table :
>>>
>>> switch_core_add_state_handler(&state_handlers);
>>>
>>> So the on_routing ( or the on_execute) event happens only when the
>>> inbound call is started.
>>> When the outbound call is initiated no handler is available to hook up a
>>> function and
>>> send the proper acct start packet.
>>>
>>> Should the module register its handlers using the
>>> switch_channel_add_state_handler() function instead?
>>> And if yes, how could the module pass the channel as a parameter to the
>>> function since channels
>>> are created and destroyed dynamically (and the module when initialized
>>> does not have that info).
>>>
>>> I would greatly appreciate your help in pinpointing a proper way to
>>> call my event handling
>>> routines on a per call leg basis.
>>>
>>>
>>> --
>>> -------------------------------------------
>>> Apostolos Pantsiopoulos
>>> Kinetix Tele.com R & D
>>> email: r...@kinetix.gr
>>> -------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev@lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>>
>> AIM: anthm
>> MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
>> iax:gu...@conference.freeswitch.org/888
>> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org>
>> pstn:213-799-1400
>>
>> ------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing
>> listfreeswitch-...@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: r...@kinetix.gr
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev@lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
> iax:gu...@conference.freeswitch.org/888
> googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing
> listfreeswitch-...@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: r...@kinetix.gr
> -------------------------------------------
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:anthony_miness...@hotmail.com <msn%3aanthony_miness...@hotmail.com>
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<paypal%3aanthony.miness...@gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org <sip%3a...@conference.freeswitch.org>
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org<googletalk%3aconf%2b...@conference.freeswitch.org>
pstn:213-799-1400
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
