The refactoring you did has completely broken the architecture:
* JmsListenerFactory is now used as a singleton that is initialized with the
dispatcher that created it
* when a new dispatcher is created, in the constructor you have:
if (enableJMS) {
this.jlf = JmsListenerFactory.getInstance(this);
}
but this call returns the singleton instance initialized with the first
dispatcher.
Jacopo
On Jun 22, 2012, at 8:41 AM, Jacopo Cappellato wrote:
> Jacques,
>
> could you please help me to understand all the changes you did around JMS? I
> see some issues (e.g. the value of ServiceDispatcher.enableJMS is ignored)
> and reviewing the history of commits I have seen that you have committed
> changes, then fixed them (partially reverting?) but all in all I have a lot
> of confusion and you can probably help in summarizing what was done.
>
> For example the commit:
>
> =================================
> Author: jleroux
> Date: Fri Jun 3 19:05:07 2011
> New Revision: 1131144
>
> URL: http://svn.apache.org/viewvc?rev=1131144&view=rev
> Log:
> Closes "JmsTopicListener started twice when distributed-cache-clear is
> active" reported by Martin Kreidenweis at
> https://issues.apache.org/jira/browse/OFBIZ-4296
> Simply avoid to start a JMS Listener thread from Job Manager when DCC is on.
> Then set it back to previous value.
> =================================
>
> seems to have caused issues that you tried to fix with:
>
> =================================
> Author: jleroux
> Date: Fri Sep 23 19:22:40 2011
> New Revision: 1174964
>
> URL: http://svn.apache.org/viewvc?rev=1174964&view=rev
> Log:
> A patch from Dimitri Unruh "With no DistributionCacheClear JMS is not working
> anymore." https://issues.apache.org/jira/browse/OFBIZ-4296
> Tested in both case (with and w/out dcc), works fine AFAICT
> =================================
>
> I am really confused.
>
> Jacopo
