[adrian.brock]

Hi,

First a qualification, I'm not a jbossmq author,
or at least I wasn't until a couple of weeks ago.
You might know the source better than me? :-)

Answers in line. Where I say I've fixed it, it means
for 3.0.4 due out this week I think?

Regards,
Adrian

> Hi all,
>
> After much consternation (and 2weeks of digging
> around), i found a few potential issues and hacked it
> and created a work-around.

Don't like work arounds :-(

>
> 1. There are a few clean-up issues when a subscriber
> disconnects (unsubscribes) its connection. If there
> are any unacknowledged messages the cleanup is
> defered and no one seems to take it up. (Authors
> please correct me if i am wrong).

True, I've fixed this.
If the client closes the session or the connection
drops, unacknowledged messages are now nacked
(negatively acknowledged).

This fixes two problems.
1) Cleanup of queues, the server can close the
queues because they are "emptied" by the nacks.
2) You don't have to restart the server to get
the messages redelivered.

> I created a hack for it by proactively (and
> aggressively ;) ) cleaning up the messages related to
> a particular client on unsubscribing.
> 2. I distributed the load on to 1 topic/stream (see
> my first post in this thread for problem description)
> so no selectors.

I've fixed the selector problem. And a problem
where you couldn't change the selector on a durable
subscritpion

> 3. I scaled down the QOS to drop old unconsumed
> messages but continue to "survive". The JMS server
> now no longer spills over to the disk, if it is
> overwhelmed by the input data, it starts dropping the
> oldest messages (this is trivially accomplished by
> commenting out the saveToStorage in MessageCache
> :)).

:-)
I'm working on a proper solution which will be
configurable on the cache MBean.
1) Drop non-persistent messages when memory is tight.
2) Scan the cache for messages that have passed their
time to live (ttl) and drop them rather than waiting
for the client to perform to test.
3) Drop persistent messages as they are sent to the
client if it is not transactional, client acknowledge
or where a connection failure would drop the messages
anyway, i.e. topics and temporary queues.

Anyone got any other ideas?
Maybe maximum queue depth or a maximum undelivered
message age?

I doubt I will have this properly tested
for it into to make it into 3.0.4 :-(

> 4. I modified a synchronization lock in
> org.jboss.mq.server.ClientConsumer.java (version
> 1.11.2.1) method removeRemovedSubscription line 337
> (take line numbers with a pinch of salt because of
> loggers that i may have inserted) to synchronize onf
> removedSubscriptions instead of subscriptions
> (seemed more reasonable to me ;).

The subscriptions->removedSubscriptions is
synchronized on subscriptions.
Not sure what this fixes?

> 5. I volume tested this fix for 100 messages/second
> and 100 listener clients for 12 hours and the memory
> footprint of the JMS Provider stayed below 40MB, and
> CPU utilization @7% (on a dual 1.2GHz windows box)

I haven't done any throughput testing yet.

I have been looking at problems with tight
memory constraints causing leaks in the cache.
Which is why I started looking at jbossmq two weeks
ago :-)

I've also fixed org.jboss.mq.server.MessageReference
so it uses a static logger rather than
one logger per message reference!

Conversely, the logger in BasicQueue shouldn't be
static because it contains the queue name. Everything
was being logged against DLQ :-)

>
> This was an acceptable workaround for me, and may not
> work for everyone.
>
> There is a another thread
> http://www.jboss.org/forums/thread.jsp?forum=48&thread
> 20461
> which seems to address similar issue, and someone
> seems to have fixed it. I hope that is true, i cannot
> test that fix for my problem right now, because 3.0.2
> introduced some new problems for me, maybe later.

Works for me, but then someone == yours truly

You should be able to take jbossmq from 3.0.4 and
use jbossmq.jar and jbossmq-client.jar in any
previous 3.0 version. I don't know of any interfaces
changes that would stop this.

>
> Regards,
>
> nitin

[cstone]

I can confirm that I am no longer encountering this problem in JBoss 3.0.4.

Excellent work on pushing this fix out!!