-
1. Re: One JUDDI, two JBoss ESB clusters
jjarkko Nov 10, 2008 12:39 PM (in response to jjarkko)We found some reason why this was so hard to setup. Mainly because ServiceInvoker class is somewhat messed ;)
ServiceInvoker needs a review and cleanup, e.g. more logging would be extremely helpfull. -
2. Re: One JUDDI, two JBoss ESB clusters
marklittle Nov 10, 2008 1:09 PM (in response to jjarkko)If you think there are issues then JIRA is your friend. That's far more useful to us and the community than "[ServiceInvoker] is somewhat messed" ;-)
Thanks. -
3. Re: One JUDDI, two JBoss ESB clusters
jjarkko Nov 10, 2008 1:18 PM (in response to jjarkko)Yes, Jira issue is coming up soon. I's just so happy when we found a solution to the issue so the post left early. We're still testing and making sure it's a correct fix.
-
4. Re: One JUDDI, two JBoss ESB clusters
mvecera Nov 11, 2008 3:40 AM (in response to jjarkko)Hello,
you could use two jUDDI instances (one on each node) with shared database (note that you cannot use Hypersonic for this). Then it is possible to call a service from another node without problems. -
5. Re: One JUDDI, two JBoss ESB clusters
sanjoa Nov 11, 2008 4:29 AM (in response to jjarkko)Here are the issues related to our clustering problem.
Wrong ReplyTo after message delivery failure: https://jira.jboss.org/jira/browse/JBESB-2183
Endless loop during cluster failover, caused by JmsCourier.jmsConnectRetry: https://jira.jboss.org/jira/browse/JBESB-2184
jUDDI retains invalid EPRs: https://jira.jboss.org/jira/browse/JBESB-866 -
6. Re: One JUDDI, two JBoss ESB clusters
kconner Nov 11, 2008 5:16 AM (in response to jjarkko)I have rejected JBESB-2184 because I believe your analysis is invalid. The count is represents the number of retry attempts before an exception is raised to the caller and is not intended to persist across invocations. Could you explain more about what is happening and why you believe this is at fault?
We have gone, pretty much, as far as we can with JBESB-866 but if you have further suggestions then we would appreciate hearing them. You mention a patch in the issue but do not provide any details.
As for JBESB-2183, I have had a quick look at the ServiceInvoker and can see a problem which would explain the problem. I'll get this fixed as quickly as possible.
Thanks for your help
Thanks. -
7. Re: One JUDDI, two JBoss ESB clusters
sanjoa Nov 11, 2008 5:35 AM (in response to jjarkko)I reopened the JBESB-2184 issue and clarified how the issue occurs for us.
I can also provide patches for all three issues if You like. -
8. Re: One JUDDI, two JBoss ESB clusters
kconner Nov 11, 2008 5:50 AM (in response to jjarkko)Your analysis was definitely wrong but I can see where the real bug lies.
It is the loop in deliver/pickupPayload that is at fault. I'll have this fixed as soon as I can.
Thanks again for your help,
Kev -
9. Re: One JUDDI, two JBoss ESB clusters
sanjoa Nov 11, 2008 6:30 AM (in response to jjarkko)I posted a patch for jUDDI retains invalid EPRs (JBESB-866) in subtask https://jira.jboss.org/jira/browse/JBESB-2185
-
10. Re: One JUDDI, two JBoss ESB clusters
kconner Nov 14, 2008 8:07 AM (in response to jjarkko)I have fixed the first two issues in our CP branches and will shortly be moving them across to trunk.
I'll take a look at the jUDDI patch and see what you are proposing. -
11. Re: One JUDDI, two JBoss ESB clusters
sanjoa Nov 14, 2008 8:13 AM (in response to jjarkko)Ok,
I tried the JmsCourier patch yesterday and it seems to work. I'll test the second fix next week. -
12. Re: One JUDDI, two JBoss ESB clusters
kconner Nov 14, 2008 8:54 AM (in response to jjarkko)Great, thanks very much. There are test cases for both issues but the real test is whether it addresses your concerns.
Thanks again
Kev -
13. Re: One JUDDI, two JBoss ESB clusters
sanjoa Nov 16, 2008 5:55 PM (in response to jjarkko)Both patches have now been tested against our cluster setup - everything works as expected.
Although the failover is quite slow when ServiceInvoker loops through all EPR's in order to find a working one.
I'll keep on testing..
/ Joakim