I think you do not understand what the effect of multi-threading has on static variables.

The unique IDs you are seeing are whatever the unique ID happened to be at the time the message was formatted for output. This is not necessarily the unique ID of the call that wanted to generate that log message as the static variable gets stomped on repeatedly by other threads.

You may want to know more about the concept of "race condition".

Dennis Buteyn
Xorcom Ltd

On 07/03/2018 03:54 PM, Balraj Singh wrote:
Sorry if I confused you, but I tested my code with concurrent calls happening at the same time and I'm able to get the UniqueId ( associated with a call) in every log line ( associated with that call )  for every call that was happening.

What I meant is, I've tested my approach with multiple calls and the unique id that is generated for each call are printed in the logs associated to that call.
So what do you think?

On Tue, Jul 3, 2018 at 5:49 PM Richard Mudgett <[email protected] <mailto:[email protected]>> wrote:



    On Tue, Jul 3, 2018 at 3:49 AM, Balraj Singh
    <[email protected] <mailto:[email protected]>>
    wrote:

        Thank you for your suggestion, We initially considered only
        using Call-id as unique id to grep the logs. But there were
        several reason for us not to:
        1) This Call-Identifier variable gets reset after we shut down
        asterisk and starts again from C-00000001.
        2) We're using CDR and unique-id by default as it is saved in
        CDR table and so we can take unique id from cdr to grep the logs.
        3) We needed unique-id to be in every log line e.g. executing
        Dialplan applications, sip debug logs, rtp streaming logs,
        etc. So to achieve this customisation, we had to modify
        logger.c file to easily grep the logs related to a call using
        that id, so that we can trace / debug it if some error occurs.

        Hence, we had to re-implement this functionality to suffice
        our needs. So, please kindly can you re-verify our approach to
        this.

        On Tue, Jul 3, 2018 at 2:32 AM Richard Mudgett
        <[email protected] <mailto:[email protected]>> wrote:

            You are trying to reimplement callid[1] which has been in
            Asterisk since v11. Callid
            is accessible from dialplan using CHANNEL(callid)[2]. 
            Accessibility from the
            dialplan has been in Asterisk 13 since 13.15.0 and in
            Asterisk 15 since it was first
            released. The callid is created when the incoming channel
            goes into dialplan not
            when it is bridged.

            As to the approach.  You do know that Asterisk is
            multi-threaded and can handle
            more than one call at a time?  Using a simple global
            variable sets the uniqueid
            for ALL log messages regardless of whether that message
            has anything to do with
            the channel of that uniqueid.


    Nothing has changed.  It is not a good approach. Your code assumes
    that there is one
    and only one call happening at a time.  You have to associate the
    uniqueid with EVERY
    log message when the log message is posted just like callid does. 
    This was why the callid
    patch was so large.

    Richard

-- _____________________________________________________________________
    -- Bandwidth and Colocation Provided by http://www.api-digital.com --

    asterisk-dev mailing list
    To UNSUBSCRIBE or update options visit:
    http://lists.digium.com/mailman/listinfo/asterisk-dev




-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to