Concurrent connections using Grizzly/Jersey

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Concurrent connections using Grizzly/Jersey

vivek
Hi,

We are embedding Grizzly in our code and are facing concurrent
connections in production. We are unable to scale beyond 7-8 concurrent
requests. I believe the problem lies in the way we are using Grizzly
and appreciate any help you can offer. I am able to replicate the
problem with the following sample code.

Please suggest what we are doing wrong and how can we use grizzly to
scale up to many more concurrent requests.

==========Main.java==========
import com.sun.grizzly.http.SelectorThread;
import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;
public class Main {
    public static void main(String[] args) throws InterruptedException
{
        Map<String, String> initParams=new HashMap<String, String>();
        initParams.put("com.sun.jersey.config.property.packages",
"com.test");
        try {
            SelectorThread threadSelector =
GrizzlyWebContainerFactory.create("http://localhost:8080/",
initParams);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}
========Default.java=========
package com.test;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;

@Path("{path:.*}")
public class Default {
    @GET
    @Produces( "text/plain" )
    public String getMessage() {
        try {
            // Adding sleep to simulate some background processing
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Hello World";
    }
}
=========================
Reply | Threaded
Open this post in threaded view
|

RE: Concurrent connections using Grizzly/Jersey

vivek
Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet 

GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]

> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================
Reply | Threaded
Open this post in threaded view
|

Re: Concurrent connections using Grizzly/Jersey

oleksiys
Administrator
Hi Vivek,

Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet
You're right, by increasing the thread-pool size you can increase number of requests Jersey/Grizzly will be able to process simultaneously.
Though it makes sense only if request processing is expensive (like in your case sleep(1000)), otherwise we recommend to keep thread-pool size = number of CPU/cores. It's similar to how Scott suggests to configure Glassfish [1], see "Tune the HTTP threads" section.

Also I'd not recommend to set
grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

it's going to disable HTTP keep-alive mechanism, which may have significant impact on server perf.

Thanks.

WBR.
Alexey.

[1] http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html


GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]
> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================

Reply | Threaded
Open this post in threaded view
|

RE: Concurrent connections using Grizzly/Jersey

vivek
Hi Alexey,

Thanks for the response.

Our threads make external web service calls and make some expensive DB queries. So, they are often in the waiting state like sleep(1000). We are testing the max threads under production load and trying to find the best number.

I looked around some Grizzly source code and noticed that there is an internal queue for managing requests which have not been allotted a thread. How can we configure the queue size and other queue properties?

Our application is behind haproxy load balancer, which disables keep alive. So, our Java app doesn't need to have keep alive. I disabled keep alive in Java as I believed that we will get performance gain since Haproxy when forwarding the request adds Connection: Close to the request.

Regards,
Vivek


Date: Fri, 21 Oct 2011 15:43:58 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet
You're right, by increasing the thread-pool size you can increase number of requests Jersey/Grizzly will be able to process simultaneously.
Though it makes sense only if request processing is expensive (like in your case sleep(1000)), otherwise we recommend to keep thread-pool size = number of CPU/cores. It's similar to how Scott suggests to configure Glassfish [1], see "Tune the HTTP threads" section.

Also I'd not recommend to set
grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

it's going to disable HTTP keep-alive mechanism, which may have significant impact on server perf.

Thanks.

WBR.
Alexey.

[1] http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html


GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]
> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================

Reply | Threaded
Open this post in threaded view
|

Re: Concurrent connections using Grizzly/Jersey

oleksiys
Administrator
Hi Vivek,

Our threads make external web service calls and make some expensive DB queries. So, they are often in the waiting state like sleep(1000). We are testing the max threads under production load and trying to find the best number.
I see.

I looked around some Grizzly source code and noticed that there is an internal queue for managing requests which have not been allotted a thread. How can we configure the queue size and other queue properties?
You mean the task queue, where threads picking up tasks from?
Please take a look at queueLimit parameter
http://grizzly.java.net/nonav/docs/docbkx2.0/html/core-config.html#threadpool-config

Though there is no clean way to set it up in Grizzly Web server 1.9.x.
Would you mind to switch to 2.x? Please check Jersey samples, they have Jersey + Grizzly 2.x samples as well.

