I'm oh-so-tired of fighting jUDDI.  The duplicate EPRs and long query times are killing our system performance.  At one point, the system had 2400-ish registered EPRs, when it should have had 392 (8 homogenous ESB servers, 49 services each).  I could have spent countless hours analyzing why the duplicate EPRs were getting registered.  I suspect it has something to do with a failure to deregister when a cluster node comes down.  However,I just didn't have the time.  We still had a caching interceptor between the ESB and jUDDI, despite the fact that it was unconfigured several versions ago, because we just never saw the supposed query speed increase after the recent jUDDI version upgrade.  Even then, the cache entries expired and we were slowed by the DB performance.  Putting a "forever" timeout on the cache wouldn't work because we needed registry liveness for possible server shutdowns, crashes, and starts.  Also, a long cache timeout prevents rapid utilization of additional capacity because booted servers aren't recognized and used until one cache timeout interval (this can be mitigated by having your ESB-aware clients call an EJB deployed on the ESB server that in-turn calls ServiceInvoker for you.  Clustered EJB refs in JNDI are immediately updated when a new server comes online).

I've written a registry interceptor that does not delegate to the underlying registry to answer any queries (i.e. getRegistry() is never called).  I used JBoss Cache to back it.  So far, it runs nicely in a development environment.  I'll soon know how it behaves under load on our 32-node test cluster.  JBoss Cache seemed like a natural choice because it facilitates the distribution of the EPR list, while having a low overhead for the millions of reads that will occur after the initial few writes.

So, my question is: has anybody run into trouble subverting jUDDI?  I can't imagine how, since I'm providing all of the necessary features in the interceptor, but trouble always seems to come from the least expected source.  Or, perhaps you've managed to get the ESB and jUDDI to work in a large-ish environment and would like to educate me on where I went wrong.  This would be better in fact.  I like learning more than I like programming around problems.

I think it would be useful to find out what percentage of the user community is actually using the features of jUDDI.  If it is found that nobody cares about discoverability or having an independent UDDI interface, it would be beneficial (and decrease deployment difficulty) if the distribution included an "org.jboss.internal.soa.esb.services.registry.JuddiFreeRegistryInterceptor" (Before you ask: mine would be of little use to you because it's built upon our abstraction of JBoss Cache, rather than the bare Cache API itself).