You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to add cache for incoming already splitted messages. This cache will contain correlation between a message segement reference_number + source_address + dest_address and a SMSC GW's messageId of a first found message segment.
This value will be then logged into a CDR.
This functionality demands extra processing and must be optional and turned off by default.
The text was updated successfully, but these errors were encountered:
checking of removeOldReferenceNumbers() at any segement may waste resources. I added some timer for periodically checking (check my fix)
your synch code at a new created object splitMessageData that means no synching between different concurrent invocations. I tried to refactor code (check my fix) to concantrate all updated in a single synchronised code segment
when stopping of SMSC GW we need to remove of MBean (check my fix)
What is till missed:
I have not tested, we need to make this step at a live server
the functionality must be optional and turned off by default, we need to add CLI / GUI for it
We may use of CLI templeate for enabling (if no objections)
smsc set cdr_splitted_message_id true
We need to update a manul for new CDR fields and a new CLI / GUI
should we have CLI / GUI for RemoveOlderThanXSeconds . Should we add it ?
I do not understand why we need SplitMessageCacheStruct class. If it is not needed, better to remove it.
We need to add cache for incoming already splitted messages. This cache will contain correlation between a message segement reference_number + source_address + dest_address and a SMSC GW's messageId of a first found message segment.
This value will be then logged into a CDR.
This functionality demands extra processing and must be optional and turned off by default.
The text was updated successfully, but these errors were encountered: