[asterisk-dev] Regarding Unique Id In Logs

[Dennis Buteyn]

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 <rmudgett at digium.com 
> <mailto:rmudgett at digium.com>> wrote:
>
>
>
>     On Tue, Jul 3, 2018 at 3:49 AM, Balraj Singh
>     <balraj.singh at zemosolabs.com <mailto:balraj.singh at zemosolabs.com>>
>     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
>         <rmudgett at digium.com <mailto:rmudgett at digium.com>> 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
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20180703/24646b60/attachment.html>