jUDDI in cluster issue

[mikefinnx]

We have 4 servers configured in a cluster ('all' config), using a single DB for jUDDI (changed using the tools/schema changer script). Services are deployed to all nodes in the cluster, as are JMS endpoints. Here is the weird thing - when I start each server in the cluster, only the last server started gets its endpoints registered in the binding_template table. The previously started server's entries get overwritten. So, each service only has a single entry in UDDI, even though it is running on 4 servers. If the request lands on any server (front ended by apache jk proxy) besides the one whose endpoints are registered (the last to be started), the service fails with an error about not being able to find DLQ:

"Registry details for service [JBossESB-Internal:DeadLetterService] could not be determined from the registry."

Any ideas? Seems like jUDDI is not aware it's in the cluster?

TIA,

Mike

[kconner]

Which version are you running?

Kev

[mikefinnx]

Geez - that would help. Sorry.

SOA-P 5.0.0

[sordyl]

Mike, we're seeing an identical problem with SOA-P 5.0.1.  Did you find a resolution?

We're also seeing just the last started server endpoints in http://localhost:8080/uddi-console/ and once we take that server down the cluster is unusable.

Any idea if setting <entry key="juddi.server.baseurl">http://${jboss.esb.bind.address}:8080</entry> with the load balancer address in esb.juddi.xml is meant for configuring this?

thanks,

-Brent

[kconner]

The juddi configuration we were using caused the database to be dropped and regenerated every time the server started.

This has been changed in SOA and ESB 4.9 to use SQL initialisation rather than hibernate initialisation.

The problem line is the following from persistence.xml

<property name="hibernate.hbm2ddl.auto" value="create"/>

[kconner]

Mike, we're seeing an identical problem with SOA-P 5.0.1.  Did you find a  resolution?

You should update to 5.0.2

Kev

[mikefinn]

Sure wish I had re-read this thread before spending 2-3 hours to come to the same conclusion :-)

Looks like as a workaround (5.0.2 is just not an option for us right now as we are close to going live on 5.0.0), you can change jbossesb-registry.sar/juddi_config/META-INF/persistence.xml

<property name="hibernate.hbm2ddl.auto" value="create"/>

to

<property name="hibernate.hbm2ddl.auto" value="validate"/>

Mike