ExecutorService

[mridul das]

There's a serversocket handling incoming request on a per thread basis. Each request is assigned a new Thread by submitting to the ExecutorService.
For argument sake say I create a ExecutorSevice with pool size 1. Executors.newFixedThreadPool(1). I submit all the incoming request to this.
Now the first request comes in and gets submitted to the Thread pool. During execution of this thread this calls the ServerSocket again. This is the portion
of the server code

ExecutorService tpes =   Executors.newFixedThreadPool(1);
public void run(){         
      while(!stop){
          try {
              final Socket socket = server.accept();
              Runnable r = new Runnable(){
                 public void run(){
                     try {
                         Socket s = new Socket("localhost",4000);
                         OutputStream ous = s.getOutputStream();
                         InputStream is = s.getInputStream();
                         
                     } catch (IOException e) {
                         e.printStackTrace(); 
                     }
                 }
              };              
              tpes.submit(r);
      }
}

When the server receives the second request, it tries to create another runnable object and submit it to the Thread Pool. But since the thread pool size is 1 this new thread never gets a chance to run.
And the first thread which initiated the process is still waiting for this thread to complete. Essentially there is a deadlock.
This is similar to a client calling a remote EJB which in turn will call another remote EJB in the same server.
Is there some way to get rid of this situation

[Stan James]

Old joke: A man comes to the Doctor holds his arm up at a strange angle and says "Doc, it hurts when I do this" and the Doctor says "Don't do that!"

No, I don't think you can expect the single Thread in the pool to stop running Runnable 1, run Runnable 2, then resume Runnable 1.

[Nitesh Kant]

This is similar to a client calling a remote EJB which in turn will call another remote EJB in the same server.

How is this a deadlock situation?

[Stan James]

I haven't seen an EJB calling an EJB deadlock. I have seen it crap out at max threads under load with a bottleneck (defect) in the code that initializes new beans. If you could set your max threads to 1 it would go bad - time out and throw an exception I think - every time.

I hope this is theoretical question ... a threading design with a max of 1 calls for some design review.