------------------------------------------------------ SwiftMQ developers mailing list * http://www.swiftmq.com To unsubscribe from this list, send an eMail to [EMAIL PROTECTED] and write in the body of your message: UNSUBSCRIBE developers <your-email-address> Archive: http://www.mail-archive.com/developers@mail.iit.de/
In our project, it is crucial that all messages created by a client are delivered to a durable subscriber "once and only once", which isn't really difficult. The problem is that there is the possibility of : a) a "burst" of messages, let's say 100 or more per second which I think is too much for SMQ to handle b) a system failure while a message is being sent. This should not affect the message and it should be redelivered ("once and only once") as soon as the system is functional again. For finding a solution to a), I thought about either having multiple threads doing a publish() at the same time since, to my understanding, publish() does not do some sort of internal queueing and you have to wait till the function returns. I wonder however if multiple publishes from the same connection are possible with SMQ and if one instance of the Session and Connection object will be enough or if every thread needs their own Session and Connection. For b), even though SMQ claims to be transaction oriented, I don't think there is any buffering done to e.g. the harddisk while a call to publish() is running. This means that I have to implement this myself, which isn't really a problem, but I would like to be in control of the transaction then, especially of the ACK when a message was delivered successfully. This would be the point where I could delete a temp-file version of the message that was created before calling publish(). The question is, how do I know that a message transaction succeeded ? ( I *do* use the commit() already). Of course, a) and b) are connected to each other in a way that if a message burst occurs, I really NEED multiple threads to: make a copy of the message and write it to the harddisk, call publish() and wait until it returns and then delete the message's temp-file. If you see any other (software) possibilities to make the message delivery 100% reliable, please let me know ;) S. Zwedler
