What kind of performance can I expect from JMQ 1.1 on an Ultra 5?

We're getting 16-18 messages/sec through it when JMQ is running on an Ultra 5. I hope that we're doing something wrong, and that it's actually more scalable than that. Do you have anyscalability numbers? Example code?
[241 byte] By [christenscreen] at [2007-11-25 8:06:29]
# 1

According to the JMS spec, "PERSISTENT delivery mode instructs the JMS

provider to take extra care to insure that the message is not lost in

transit due to a JMS provider failure".

In other words, PERSISTENT message must be delivered "once and only

once", while NON_PERSISTENT message may be delivered "at most once".

In JMQ, this translates to following extra overheads -

1. The 'irouter' saves every PERSISTENT message on the disk.

2. Additional handshaking is required to remove these messages from

the disk when the subscriber acknowledges the message delivery.

This obviously has a huge impact on performance.

Here are some pros and cons of using PERSISTENT delivery mode -

1. The NON_PERSISTENT "at most once" delivery mode does NOT mean that

JMQ will occasionally drop such messages. It also does NOT mean

that these messages will have lower priority in any sense. All it

means is that, if for some reason irouter process is restarted

(e.g. after a crash), the PERSISTENT messages can be redelivered.

2. Note that the message redelivery after irouter restart is subject

to the subscription contract. For example, if the application uses

non-durable Topic subscription there is no point in using

PERSISTENT delivery. (because by definition non-durable topic

subscriptions get only the messages sent after the subscription is

created, and provider failure always causes all subscribers to

reconnect and start from scratch...)

3. So in other words - PERSISTENT delivery mode is useful only if you

are using either point-to-point (Queue) model, or durable Topic

subscriptions.

4. Even in case of point-to-point model, if occasional message loss

due to a provider failure is acceptable for a specific

application, it is better to use NON_PERSISTENT mode.

5. Finally PERSISTENT delivery mode is usually used in conjunction

with either CLIENT_ACKNOWLEDGE or transacted sessions (on the

receiver side) to insure that the message gets removed

from the disk only after the subscriber has processed it...

christenscreen at 2007-7-1 13:56:29 > top of Java-index,Application & Integration Servers,Sun Java System Message Queue...