Our application is behind haproxy load balancer, which disables keep alive. So, our Java app doesn't need to have keep alive. I disabled keep alive in Java as I believed that we will get performance gain since Haproxy when forwarding the request adds Connection: Close to the request.
haproxy disable keepalive in client <-> haproxy communication or haproxy <-> server? If earlier - then keep-alive still makes sense imo.

Thanks.

WBR,
Alexey.

Regards,
Vivek


Date: Fri, 21 Oct 2011 15:43:58 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet
You're right, by increasing the thread-pool size you can increase number of requests Jersey/Grizzly will be able to process simultaneously.
Though it makes sense only if request processing is expensive (like in your case sleep(1000)), otherwise we recommend to keep thread-pool size = number of CPU/cores. It's similar to how Scott suggests to configure Glassfish [1], see "Tune the HTTP threads" section.

Also I'd not recommend to set
grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

it's going to disable HTTP keep-alive mechanism, which may have significant impact on server perf.

Thanks.

WBR.
Alexey.

[1] http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html


GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]
> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================


Reply | Threaded
Open this post in threaded view
|

RE: Concurrent connections using Grizzly/Jersey

vivek
Hi Alexey,

Thanks. I will look at Grizzly 2.0 and will try that.

The keep-alive is enabled between client and haproxy, but is disabled between haproxy and grizzly. Haproxy and grizzly are on the same LAN (well, technically they are in EC2 VPC), so the connection is quite fast. Closing the connection lets us reuse threads on grizzly side. Also, we manipulate and load balance requests using haproxy, so we treat each request separately and can't enable a keep-alive directly from client to grizzly.

Vivek


Date: Mon, 24 Oct 2011 15:19:36 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Our threads make external web service calls and make some expensive DB queries. So, they are often in the waiting state like sleep(1000). We are testing the max threads under production load and trying to find the best number.
I see.

I looked around some Grizzly source code and noticed that there is an internal queue for managing requests which have not been allotted a thread. How can we configure the queue size and other queue properties?
You mean the task queue, where threads picking up tasks from?
Please take a look at queueLimit parameter
http://grizzly.java.net/nonav/docs/docbkx2.0/html/core-config.html#threadpool-config

Though there is no clean way to set it up in Grizzly Web server 1.9.x.
Would you mind to switch to 2.x? Please check Jersey samples, they have Jersey + Grizzly 2.x samples as well.

Our application is behind haproxy load balancer, which disables keep alive. So, our Java app doesn't need to have keep alive. I disabled keep alive in Java as I believed that we will get performance gain since Haproxy when forwarding the request adds Connection: Close to the request.
haproxy disable keepalive in client <-> haproxy communication or haproxy <-> server? If earlier - then keep-alive still makes sense imo.

Thanks.

WBR,
Alexey.

Regards,
Vivek


Date: Fri, 21 Oct 2011 15:43:58 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet
You're right, by increasing the thread-pool size you can increase number of requests Jersey/Grizzly will be able to process simultaneously.
Though it makes sense only if request processing is expensive (like in your case sleep(1000)), otherwise we recommend to keep thread-pool size = number of CPU/cores. It's similar to how Scott suggests to configure Glassfish [1], see "Tune the HTTP threads" section.

Also I'd not recommend to set
grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

it's going to disable HTTP keep-alive mechanism, which may have significant impact on server perf.

Thanks.

WBR.
Alexey.

[1] http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html


GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]
> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================


Reply | Threaded
Open this post in threaded view
|

Re: Concurrent connections using Grizzly/Jersey

oleksiys
Administrator
Hi Vivek,

The keep-alive is enabled between client and haproxy, but is disabled between haproxy and grizzly. Haproxy and grizzly are on the same LAN (well, technically they are in EC2 VPC), so the connection is quite fast.
Well, TCP connect/accept is relatively expensive anyways, IMO you may feel it on higher load.

Closing the connection lets us reuse threads on grizzly side.
Hmm, when connection is idle it doesn't occupy any thread in Grizzly.

Also, we manipulate and load balance requests using haproxy, so we treat each request separately and can't enable a keep-alive directly from client to grizzly.
IMO keeping connections alive is not directly related to load balancing or treating requests separately.
You can look at keep-alive feature as some low-level TCP connection cache, which is not even related to HTTP.

