I'm guessing it's the final query that compiles and sorts the results.
Searching works by running a series of queries - one for each kind of
criteria (names, categories, identifiers, etc) - that return a list of keys
that match the criteria. This list is subsequently passed into each query
and appended as an IN list and therefore narrowed down. We had a user post
an issue that Oracle only allows 1000 terms in the IN list so these criteria
queries chunk the IN list into groups of 1000 (there is a parameter that
sets this value).
However, after all these queries are run and the results are hopefully
narrowed down enough, the resulting key list is used in an IN clause for one
final query that grabs all the necessary data and sorts the results. In
order to take advantage of SQL sorting, this final query does not "chunk"
the IN clause. Otherwise, sorting would have to occur as another step
within Java. The maximum results parameter for the search doesn't help
because the entire query is still run (but only the maximum results are
compiled into the returned list).
So, I'm thinking that this final query is the one that is causing the error.
It could be that either Hibernate or Derby (or JDBC) has an issue with a
query that has an IN clause with 2741 terms (Oracle would've died at 1000).
The solution would be to chunk this query like the previous criteria queries
and then do the sorting within Java.
I'm curious to see the results with MySql. Any thoughts?
-----Original Message-----
From: Jeremi Thebeau [mailto:[email protected]]
Sent: Friday, July 31, 2009 11:00 AM
To: [email protected]
Subject: jUDDI load testing update: Max search results
Hi,
I tried to determine how many businesses I could publish to juddi before
I get to many results back when I search for all businesses. To do this
I ran a test where I start with an empty DB (derby), publish a business
with a single service, then run a search for any business (by submitting
the wild-card "%" as the name of the business I am looking for). I run
this test repeatedly until the first error. Three times now I've gotten
to the 2741st iteration before the first error.
Here is the return SOAP msg and the stack trace:
Soap Message:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
<soap:Header />
<soap:Body>
<soap:Fault>
<faultcode>
soap:Server
</faultcode>
<faultstring>
org.hibernate.exception.GenericJDBCException: could not
execute query
</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
Message Context Properties:
- com.sun.xml.internal.ws.api.message.HeaderList = []
- com.sun.xml.internal.ws.api.server.WSEndpoint = null
- com.sun.xml.internal.ws.client.ContentNegotiation = none
- com.sun.xml.internal.ws.client.handle = null
- com.sun.xml.internal.ws.handler.config =
com.sun.xml.internal.ws.client.handlerconfigurat...@183ee9a
- com.sun.xml.internal.ws.server.OneWayOperation = null
- com.xceptance.xlt.ws.handler.requestData =
com.xceptance.xlt.api.engine.requestd...@13ada
- javax.xml.ws.handler.message.outbound = false
- javax.xml.ws.http.response.code = 200
- javax.xml.ws.http.response.headers = {null=[HTTP/1.1 200 OK],
Content-type=[text/xml;charset=UTF-8], Content-length=[264],
Server=[Apache-Coyote/1.1], Date=[Fri, 31 Jul 2009 12:22:07 GMT]}
- javax.xml.ws.reference.parameters = []
- javax.xml.ws.service.endpoint.address =
http://192.168.178.200:8080/juddi/services/inquiry
- javax.xml.ws.soap.http.soapaction.uri = null
- javax.xml.ws.wsdl.interface =
{urn:uddi-org:api_v3_portType}UDDI_Inquiry_PortType
- javax.xml.ws.wsdl.port =
{urn:uddi-org:api_v3_portType}UDDIInquiryServicePort
- javax.xml.ws.wsdl.service =
{urn:uddi-org:api_v3_portType}UDDIInquiryService
[14:21:50,074] ERROR [main] - Execution step failed (user:
'TFindBusinessByName-0', output: '1249042905521'):
javax.xml.ws.soap.SOAPFaultException:
org.hibernate.exception.GenericJDBCException: could not execute query
at
com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.j
ava:178)
at
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuil
der.java:111)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandle
r.java:108)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandle
r.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at $Proxy43.findBusiness(Unknown Source)
at
org.apache.juddi.xlt.action.SOAP.FindBusinessByName.execute(FindBusinessByNa
me.java:91)
at
com.xceptance.xlt.api.actions.AbstractAction.run(AbstractAction.java:315)
at
org.apache.juddi.xlt.test.TFindBusinessByName.findBusiness(TFindBusinessByNa
me.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.
java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.j
ava:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.ja
va:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.jav
a:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28
)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.jav
a:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.jav
a:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28
)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestRef
erence.java:45)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)
Is this expected behavior? The fault message doesn't exactly tell me
that there are too many search results returned. Is there another
possible problem?
Possibly worth mentioning is that a maximum of 5 results is specified
for the business search.
I'm using the snapshot release as is found here:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/juddi/juddi-
portal-bundle/3.0.0.SNAPSHOT/juddi-portal-bundle-3.0.0.20090723.201427-7.zip
installed on the following machine:
Processor: Intel(R) Core(TM)2 CPU, 6400 @ 2.13GHz;
RAM: 2011 MB;
OS: Ubuntu 9.04, linux kernel 2.6.28-13-generic.
The three XLT test reports can be view here:
http://xlt.xceptance.de/download/results/juddi/20090730-195254/
http://xlt.xceptance.de/download/results/juddi/20090731-112335/
These first two runs are basically the same except the first one was
planed to run for 15 hours and the second for only 3 hours. They both
ran for 1h 25 min
http://xlt.xceptance.de/download/results/juddi/20090731-132952/
This run is different only in that it uses the same AuthToken for all
queries.
Here is the XLT test suite that was used:
http://xlt.xceptance.de/download/results/juddi/testsuites/20090731-juddiTest
Suite.zip
Next I will switch to a mySQL DB and rerun these test.
Jeremi
