10 Replies Latest reply on Dec 15, 2008 1:08 AM by sanjoa

    Duplicate EPRs in jUDDI

    rkiesler

      Using ESB 4.3 GA, I noticed that when the AS shuts down abnormally, jUDDI contains duplicate/triplicate/quarduplicate/etc. records the next time I start up. This can be verified using the contract application.

      Apparently this is a known issue (https://jira.jboss.org/jira/browse/JBESB-1164) and is listed as fixed in 4.2.1 CP2, yet 4.3 still demonstrates this behavior.

      The fix note states "There are now mechanisms for services to clean up when they restart.", but does not specify what these mechanisms are, nor do any of the quickstart examples seem to implement those mechanisms.

      Any insights will be appreciated.

      Thanks,
      --
      Roy

        • 1. Re: Duplicate EPRs in jUDDI
          beve

          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.

          Regards,

          /Daniel

          • 2. Re: Duplicate EPRs in jUDDI
            rkiesler

            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.

            • 3. Re: Duplicate EPRs in jUDDI
              tfennelly

              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.

              • 4. Re: Duplicate EPRs in jUDDI
                rkiesler

                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.

                • 5. Re: Duplicate EPRs in jUDDI
                  kconner

                  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?

                  • 6. Re: Duplicate EPRs in jUDDI
                    rkiesler

                    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.

                    • 7. Re: Duplicate EPRs in jUDDI
                      kconner

                      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.

                      • 8. Re: Duplicate EPRs in jUDDI
                        kurtstam

                        Hi Kevin,

                        Was there a bug reported on this in the Scout Issue Tracker?

                        thx

                        --Kurt

                        • 9. Re: Duplicate EPRs in jUDDI
                          kconner

                          Hi Kurt.

                          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.

                          Kev

                          • 10. Re: Duplicate EPRs in jUDDI
                            sanjoa

                            Another related issue https://jira.jboss.org/jira/browse/JBESB-866 (jUDDI retains invalid EPRs)