No, you're wrong, AGAIN.

READ the email:

"This then leaves the message in an ACK/ state and never gets updated to
sent or undelivered"

How could those messages be there if he restarted the box? The queue would
be empty.

_and_

"Also does the Kannel status page EG: DLR: 1247 queued, using internal
storage"

That's NOT the store size, but the DLR size.

I wont spend any more time on this. I think he have a clearer picture now
about what's happening.

Regards,

Alex

2010/9/13 Nikos Balkanas <[email protected]>

> Yes I did. But apparently you didn't. And yes received DLRs are stored in
> file storage until received by smsbox. He asks 2 things:
>
> 1) Why 10% of his DLRs are mismatched. Answer: Because he uses internal DLR
> storage and restarts bearerbox frequently.
> 2) Why he has 1000+ SMS in storage status in HTTP admin, and if that is due
> to missed DLRs. Answer: No, because they are discarded and deleted from
> storage when mismatched even if his smsbox is down.
>
>
> BR,
> Nikos
> ----- Original Message ----- From: Alejandro Guerrieri
> To: Nikos Balkanas
> Cc: Jarratt Ingram ; [email protected]
> Sent: Monday, September 13, 2010 2:35 PM
>
> Subject: Re: DLR and Message Type question
>
>
> ???
>
>
> Did you really read the email? He's having issues with DLR's not being
> recognized. What does that have to do with file storage? You're complicating
> things.
>
>
> For what concerns here, DLR's are NOT stored in file storage.
>
>
> From Kannel's perspective, DLR's are a completely different animal than
> other messages (though they're very similar to regular MO's from an SMPP
> perspective).
>
>
> Regards,
>
>
> Alex
>
>
> 2010/9/13 Nikos Balkanas <[email protected]>
>
> Yes, I understand that he is speaking of DLRs. But he is talking about DLRs
> placed in file storage (spool or file) like any other MO. And they will
> remain there as long as smsbox is down. I don't care what happens with
> dlr_entries in memory, that's not what the user asked. He asked why his file
> storage was growing so large.
>
> DB storage has many advantages, however, it degrades performance
> significantly.
>
>
> BR,
> Nikos
> ----- Original Message ----- From: Alejandro Guerrieri
> To: Nikos Balkanas
> Cc: Jarratt Ingram ; [email protected]
>
> Sent: Monday, September 13, 2010 1:59 PM
>
> Subject: Re: DLR and Message Type question
>
>
> No, he's clearly speaking of DLR's.
>
>
> The statement "Unmatched DLRs are discarded and erased form storage." it's
> completely wrong. They're NOT erased from storage. It doesn't matter the
> storage method, unmatched DLR's will be held in memory indefinitely, until
> you restart the service (and lose _all_ pending DLR's disregarding the age).
>
>
> "You can examine storage contents from the HTTP admin." is unrelated. His
> mail clearly states "I am experiencing some small issues with the DLR
> mechanism in my current Kannel configuration". What does that have to do
> with MO storage?? Read his original email again, he didn't even mention
> "MO".
>
>
> Having a DB storage will give him the advantage of being able to delete
> older entries without losing the newer ones.
>
>
> Regards,
>
>
> Alex
> 2010/9/13 Nikos Balkanas <[email protected]>
>
> Alex,
>
> We are not talking about db storage, here. We are talking about internal
> storage and spool or file storage used for all MOs. The one seen from HTTP
> admin.
>
> BR,
> Nikos
> ----- Original Message ----- From: Alejandro Guerrieri
> To: Nikos Balkanas
> Cc: Jarratt Ingram ; [email protected]
> Sent: Monday, September 13, 2010 1:21 PM
> Subject: Re: DLR and Message Type question
>
>
>
> "Unmatched DLRs are discarded and erased from storage"
>
>
> How so? You need to do that _manually_ I'm afraid. If a DLR arrives and
> it's not found, it means that it's NOT on the DB, so there's nothing to
> delete. If a DLR doesn't arrive, the original entry will remain there
> forever. You need to run a manual query to delete them using some criteria
> (usually "older than N days").
>
>
> Kannel only deletes matched "final" DLR's ("final" varying according to
> your dlr-mask setting of course).
>
>
> Regards,
>
>
> Alex
>
>
> 2010/9/13 Nikos Balkanas <[email protected]>
>
> Hi,
>
> No, do not mess up with msg-id-type or you will loose 100% of your DLRs.
>
> Unmatched DLRs are discarded and erased form storage. You can examine
> storage contents from the HTTP admin.
>
> Post your configuration and detailed stsrtup bb logs.
>
> BR,
> Nikos
> ----- Original Message ----- From: "Jarratt Ingram" <
> [email protected]>
> To: <[email protected]>
> Sent: Monday, September 13, 2010 12:37 PM
> Subject: DLR and Message Type question
>
>
>
>
> Good Morning All,
>
> I am experiencing some small issues with the DLR mechanism in my current
> Kannel configuration,
>
> RPM version of Kannel on Fedora 13 64bit
> DLR is currently set to internal storage,
> msg-id-type is default as it is not explicitly set.
>
> I have two SMPP connections to a provider both have the same smsc-id and
> are both setup with transceiver-mode = 1
> The DLR processing works for 90% of the time and every now and again i get
> the following in the logs
>
> 2010-09-13 11:11:13 [7277] [6] ERROR: SMPP[3]: got DLR but could not find
> message or was not interested in it id<27/00/4d599338/1127829048804>
> dst<27829048804>, type<2>
>
> This then leaves the message in an ACK/ state and never gets updated to
> sent or undelivered, based on the message above does this mean i should
> rather set the msg-id-type = 0x02 ? i am assuming that Kannel is able to
> correctly determine the DLR's 90% of the time and gets stuck every now and
> again ?
>
> Also does the Kannel status page EG: DLR: 1247 queued, using internal
> storage
> directly relate to  this i.e id a DLR is not found does the DLR queue get
> reduced by 1 ? As i have had over 1k DLR's pending for a few days now
>
> Any help would be appreciated,
>
> Kind regards
> Jarratt
>

Reply via email to