Bug 779729 - (SOA-2091) JAXRRegistryImpl performance enhancements
JAXRRegistryImpl performance enhancements
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.0.0 GA
Unspecified Unspecified
high Severity high
: ---
: 5.0.2
Assigned To: Pavel Macik
Depends On:
  Show dependency treegraph
Reported: 2010-05-20 08:27 EDT by Kevin Conner
Modified: 2010-07-22 03:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-07-22 03:58:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
SOA-P-JUDDI-performance-comparison.ods (13.55 KB, application/vnd.oasis.opendocument.spreadsheet)
2010-07-22 03:43 EDT, Pavel Macik
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-2091 None None None Never

  None (edit)
Description Kevin Conner 2010-05-20 08:27:38 EDT
Date of First Response: 2010-06-06 22:49:40
project_key: SOA
Comment 1 Kevin Conner 2010-05-20 08:28:13 EDT
Link: Added: This issue depends JBESB-3326
Comment 2 Kevin Conner 2010-05-20 12:55:13 EDT
Updated in ESB codebase, will be in next merge.
Comment 3 Dana Mison 2010-06-06 22:49:40 EDT
More information needed to document this:

Is all the work here related to reducing the number of database queries ?

The following items where taken from JBESB-3306. Do they adequately cover the work done here?

- cache classification scheme

- generate deleted EPR information once

- check retrieved service for bindings before querying for bindings.
Retrieved services are checked for binding information before querying the database. 
Comment 4 Kevin Conner 2010-06-08 09:37:53 EDT
-cache classification schema

The classification scheme was repeatedly queried from the repository even though this information does not change, once retrieved it can be cached and reused.

- generate deleted EPR information once

The implementation has to discover the correct EPR to delete and, to achieve this, compares the current EPR string representation with those in the repository.  The previous implementation generated the string representation of the deleted EPR for every comparison, rather than generating it once and then comparing with each EPR in the registry.

- check retrieved service for bindings before querying for bindings

The process to query current list of EPRs involves two steps, query for the service information and then search for associated bindings.  The jUDDI v2 implementation returns the associated bindings as part of the overall service information and allows us to miss out the second, more intensive, juddi v2 query.
Comment 5 Dana Mison 2010-06-11 03:19:09 EDT
Added to the SOA 5.0.2 release notes as resolved:

JAXRRegistryImpl has had the following performance enhancements.

* Classification schemes are now cached when retrieved so they can be reused without having to query the database again.
* When deleting End Point References (EPRs), the string representation of the EPR to delete is now only generated once and reused for each EPR comparision instead of re-creating it each time. 
* The process for querying the current list of EPRs now reuses the associated bindings information returned with the overall service information instead of performing a separate query for this information.
Comment 6 Pavel Macik 2010-07-22 03:36:14 EDT
Verified in 5.0.2.GA
Comment 7 Pavel Macik 2010-07-22 03:43:40 EDT
Performance results comparison attached
Comment 8 Pavel Macik 2010-07-22 03:43:40 EDT
Attachment: Added: SOA-P-JUDDI-performance-comparison.ods

Note You need to log in before you can comment on or make changes to this bug.