Thank you Stipe. As my case used multiple connections, it does not seem a bug in kannel. I believe Alvaro's suggestion will be the solution for my case.
Regards, Bobby Bobby Richardson Manager - SIM Engineering O 650.810.8196 | M 310.894.0100 -----Original Message----- From: Stipe Tolj [mailto:st...@kannel.org] Sent: Wednesday, July 15, 2015 11:15 AM To: Bobby Richardson <bobby.richard...@jasper.com> Cc: users@kannel.org Subject: Re: Multiple SMPP objects overlapping Am 14.07.2015 22:11, schrieb Bobby Richardson: > Hello: > > My organization uses Kannel logs everyday and is experiencing a > technical challenge recently. > > For this issue, I searched through kannel.org and unfortunately could > not find any helpful solution. > > From attached, you may see 2 SMPP objects (first one is a complete > one; lines between 1 and 16 and the second one is just a partial) with > 2 different connection names (ie. SMPP[SMSC1_ATT_RSS] and > SMPP[SMSC2_ATT_RSS]) . > > Before the second SMPP object starts, I expected "SMPP PDU dump ends." > first and then "SMPP[SMSC2_ATT_RSS]: Got PDU:". "SMPP[SMSC2_ATT_RSS]: > Got PDU:" was placed in line 14 before the first SMPP object ends. > > Is this normal sequence? In many cases, I have seen "SMPP PDU dump > ends." as an indication of end of a SMPP. And then after this, another > SMPP may start with "SMPP[SMSC2_ATT_RSS]: Got PDU:". > > Do you have any suggestion for how to let Kannel log records one SMPP > object at a time without getting mixed? > > Is there any specific parameter in the Configuration file to control > this case? Hello Bobby, the log parts show that the "mixing" happens due to thread concurrency. Since every SMPP SMSC connection runs in it's own thread, there is no "guaranteed" order of thread execution and therefore also no "grantee" in that a particular SMPP PDU dump is "in-line complete" before any other vectorized in. So, is this mixing a feature or a bug? It's a feature actually, since we COULD use mutex locking to perform the SMPP PDU dump completely and then release the lock, but this would generate a high concurrency delay on the log file writing, and therefore also in the PDU processing itself. Alvaro suggested a way to avoid this, by using individual smsc group specific log-files. We DO have code branches in our internal trees that allow mutex locking, though we never used this in high IO scenarios. If you need any further assistance, please feel free to email me. -- Best Regards, Stipe ------------------------------------------------------------------- Kölner Landstrasse 419 40589 Düsseldorf, NRW, Germany Kannel Foundation tolj.org system architecture http://www.kannel.org/ http://www.tolj.org/ mailto:stolj_{at}_kannel.org mailto:st_{at}_tolj.org -------------------------------------------------------------------
