The session runs in it's own thread when you use session_locate to find a
pointer to the session you stop that session from exiting until you release
it from the same thread you called session_locate from.
So the session could have just done the radius connection itself in it's
perfectly good existing thread.
now you are detaining the session and creating a new thread thus wasting the
session thread.
instead of an event handler you may want to use a state handler so you can
run the stuff in the session thread.
On Mon, Feb 2, 2009 at 11:18 AM, r...@kinetix.gr <r...@kinetix.gr> wrote:
> Correct me if I am wrong, but wouldn't a fifo queue (along with its
> processing thread)
> process the radius packets to be sent in a sequential manner? And If a
> packet submission
> got stuck for retries*timeout secs wouldn't that affect the packets that
> wait in the queue?
> What I am trying to implement is different. I want the transmission of the
> radius packets
> to be independent of any sequence or order... That's why I am creating a
> new thread
> for each one, then detaching the thread, stalling the session with a lock
> until I get all the
> info I want from it and in the end notifying the calling function that it
> is free to continue (even to destroy the session).
> Also, does the event message contain all the possible info for a
> session/channel/profile of a
> call leg?
>
> Anthony Minessale wrote:
>
> 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
> listfreeswitch-...@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> _______________________________________________
> 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
