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