-
15. Re: JBAS-1445 & JBAS-2156 Discussion thread
"adrian@jboss.org" wrote:
4) Changes to the wire format (EACK)
Again, what happens to user code that doesn't expect this, e.g. in an interceptor?
Since DataInput regards a non-zero values as a boolean "true", EACK will appear as a "true" or ACK. So, unless the user code expects a 1 or a 0, it should be fine.
5) Changing to threadpooling in UIL2 (something I already tested and reverted because such a trivial change introduces problems).
Can you explain this in more detail? The server pool is indeed shared with the UIL2 connector, but I don't see how passing one is asking for trouble. -
16. Re: JBAS-1445 & JBAS-2156 Discussion thread
You misunderstand. The issue is not about making it serialization compatible,
though that is a consideration.
These methods/fields are already public and could be used by some user's code.
If you change it, they will start getting NoSuchField/MethodError.
Like it or not, they are part of the public api of JBossMQ and can/must not be changed.
Just remove the isOutdated() checking from the client side.
It has been redundant anyway since the serverside started doing expiry processing. -
17. Re: JBAS-1445 & JBAS-2156 Discussion thread
"genman" wrote:
Can you explain this in more detail? The server pool is indeed shared with the UIL2 connector, but I don't see how passing one is asking for trouble.
The issue is about whether the protocol behaves well under thread pool exhaustion
and/or "recursive" operations between client and server.
Any change to the thread pooling will need to have stress tests for this condition.
A pool configure too small is the same (if not worse) than no pool at all. -
18. Re: JBAS-1445 & JBAS-2156 Discussion thread
"genman" wrote:
Sorry to make you get involved in a big feature, but when you end up fixing one thing, one other thing leads to another, etc. I'll see about getting this into CVS head at least.
Let's do the patches individually so we know which change causes any breakages.
The logical order is the one I defined above. -
19. Re: JBAS-1445 & JBAS-2156 Discussion thread
"adrian@jboss.org" wrote:
The issue is about whether the protocol behaves well under thread pool exhaustion
and/or "recursive" operations between client and server.
Any change to the thread pooling will need to have stress tests for this condition.
A pool configure too small is the same (if not worse) than no pool at all.
I wrote it so the client have its own thread pool in my implementation for this reason. -
20. Re: JBAS-1445 & JBAS-2156 Discussion thread
I've laid out a roadmap for the expiry processing.
I think you have most of it already, except the notion of "plugin" and
the backward compatibility issues?
So let's remove the other changes and get it tested so you can backport it.
Then we can move onto the other threadpooling if you are still interested.