Design discussions belong in the forums - Compatibility

[adrian.brock]

E

"
The intent was to place expired messages from queue A to queue B, and really has nothing to do with the existing DLQ feature. It may make sense to change the default configuration for all queues to expire messages into the DLQ.

Longer term, there should be a "total solution" that deals with (in an easily configurable manner) the lifecycle of all messages on the server, from inception, to attempted delivery, to eventually being expired from the DLQ, into some sort of reporting database or logfile or whatever. (By the way, I never got to hear your long term design goals for this on the forum.)

Many of the public interface changes and thread pool changes I made are not necessary to implement this feature, although it seemed logical for JBossMQ to unify, at least on the server, the pool it was using. These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.

I would be happy to apply a minimal set of changes to 4.0, after 4.0.3 release, with your support. This would include changes to TimeoutFactory, BasicQueue, DestinationMBean/MBeanSupport, and SpySession (remove isOutdated()).
"

[adrian.brock]

I moved your comment/question from JIRA.

We need to distinguish "things that need doing"- JIRA tasks
from design discussion, questions and help - design forums

Otherwise the JIRA tasks are useless as release notes, because they become
unreadable for users.

I should really have added my comments as subtasks, but I'm not sure you are
on the JIRA mailing list. I just wanted to flag that the patch as it stands is not
acceptable.

[adrian.brock]

The intent was to place expired messages from queue A to queue B, and really has nothing to do with the existing DLQ feature. It may make sense to change the default configuration for all queues to expire messages into the DLQ.

That could be an optional configuration, e.g. on the destination manager
But it should never be the default. The default is for expired messages to be
deleted (as anticpated in the spec).
This is what countless users of JBossMQ already expect to happen.

Many of the public interface changes and thread pool changes I made are not necessary to implement this feature, although it seemed logical for JBossMQ to unify, at least on the server, the pool it was using. These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.

I would be happy to apply a minimal set of changes to 4.0, after 4.0.3 release, with your support. This would include changes to TimeoutFactory, BasicQueue, DestinationMBean/MBeanSupport, and SpySession (remove isOutdated()).

Anything that says "public" could be used by a user. It should not be changed unless:
1) It is absolutely required to fix a bug (e.g. the spec demands it), in which case
we should try to provide an error message that explains the incompatible change
2) If it is not required, the api should be flagged as deprecated and then changed in the next major release, or preferably the one after that.

This includes a change to semantics, not just the signature of the method.
e.g. new AcknowledgementRequest() has always created NACK until your change.

[adrian.brock]

These thread pooling changes could be left out of 4.0, or back-ported (once "fixed") by somebody. Personally, I never knew enough about JBossMQ internals or what was deemed "public" or not to design the correct fix for this.

I will only consider these thread pooling changes complete when you can reproduce
the old configuration. i.e. somebody should be able to revert to the old semantics
if they have problems.

And as a matter of good design, it should be possible to use different thread pools
in different areas. e.g. UIL2 could do the following logic:

1) Use Pool configured on MBean
2) Use Pool from destination manager (if I can get at it and it is configured)
3) Default back to old behaviour

[ovidiu.feodorov]

What JIRA issue?
Would you be so kind to also link to it?
And maybe use a more explicit title?

[adrian.brock]

2) If it is not required, the api should be flagged as deprecated and then changed in the next major release, or preferably the one after that.

There is also the additional considersation in that why should we make it harder to
migrate between versions, just because we want to refactor some code.

e.g. although the default config of the jbossmq xml has changed quite a lot over the
years to take advantage of new features, better implementation and config options,
it is still in principle possible to drop the original 2.4.x config into 3.2.7

ok, you have to make a few small changes, like add the MessageCache mbean
that wasn't in 2.4.x and revert the login-config.xml
One example that makes it more difficult, is some idiot refactored the name of the
destination manager in 3.0.0alpha for no good reason.

The reason why you can't do the same in 4.0.x is because the deprecated file pm
and crappy ILs are gone in that release. But it waited for a major release for
this to happen and the 4.0.x config is practically the same as 3.2.x

[adrian.brock]

What JIRA issue?
Would you be so kind to also link to it?
And maybe use a more explicit title?

http://jira.jboss.com/jira/browse/JBAS-2156

[genman]

Adrian,

The behavior, as it is now in JBoss HEAD, is largely the same as 4.0 and was intended to work for 99.9% of your customers. Yes, there are incompatible changes I made within what I suspected were internal interfaces. Yes, I made some obvious mistakes with my check-ins, though all unit tests passed ...

I would be happy if you just told me precisely what you want including rollback in head, deletion of this patch/issue, a rewrite, etc. I'm more interested in cooperation than education, though education is appreciated, it isn't really letting me reach my goal here, which is eventual inclusion in JBoss 4.

I do appreciate your time here. If I were you, I'd probably would have taken the efficient route and rejected the patch outright, requested a rewrite until things were acceptable, etc. I do want to contribute, not generate a lot of bother.

And I take back what I said about you not being affectionate, I think you are. If you didn't care about me, you wouldn't have bothered to try to communicate so much.