Hi,
One of my notes points to a JMS (ActiveMQ) based spoolmanager.
Now that we added derby it would be also easier (ActiveMQ
default db
is Derby, too).
I'm not sure how much work is needed for JMS compared to
the patch to
make the current spoolmanager single threaded.
If feasible/"easy enough" do we like more the JMS solution?
Just curious: isn't JMS an overkill just to solve a threading problem?
JMS itself isn't heavyweight: activemq is really lightweight.
I see. A few years ago it was a pretty overhead if I recall well :).
If I remember, the best part of JMS were the transactions :).
If we adopt JMS we get remote spool monitoring/handling for free.
That sounds very good.
We also get JMS distributability and "free" clustering support.
I would really like to see a JAMES config example about how could this
be achieved :).
And we remove some of the avalon dependency.
This sounds also very good :).
Thank you for the details,
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
