independent of question bellow, I fixed this in the SVN.

Alex

Am 18.02.2013 um 11:32 schrieb Alexander Malysh <[email protected]>:

> I just want that validity & deferred is the absolute timestamp and not 
> dependent from
> any message value.
> 
> As to the mentioned code. I just don't understand why sqlbox first fetch 
> message from db, sends it
> ro bearerbox and then insert it back to DB??
> 
>     while (sqlbox_status == SQL_RUNNING && boxc->alive) {
>         if ((msg = gw_sql_fetch_msg()) != NULL) {
>             if (charset_processing(msg) == -1) {
>                 error(0, "Could not charset process message, dropping it!");
>                 msg_destroy(msg);
>                 continue;
>             }
>             if (global_sender != NULL && (msg->sms.sender == NULL || 
> octstr_len(msg->sms.sender) == 0)) {
>                 msg->sms.sender = octstr_duplicate(global_sender);
>             }
>             /* convert validity and deferred to unix timestamp */
>             if (msg->sms.validity != SMS_PARAM_UNDEFINED)
>                 msg->sms.validity = time(NULL) + msg->sms.validity * 60;
>             if (msg->sms.deferred != SMS_PARAM_UNDEFINED)
>                 msg->sms.deferred = time(NULL) + msg->sms.deferred * 60;
>             send_msg(boxc->bearerbox_connection, boxc, msg);
> 
>       ^^^^^ here is correct that we send unix timestamp to bearerbox, because 
> bearerbox expects seconds now
> 
>             gw_sql_save_msg(msg, octstr_imm("MT"));
> 
>       ^^^^^^^^^ why do we save message again, that we just fetched from DB?
> 
>         }
>         else {
>             gwthread_sleep(SLEEP_BETWEEN_SELECTS);
>         }
> 
> 
> Alex
> 
> Am 18.02.2013 um 10:54 schrieb Rene Kluwen <[email protected]>:
> 
>> Not sure why you want to go through all this trouble.
>> But the function sql_to_bearerbox does not do still what you want.
>>  
>> Here goes:
>>  
>>             /* convert validity and deferred to unix timestamp */
>>             if (msg->sms.validity != SMS_PARAM_UNDEFINED)
>>                 msg->sms.validity = time(NULL) + msg->sms.validity * 60;
>>             if (msg->sms.deferred != SMS_PARAM_UNDEFINED)
>>                 msg->sms.deferred = time(NULL) + msg->sms.deferred * 60;
>>             send_msg(boxc->bearerbox_connection, boxc, msg);                 
>>           /* message is sent with validity in absolute seconds */
>>             gw_sql_save_msg(msg, octstr_imm("MT"));                          
>>                     /* message is saved in sent_sms in absolute seconds */
>>  
>> From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander 
>> Malysh
>> Sent: maandag 18 februari 2013 10:02
>> To: Rene Kluwen
>> Cc: [email protected]
>> Subject: Re: Validity perdiod
>>  
>> Hi,
>>  
>> just found a typo in my patch and changed it to:
>>  
>>             msg_escaped = msg_duplicate(msg);
>>             /* convert validity & deferred to minutes */
>>             if (msg_escaped->sms.validity != SMS_PARAM_UNDEFINED)
>>                 msg_escaped->sms.validity = (msg_escaped->sms.validity - 
>> time(NULL))/60;
>>             if (msg_escaped->sms.deferred != SMS_PARAM_UNDEFINED)
>>                 msg_escaped->sms.deferred = (msg_escaped->sms.deferred - 
>> time(NULL))/60;
>>             gw_sql_save_msg(msg_escaped, octstr_imm("MT"));
>>  
>> This should fix this issue.
>>  
>> Alex
>>  
>> Am 18.02.2013 um 09:57 schrieb Rene Kluwen <[email protected]>:
>> 
>> 
>> In sqlbox, two different things happen.
>>  
>> 1.       Select rows from send_sms and send them to bearerbox (with validity 
>> in minutes)
>> 2.       Relay rows from smsbox to bearerbox and store them in sent_sms on 
>> the fly. These messages have been processed by smsbox already and should not 
>> be reprocessed.
>>  
>> I am not sure what exactly you did because I don’t have time to look at the 
>> code now. But something is going very wrong here. Even without using sqlbox 
>> we are getting invalid validity_period fields in smsc_smpp.
>>  
>> On a side note, I see now that opensmppbox never sends a validity field to 
>> its connected entity, now I look at it. But that’s a different story.
>>  
>> == Rene
>>  
>> From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander 
>> Malysh
>> Sent: maandag 18 februari 2013 9:29
>> To: Rene Kluwen
>> Cc: [email protected]
>> Subject: Re: Validity perdiod
>>  
>> Hi Rene,
>>  
>> I converted validity & deferred to be unix timestamp internally, they were 
>> in minutes before.
>> Due to the fact that I didn't know how sqlbox works, I assumed that validity 
>> & deferred in the
>> sqlbox tables also stored in minutes therefore this conversion:
>>             if validity set then (now - unix timestamp) / 60 -> minutes
>>  
>> the counter part is when selecting values from DB and sending to bearerbox:
>>  
>>             /* convert validity and deferred to unix timestamp */
>>             if (msg->sms.validity != SMS_PARAM_UNDEFINED)
>>                 msg->sms.validity = time(NULL) + msg->sms.validity * 60;
>>             if (msg->sms.deferred != SMS_PARAM_UNDEFINED)
>>                 msg->sms.deferred = time(NULL) + msg->sms.deferred * 60;
>>  
>> Alex
>>  
>> Am 16.02.2013 um 15:36 schrieb Rene Kluwen <[email protected]>:
>> 
>> 
>> 
>> Also: in sqlbox.c (function smsbox_to_bearerbox()):
>>  
>>                /* convert validity & deferred to minutes */
>>                 if (msg->sms.validity != SMS_PARAM_UNDEFINED)
>>                     msg->sms.validity = (msg->sms.validity - time(NULL))/60;
>>                 if (msg->sms.deferred != SMS_PARAM_UNDEFINED)
>>                     msg->sms.deferred = (msg->sms.deferred - time(NULL))/60;
>>  
>> Isn’t this field encoded twice now? Once in smsbox and another time in 
>> sqlbox?
>>  
>> Alexander, you made this change. Please shed some light.
>>  
>> From: [email protected] [mailto:[email protected]] On Behalf 
>> Of Rene Kluwen
>> Sent: vrijdag 15 februari 2013 15:16
>> To: [email protected]
>> Subject: Validity perdiod
>>  
>> I came across an issue since svn version 4956 of smsbox.c, using smpp.
>>  
>> The logs show the following:
>>  
>> 2013-02-15 14:52:45 [3144] [7] DEBUG:   validity_period: "711110215159000+"
>>  
>> This was this afternoon at 14:52. The validity field of the sendsms 
>> interface was not set.
>>  
>> How do I interpret this as “YYMMDDhhmmsstnnp”?
>>  
>> One of my clients needed to downgrade because of this issue.
>>  
>> == Rene
> 

Reply via email to