cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: Releasing 2.1.1?
Date Fri, 29 Aug 2003 20:18:40 GMT
On Fri, 2003-08-29 at 19:55, Giacomo Pati wrote:
> On Fri, 29 Aug 2003, Bruno Dumon wrote:
> 
> > For me it works with Linux/Sun jdk 1.4.2, it doesn't work with 1.3.1.
> > For Carsten it doesn't work with Windows/jdk 1.4 either. I've done all
> > my testing with the Jetty which ships with Cocoon.
> >
> > I've added some println's here and there and it appears that, with
> > 1.3.1, the CommandManager starts working but stops as soon as Jetty
> > prints out the following lines:
> > Fri Aug 29 13:58:07 CEST 2003 Listening for connections ...
> > 13:58:07.575 EVENT  Started SocketListener on 0.0.0.0:8888
> 
> I have the above also in with sun jdk 1.4.2 on Linux.

It's probably a coincidence. If you supply a higher value for the
"sleep-time" parameter of the CommandManager, for example 1000 ms, it
will probably keep working for you too (with 1.3 also).

I think the problem lies somewhere in the PooledExecutor and/or
SynchronousChannel classes from the concurrent package.

If you take a look at the PooledExecutor class, there's a getTask method
that is called by worker threads (see the inner class Worker). Shortly
before jetty binds to port 8888 it probably does something cpu
intensive, causing the poll(sleep-time) call in the getTask method to
timeout, and the getTask() method to return null, which in itself causes
the worker thread to be released. More or less at the same time, the
PooledExecutor is asked to execute another runnable but it thinks no
threads are available anymore and "hands off" the runnable to the
SynchronousChannel. How it then needs to get out of that situation is
currently still a mystery for me... 


ok, 10 minutes later now, got an idea:

if you add the following code before the closing bracket of the
PooledExecutor.workerDone(...) method, then it --seems to-- work:

    if (!shutdown_) {
      if (poolSize_ < maximumPoolSize_) {
        Runnable r= null;
        try {
          r = getTask();
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
        if (r != null)
          addThread(r);
      }
    }

Could someone else also try this out? For your convenience, here's a
compiled jar with this change:
http://outerthought.net/~bruno/concurrent.jar

just copy it over the util.concurrent-1.3.1.jar


> 
> > It seems that the thread that was executing the commands is somehow not
> > released (or whathever), so when the ThreadManager wants to execute the
> > next command it keeps waiting for a thread to be released (this waiting
> > happens in Doug Lea's Executor). If the "threads-per-processor"
> > parameter is augmented to "2", then it keeps working.
> 
> Have not tried using a second Thread.
> 
> >
> > According to Giacomo, the CommandManager works just fine in a
> > non-servlet environment.
> 
> Right.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message