WBR,
Alexey.




Date: Mon, 24 Oct 2011 15:19:36 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Our threads make external web service calls and make some expensive DB queries. So, they are often in the waiting state like sleep(1000). We are testing the max threads under production load and trying to find the best number.
I see.

I looked around some Grizzly source code and noticed that there is an internal queue for managing requests which have not been allotted a thread. How can we configure the queue size and other queue properties?
You mean the task queue, where threads picking up tasks from?
Please take a look at queueLimit parameter
http://grizzly.java.net/nonav/docs/docbkx2.0/html/core-config.html#threadpool-config

Though there is no clean way to set it up in Grizzly Web server 1.9.x.
Would you mind to switch to 2.x? Please check Jersey samples, they have Jersey + Grizzly 2.x samples as well.

Our application is behind haproxy load balancer, which disables keep alive. So, our Java app doesn't need to have keep alive. I disabled keep alive in Java as I believed that we will get performance gain since Haproxy when forwarding the request adds Connection: Close to the request.
haproxy disable keepalive in client <-> haproxy communication or haproxy <-> server? If earlier - then keep-alive still makes sense imo.

Thanks.

WBR,
Alexey.

Regards,
Vivek


Date: Fri, 21 Oct 2011 15:43:58 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: Concurrent connections using Grizzly/Jersey

Hi Vivek,

Answering my own email. We were able to fix it and scale to 50 worker threads by using the following code snippet
You're right, by increasing the thread-pool size you can increase number of requests Jersey/Grizzly will be able to process simultaneously.
Though it makes sense only if request processing is expensive (like in your case sleep(1000)), otherwise we recommend to keep thread-pool size = number of CPU/cores. It's similar to how Scott suggests to configure Glassfish [1], see "Tune the HTTP threads" section.

Also I'd not recommend to set
grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

it's going to disable HTTP keep-alive mechanism, which may have significant impact on server perf.

Thanks.

WBR.
Alexey.

[1] http://weblogs.java.net/blog/sdo/archive/2007/12/a_glassfish_tun.html


GrizzlyWebServer grizzlyWebServer = new GrizzlyWebServer(8080);

grizzlyWebServer.getSelectorThread().setMaxKeepAliveRequests(0);

grizzlyWebServer.setCoreThreads(30);

grizzlyWebServer.setMaxThreads(50);

ServletAdapter jerseyAdapter = new ServletAdapter();

jerseyAdapter.addInitParameter("com.sun.jersey.config.property.packages", "com.test");

jerseyAdapter.setServletInstance(new ServletContainer());

grizzlyWebServer.addGrizzlyAdapter(jerseyAdapter, new String[]{"/"});

grizzlyWebServer.start();


Please let me know if we can embed grizzly while using jersey in a better way.


Thanks,

Vivek



> To: [hidden email]
> From: [hidden email]
> Subject: Concurrent connections using Grizzly/Jersey
> Date: Thu, 20 Oct 2011 21:18:11 +0000
>
> Hi,
>
> We are embedding Grizzly in our code and are facing concurrent
> connections in production. We are unable to scale beyond 7-8 concurrent
> requests. I believe the problem lies in the way we are using Grizzly
> and appreciate any help you can offer. I am able to replicate the
> problem with the following sample code.
>
> Please suggest what we are doing wrong and how can we use grizzly to
> scale up to many more concurrent requests.
>
> ==========Main.java==========
> import com.sun.grizzly.http.SelectorThread;
> import com.sun.jersey.api.container.grizzly.GrizzlyWebContainerFactory;
> import java.io.IOException;
> import java.util.HashMap;
> import java.util.Map;
> public class Main {
> public static void main(String[] args) throws InterruptedException
> {
> Map<String, String> initParams=new HashMap<String, String>();
> initParams.put("com.sun.jersey.config.property.packages",
> "com.test");
> try {
> SelectorThread threadSelector =
> GrizzlyWebContainerFactory.create("http://localhost:8080/",
> initParams);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> }
> ========Default.java=========
> package com.test;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
>
> @Path("{path:.*}")
> public class Default {
> @GET
> @Produces( "text/plain" )
> public String getMessage() {
> try {
> // Adding sleep to simulate some background processing
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return "Hello World";
> }
> }
> =========================