Hmm... If this happens during a part of a multipart message, it gets really complicated... A big message is breaked up in parts on the fly, so if one part throws errors it would be extremely difficult to identify it and retry just that. SMSLib will retry the transmition of the entire message again.
The thing that the markMessage() is not called is what worries me! I'll try to reproduce it here and get back to you. On Sep 8, 6:58 am, Elias <[email protected]> wrote: > The end result of the problem is that sometimes the markMessage() > method of the interface is not called, so the message stays marked "in > queue" and the transmission never competes. I am thinking of extending > the getMessagesToSend() method to look in the database "queue" and re- > process the messages that stay there for a long time (60 minutes or > so). > Is there a way to check if a message exists already in the outbound > message queue of the server, just in case it has not been processed > for some other reason? > > On 4 Σεπτ, 22:43, Thanasis <[email protected]> wrote: > > > > > I think this has been reported before. The MC35 is reported to have > > some peculiarities... > > Hopefully, a friend working with an MC35 may answer better. > > > On Sep 4, 8:12 pm, Elias <[email protected]> wrote: --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SMSLib for Java User Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/smslib?hl=en -~----------~----~----~----~------~----~------~--~---
