> a) a "burst" of messages, let's say 100 or more per second which I think
> is too much for SMQ to handle
That should not a problem but it is dependent on the message size. If
you have small messages, disable the default message compression with
message.setBooleanProperty("JMS_SWIFTMQ_BC",false);
(Next version will have a size limit for compression)
> 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.
Yes.
> 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.
See below (transacted/non-transacted session).
> I wonder however if multiple publishes from the same
> connection are possible with SMQ
Sure.
> and if one instance of the Session and Connection object will be enough
> or if every thread needs their own
> Session and Connection.
One connection seems to be enough (but you can use multiple connections
if you want). A session inherits a transaction context (the session's
input/output streams are transacted) and is per JMS definition
*single-threaded*. Thus, you need a session for every different
publishing thread.
> 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).
When your session is transacted, you publish each message and somewhere
you do a commit. If that doesn't throw an exception, all messages of
this transaction are successful delivered to the message server. All
messages in a transaction are buffered at the client in memory and
delivered with the commit call at once. In a non-transacted session,
each message is wrapped in a single transaction. On a successful return
of publish(), the message is delivered and committed.
> 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.
Yes, if you must handle a backlog of messages at your client.
> If you see any other (software) possibilities to make the message
> delivery 100% reliable, please
> let me know ;)
Well, as I said, this is automatically the case. But if your client must
handle a backlog, you have to code the reliability for the *backlog* by
yourself.
--
Andreas Mueller, [EMAIL PROTECTED], IIT GmbH, Bremen/Germany, http://www.iit.de
SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com
------------------------------------------------------
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/