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 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? 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
