Slowdown of ESB-Registry

[bernd.koecke]

Hello all,

would it be possible to add a new endpoint to jUDDI only after the older identical entries are remove?

I am using JBossESB 4.2/4.2.1 on a JBossAS-Cluster, but the problem happens on a single node, too. Sometimes a node doesn't shutdown normally, so I have to kill him. When this happens the ESB has no chance to remove his service endpoints. But when the server comes up, the new endpoints are added at the end of the list in jUDDI without removing the old ones. When a server comes down normally, the first matching entry in the list is removed. This means that the list grows with every killed server and will never decline. Now I have so much old endpoints, that my server doesn't come down without an OutOfMemoryException, because from 4.2 to 4.2.1 the JNDI-URL for JMS-Queues changes and so when undeploying an endpoint the whole list of EPRs is instantiated until the last one, which will be removed. Currently I have roundabout 120 old endpoints per service. This problem would decrease when the old entries after a server crash are deleted, e.g. when the code of inserting an endpoint cleans up the registry before. Would this be a good idea?

Thanks in Advance,
Bernd

[mvecera]

Hello,

this issue well-known (as you can see here for example http://www.jboss.com/index.html?module=bb&op=viewtopic&t=96389&postdays=0&postorder=asc&start=10).

Your idea is definitely good, and you are not the first one. There's a plan to solve that problem in the future. Unfortunatelly I can't promise you when.

[marklittle]

There are a couple of fixes for this in the CP1 branch.

[bernd.koecke]

Hello,

thanks a lot. I will have a deeper look at the referenced topic. I wrote a small JAXR-Client for direct registry access. As a quick fix, I will add the possibility to remove the duplicate entries. This might not be a solution for all situations, but its suitable for my current problem and will hopefully lessen the shutdown time of our cluster. Currently each node needs more than 20 minutes to come down. And then it seems to be a good idea to checkout the CP1 branch and play around with it.

Best regards,
Bernd

[marklittle]

I'd recommend the CP branch because there are a number of performance improvements too.

[bernd.koecke]

Hello,

now I played a little bit around with the CP branch, read the mentioned forum and the noted whitepaper. I see the better performance of the CP version, it seems to add new entries at the beginning of the list, so the maybe damaged older entries need not be handled on shutdown/undeployment. But the damaged entries are still there. I learned by the mentioned docs, that its not a good idea when the ESB should determine on deployment which entry is old or damaged. But it would be nice, if the EPR knows his UUID. May be as a part of an extension entry in EPRs PortReference. Then it would be possible to ask the Registry for the UUIDs of all stored service endpoints and ask the ESB through JMX for the UUIDs of the registered EPRs. All UUIDs which are in both listes are ok. And the ids which are only known by the registry I have to look at by myself. Would this be a solution and are there any thoughts to add the UUID to the EPRs data? I saw some posts on the mentioned topic, but I can't find it in the code of 4.2.1.CP.

Thanks in advance,
Bernd

[marklittle]

There are a number of problems with your proposed solution, not least of which is the fact that the same registry may be used by multiple ESB deployments each with multiple services registered with the same service name/category. So in order for this to work, you'd need to cross reference all ESB instances for their UUIDs in order to find stale references. Then there's the problem that there is no global notion of "now", so the list you get back from the registry and the list you get back from all of the ESB instances may be "identical" when in fact there are differences due to timing.

We will definitely provide a fix for this, but for the time being you're better off using the two CP options that are mentioned in the documentation.