Hi Sven
thanks for the update,
On 08/02/12 17:29, Viehmeier, Sven wrote:
Hi Sergey,
Thank you very much for this hint. I got it to work now.
For others, here is what I did:
- Put the pax web bundle, including jetty, into your OSGi container (together
with its dependencies)
- Create a configuration file (jetty.xml) and add the xml content that I posted
before
- Set the system property -Dorg.ops4j.pax.web.config.file=<path of your
jetty.xml> to point to your configuration file (you should be able to specify
this property somewhere in your container but that did not work for me); btw. use
forward slashes and escape colons
- When registering your services, set the property org.apache.cxf.rs.httpservice.context
to the path of your service (e.g. "/test") and do not use
org.apache.cxf.ws.address
- The cxf framework should then search and use the HTTPService provider, which
is in this case the pax web bundle
I'll update the DOSGi wiki a bit later with this information (by the
way, I believe you meant 'org.apache.cxf.ws.httpservice.context' as you
work with SOAP services, though the same advice will apply to rs services)
The only issue that I am facing at the moment is the logging of all the
components. CXF and pax web are all set to debug by default and I did not find
a way to change them yet. I tried to use pax logging and I tried to use a
fragment host with a log4j.properties file, but nothing worked. Does anybody
know what's the best option to configure the logging level for all the
different bundles?
Have a look at the Karaf docs:
http://karaf.apache.org/manual/2.2.5/users-guide/logging-system.html
Pax Logging should help somehow...
Cheers, Sergey
Cheers,
Sven
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: 07 February 2012 17:39
To: [email protected]
Subject: Re: Distributed OSGi: Maximum number of parallel requests == 24?
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
