> 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/




Reply via email to