You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by "Rémi Flament (JIRA)" <ju...@ws.apache.org> on 2006/07/12 18:15:30 UTC
[jira] Created: (JUDDI-89) JDBC Datastore performance improvements
JDBC Datastore performance improvements
---------------------------------------
Key: JUDDI-89
URL: http://issues.apache.org/jira/browse/JUDDI-89
Project: jUDDI
Type: Improvement
Versions: 0.9rc4
Environment: Oracle
Reporter: Rémi Flament
Assigned to: Steve Viens
Attachments: juddi.patch
Hi,
Please find a *huge* patch attached.
We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
- Juddi was *very* slow with more than 1000 business services.
- Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
This patch applies to v0.9rc4.
Regards,
Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Rémi Flament (JIRA)" <ju...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/JUDDI-89?page=all ]
Rémi Flament updated JUDDI-89:
------------------------------
Attachment: patch2.patch
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: http://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Type: Improvement
> Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Steve Viens
> Attachments: juddi.patch, patch2.patch
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Commented: (JUDDI-89) JDBC Datastore performance
improvements
Posted by "Rémi Flament (JIRA)" <ju...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/JUDDI-89?page=comments#action_12420832 ]
Rémi Flament commented on JUDDI-89:
-----------------------------------
Here is a second patch that correct bugs added by the first one :
Index: BindingCategoryTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/BindingCategoryTable.java,v
retrieving revision 1.4
diff -u -r1.4 BindingCategoryTable.java
--- BindingCategoryTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ BindingCategoryTable.java 13 Jul 2006 08:13:34 -0000
@@ -153,6 +153,8 @@
PreparedStatement statement = null;
ResultSet resultSet = null;
+ if (bindingsKeys!=null && !bindingsKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
@@ -207,6 +209,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: BindingDescTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/BindingDescTable.java,v
retrieving revision 1.4
diff -u -r1.4 BindingDescTable.java
--- BindingDescTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ BindingDescTable.java 13 Jul 2006 08:13:34 -0000
@@ -144,6 +144,8 @@
PreparedStatement statement = null;
ResultSet resultSet = null;
+ if (bindingsKeys!=null && !bindingsKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
@@ -197,6 +199,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: BindingTemplateTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/BindingTemplateTable.java,v
retrieving revision 1.4
diff -u -r1.4 BindingTemplateTable.java
--- BindingTemplateTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ BindingTemplateTable.java 13 Jul 2006 08:13:34 -0000
@@ -239,6 +239,8 @@
PreparedStatement statement = null;
ResultSet resultSet = null;
+ if (bindingsKeys!=null && !bindingsKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
query.append("(" + selectInSQL);
@@ -293,6 +295,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
@@ -358,6 +362,8 @@
PreparedStatement statement = null;
ResultSet resultSet = null;
+ if (servicesKeys!=null && !servicesKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
@@ -426,6 +432,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: BusinessServiceTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/BusinessServiceTable.java,v
retrieving revision 1.3
diff -u -r1.3 BusinessServiceTable.java
--- BusinessServiceTable.java 11 Jul 2006 09:13:02 -0000 1.3
+++ BusinessServiceTable.java 13 Jul 2006 08:13:34 -0000
@@ -198,6 +198,9 @@
ResultSet resultSet = null;
ArrayList services = new ArrayList();
+ if (servicesKeys!=null && !servicesKeys.isEmpty())
+ {
+
try {
DynamicQuery query = new DynamicQuery();
query.append("(" + selectInSQL);
@@ -246,6 +249,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return services;
}
/**
Index: ServiceCategoryTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/ServiceCategoryTable.java,v
retrieving revision 1.4
diff -u -r1.4 ServiceCategoryTable.java
--- ServiceCategoryTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ ServiceCategoryTable.java 13 Jul 2006 08:13:34 -0000
@@ -152,6 +152,8 @@
PreparedStatement statement = null;
ResultSet resultSet = null;
+ if (servicesKeys!=null && !servicesKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
query.append("(" + selectInSQL);
@@ -206,6 +208,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: ServiceDescTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/ServiceDescTable.java,v
retrieving revision 1.3
diff -u -r1.3 ServiceDescTable.java
--- ServiceDescTable.java 11 Jul 2006 09:13:02 -0000 1.3
+++ ServiceDescTable.java 13 Jul 2006 08:13:34 -0000
@@ -143,7 +143,9 @@
Map results = new HashMap();
PreparedStatement statement = null;
ResultSet resultSet = null;
-
+
+ if (servicesKeys!=null && !servicesKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
query.append("(" + selectInSQL);
@@ -196,6 +198,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: ServiceNameTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/ServiceNameTable.java,v
retrieving revision 1.3
diff -u -r1.3 ServiceNameTable.java
--- ServiceNameTable.java 11 Jul 2006 09:13:02 -0000 1.3
+++ ServiceNameTable.java 13 Jul 2006 08:13:34 -0000
@@ -146,6 +146,8 @@
Map results = new HashMap();
+ if (servicesKeys!=null && !servicesKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
query.append("(");
@@ -200,6 +202,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: TModelInstanceInfoDescTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/TModelInstanceInfoDescTable.java,v
retrieving revision 1.4
diff -u -r1.4 TModelInstanceInfoDescTable.java
--- TModelInstanceInfoDescTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ TModelInstanceInfoDescTable.java 13 Jul 2006 08:13:34 -0000
@@ -155,6 +155,9 @@
ResultSet resultSet = null;
Map results = new HashMap();
+
+ if (bindingsKeys!=null && !bindingsKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
@@ -216,6 +219,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
Index: TModelInstanceInfoTable.java
===================================================================
RCS file: g:/local/cvs/cvs-uddi/juddi/src/java/org/apache/juddi/datastore/jdbc/TModelInstanceInfoTable.java,v
retrieving revision 1.4
diff -u -r1.4 TModelInstanceInfoTable.java
--- TModelInstanceInfoTable.java 11 Jul 2006 09:13:02 -0000 1.4
+++ TModelInstanceInfoTable.java 13 Jul 2006 08:13:34 -0000
@@ -169,6 +169,8 @@
ResultSet resultSet = null;
Map results = new HashMap();
+ if (bindingsKeys!=null && !bindingsKeys.isEmpty())
+ {
try {
DynamicQuery query = new DynamicQuery();
query.append("(" + selectInSQL);
@@ -248,6 +250,8 @@
} catch (Exception e) { /* ignored */
}
}
+ }
+ return results;
}
/**
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: http://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Type: Improvement
> Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Steve Viens
> Attachments: juddi.patch
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Rémi Flament (JIRA)" <ju...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/JUDDI-89?page=all ]
Rémi Flament updated JUDDI-89:
------------------------------
Attachment: juddi.patch
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: http://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Type: Improvement
> Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Steve Viens
> Attachments: juddi.patch
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Assigned: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Kurt Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt Stam reassigned JUDDI-89:
------------------------------
Assignee: Tom Cunningham (was: Steve Viens)
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 2.0
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Commented: (JUDDI-89) JDBC Datastore performance
improvements
Posted by "Rémi Flament (JIRA)" <ju...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/JUDDI-89?page=comments#action_12420884 ]
Rémi Flament commented on JUDDI-89:
-----------------------------------
Another bug corrected :
--- C:\salto\FindServiceByNameQuery.java Thu Jul 13 17:26:14 2006
+++ C:\salto\FindServiceByNameQuery2.java Thu Jul 13 17:26:25 2006
@@ -173,7 +173,7 @@
if (keysIn == null)
return;
- sql.append("AND ( S.SERVICE_KEY IN (");
+ sql.append("AND S.SERVICE_KEY IN (");
int keyCount = keysIn.size();
int count = 0;
@@ -193,7 +193,7 @@
}
}
- sql.append(")) ");
+ sql.append(") ");
}
/**
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: http://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Type: Improvement
> Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Steve Viens
> Attachments: juddi.patch, patch2.patch
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Kurt Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt Stam updated JUDDI-89:
---------------------------
Fix Version/s: 2.0
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 2.0
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Kurt T Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt T Stam updated JUDDI-89:
-----------------------------
Fix Version/s: (was: 2.0)
3.0
moving to 3.0
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 3.0
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Kurt T Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt T Stam updated JUDDI-89:
-----------------------------
Fix Version/s: (was: 3.0)
3.0.1
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 3.0.1
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Rémi Flament (JIRA)" <ju...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/JUDDI-89?page=all ]
Rémi Flament updated JUDDI-89:
------------------------------
Attachment: juddi3.patch
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: http://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Type: Improvement
> Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Steve Viens
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org
[jira] Updated: (JUDDI-89) JDBC Datastore performance improvements
Posted by "Kurt T Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt T Stam updated JUDDI-89:
-----------------------------
Fix Version/s: (was: 3.0.1)
3.0.2
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 3.0.2
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JUDDI-89) JDBC Datastore performance
improvements
Posted by "Kurt Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629039#action_12629039 ]
Kurt Stam commented on JUDDI-89:
--------------------------------
Hey Tom,
If you have an example with lots of services then maybe we can check if this patch helps.
> JDBC Datastore performance improvements
> ---------------------------------------
>
> Key: JUDDI-89
> URL: https://issues.apache.org/jira/browse/JUDDI-89
> Project: jUDDI
> Issue Type: Improvement
> Affects Versions: 0.9rc4
> Environment: Oracle
> Reporter: Rémi Flament
> Assignee: Tom Cunningham
> Fix For: 2.0
>
> Attachments: juddi.patch, juddi3.patch, patch2.patch
>
>
> Hi,
> Please find a *huge* patch attached.
> We have used Juddi with more than an hundred business services and we had some issues. This patch correct these issues :
> - Juddi was *very* slow with more than 1000 business services.
> - Oracle cannot handle more than 1000 elements in SQL "IN" request, so Juddi crashed when a business entity contained more than 1000 services.
> For the "IN" problem we added a method in util/Config which gives the maximum element the db can handle in IN requests.
> For the performance problem we had to rewrite a lot of the JDBC datastore. Basically the thing is to avoid to do too much sql requests by grouping them. As an example instead of the method fetchService() we use the method fetchServices(), etc.
> Thanks to these corrections we had great performance improvement : the getbusinessdetail used to take more than 40 seconds on big business entity, now it takes about 6 seconds.
> This patch applies to v0.9rc4.
> Regards,
> Rémi Flament.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: juddi-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: juddi-dev-help@ws.apache.org