Hi Sven
On 07/02/12 17:25, Viehmeier, Sven wrote:
Hi Sergey,
Thanks for your reply. I am using org.apache.cxf.ws, but I am not setting any
org.apache.cxf.ws.http.context property. The only properties I set in my
Activator are:
props.put("service.exported.interfaces", "*");
props.put("service.exported.configs", "org.apache.cxf.ws");
props.put("org.apache.cxf.ws.address", url);
bundleContext.registerService(..., props);
I had a look at the page you directed me to and saw that there is a possibility
to configure the thread pool size using
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure.dtd";>
<Configure id="server" class="org.eclipse.jetty.server.Server">
<Set name="threadPool">
<New class="org.eclipse.jetty.util.thread.QueuedThreadPool">
<Set name="minThreads">10</Set>
<Set name="maxThreads">1000</Set>
</New>
</Set>
</Configure>
But when I tested it, it did not work. I put the pax-web-jetty-bundle-1.1.2.jar
in the plugins folder of my Eclipse. I tried to use the possibility to specify
an external xml file. So I created the jetty.xml file and placed the
configuration code from above in it. Then I put the
org.ops4j.pax.web.config.file property in my config.ini of Eclipse and tried
out multiple paths:
org.ops4j.pax.web.config.file=C:\jetty\jetty.xml
org.ops4j.pax.web.config.file=C:/jetty/jetty.xml
[email protected]/workspace/jetty.xml
But nothing worked. Furthermore, I tried the same steps in Felix, but with the
same result.
I think I am lacking some understanding of the internals of DOSGi and what all
the different components do. Do I have to activate the pax-web bundle somewhere
in Eclipse and Felix? Did I put the wrong xml in the jetty configuration? Or do
I miss any other important step?
When "org.apache.cxf.ws.address" is used then CXF Jetty Transport will
be directly involved, it is possible to configure it in OSGI with Spring
and soon Blueprint, but not yet in DOSGi.
So, when working with DOSGi, always consider using
"org.apache.cxf.ws.http.context" - this way OSGI HttpService will be
used and hence all the relevant jetty configuration should work.
At the moment only a greeter_rest demo (in DOSGi 1.3) uses a similar
"org.apache.cxf.rs.http.context" property like "/greetme" or similar,
the configuration for WS endpoints is identical except for the name of
the property itself.
Filer-based security will work (see a security_filter demo), host name,
port, web app context will be hidden away too.
Cheers, Sergey
Cheers,
Sven
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: 07 February 2012 15:27
To: [email protected]
Subject: Re: Distributed OSGi: Maximum number of parallel requests == 24?
Hi
On 07/02/12 14:09, Viehmeier, Sven wrote:
Hello,
I faced another issue with my distributed OSGi application. My application
should handle hundreds of requests per second whereby each request might need
one second or more calculation time. But from my tests it seems that the OSGi
framework only accepts 24 requests in parallel and queues the others.
I first thought that it is an error in my application so I commented out
everything, just logged each service call, and set the thread to sleep to
simulate the workload. It showed the same behaviour: 24 service calls were
logged, then some wait time while the threads were sleeping, and then the next
logs.
I although thought about a problem in my client (also an OSGi application), so
I tried to access the service by using JMeter directly on the WSDL endpoint.
The service behaved the same.
I also tested it in Felix and Equinox to see if there is any difference between
the containers, but both showed the same behaviour.
The only explanation that came in my mind so far is the size of an internal
thread pool that might be used by the OSGi container to schedule the requests.
Does anybody know if there is a threshold for the maximum number of concurrent
requests in OSGi and how I could increase it? Or do you have an idea what else
could be the source of this behaviour?
Do you use org.apache.cxf.ws.http.context ? If yes then the following
should help:
http://team.ops4j.org/wiki/display/paxweb/Advanced+Jetty+Configuration
Cheers, Sergey
Here is the code that I used to test the behaviour:
Service endpoint:
public AtomicInteger count = new AtomicInteger(0);
public MyResponse putRequest(MyRequest request) {
System.out.println(this.count.incrementAndGet());
try {
Thread.sleep(10000);
} catch (Exception e) {
e.printStackTrace();
}
this.count.decrementAndGet();
return new MyResponse("Hello from Server!");
}
Client:
int id = 0;
for (int repeat = 0; repeat< 10; repeat++) {
for (int i = 0; i< 50; i++) {
LoadGeneratingThread t = new LoadGeneratingThread(id);
t.start();
id++;
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
}
The LoadGeneratingThread simply looks for the service using a
ServiceTracker<S,T> and if it finds it, it calls the putRequest method.
Many thanks in advance,
Sven
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
