You can add the following property to the "core" section of jbossesb-properties.xml:
<property name="org.jboss.soa.esb.failure.detect.removeDeadEPR" value="true">
For more info about this property and what it does please refer to From the section "Clustering and Fail-over support
" section in the AdministrationGuilde.pdf.
Thanks for that, Daniel -- I added this property, but am getting mixed results. EPRs continue to pile up for all services except the 2 services defined in the invm_transport quickstart sample.
For example, after 5 forced shutdowns, the HelloWorld sample service (FirstServiceESB:SimpleListener) shows 6 copies of the endpoint jms://127.0.0.1:1099/queue/quickstart_helloworld_Request_esb --
looking at the description of this property in the admin guide, it states that "If you set the org.jboss.soa.esb.failure.detect.removeDeadEPR
property to true, then whenever ServiceInvoker suspects an EPR has failed
it will remove it from the Registry". In this case, all 6 EPRs are valid, so the question is what qualifies an EPR as "dead"?
Appreciate any further insight.
ServiceInvoker should remove the EPR if it fails to deliver on it.
The best thing to do is get the source, hook up a debugger and set a breakpoint in ServiceInvoker and see what it's doing.
That was the point I was trying to make -- ServiceInvoker does not fail to deliver the message, as all copies of the EPR are perfectly valid (they're identical), therefore no cleanup takes place, and EPRs keep on piling up.
It is only when the EPR is invalid that it will be removed.
The ServiceInvoker is not able to tell whether a valid EPR has been registered from a duplicate (and active) service nor whether it has been left from a crashed server. if the ServiceInvoker can still, successfully, use the EPR then there is no functional reason to remove it.
Are you seeing any issues which you believe are caused by having these duplicates in the registry?
Well, the first issue that comes to mind is speed of registry searches, which increases noticeably when multiple copies of EPRs exist for multiple services. You can simply time the contract.jsp application as an example and see how the load time increases as more EPRs are added â€“ this JSP loops through service publishers, retrieves the EPRs for each service, and renders them to HTML. The looping through all the dups is costly.
The speed of registry searches is actually the result of a bug in scout and not a consequence of any loop, in the contract.jsp or otherwise.
We have a work around for it in ESB 4.4 but see https://jira.jboss.org/jira/browse/JBESB-1675 for the details/analysis.
Was there a bug reported on this in the Scout Issue Tracker?
To be honest I am not sure. TomC is certainly aware of both this and the XML parsing issue in jUDDI, both of which we are working around at present.
If they are not there then we need to get something added.