You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Piyush Purang <pp...@gmail.com> on 2006/01/11 12:16:19 UTC
[MINA] Need some enlightenment ...
I have been trying to quickly integrate MINA into a small project that
i have undertaken.
I decided to use the HTTPProtocolHandler example as my guide. So in
the run method of my Worker thread I have these two lines of code tha
basically try and read all of the request at one go. (Is that
adviced?)
--- codesnippet 1
try {
Reader reader = new InputStreamReader(new
BufferedInputStream(in), IOUtils.UTF_8);
String request = IOUtils.read(reader,
IOUtils.DEFAULT_EOF_CHARACTER);
--- /codesnippet 1
The utility method read from the utility class IOUtils is as follows....
--- codesnippet2
public static final String read(Reader reader, char eofChar)
throws IOException {
if(reader == null)
throw new IllegalArgumentException("Reader can't be null!");
char[] buffer = new char[BUFFER_CAPACITY];
StringWriter stringCapture = new StringWriter(BUFFER_CAPACITY);
LOGGER.trace("Beginning capture of input stream content...");
long timeStart = System.currentTimeMillis();
for (boolean eof = false; !eof;) {
// it makes sense to try and read the reader iff it is ready to be
// read!
if (reader.ready()) {
LOGGER.trace("Reader is ready to be read!");
int amount = 0;
if ((amount = reader.read(buffer)) > 0) {
char pop = buffer[amount - 1];
if (pop == eofChar) {
LOGGER.trace("Encountered eof charachter.");
eof = true;
LOGGER.trace("Writing amount = " + (amount - 1));
stringCapture.write(buffer, 0, amount - 1);
} else {
LOGGER.trace("Writing amount = " + amount);
stringCapture.write(buffer, 0, amount);
}
stringCapture.flush();
}
LOGGER.trace("Read " + amount + " bytes");
}
}
LOGGER.trace("Completed capturing input stream content in ["
+ ((System.currentTimeMillis() - timeStart) / 1000) + "s].");
return stringCapture.toString();
}
--- /codesnippet2
The client uses simple java sockets to connect with the server and
uses java.io classes in conjunction with IOUtils to write(which writes
the eof character as the last byte) and read content.
Running the server and client (individual java VMs) leads to odd
behaviour.. Most of the attempts at running them end up in both server
and client hanging up with CPU at 50+% .. obviously both of them are
trapped in the for loop of the read method ..
--- server log
0 [main] DEBUG de.cgs.vwtools.monitor.server.Server - Listening on port 33333
6453 [IoThreadPool-1] DEBUG de.cgs.vwtools.monitor.server.Server -
/127.0.0.1:1746
6453 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils -
Beginning capture of input stream content...
6906 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils - Reader
is ready to be read!
--- client log
0 [Thread-3] DEBUG de.cgs.vwtools.client.applets.CpuApplet - writing
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cpuRequest className="de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler"
xmlns="http://cgs.de/vwtools/monitor/cpu/handler"><retreiveSnapshot
xmlns=""><dateTo>1136976270671</dateTo></retreiveSnapshot></cpuRequest>
16 [Thread-3] DEBUG de.cgs.vwtools.monitor.server.IOUtils - wrote 275
16 [Thread-3] DEBUG de.cgs.vwtools.client.applets.CpuApplet - Waiting
to read the response.
16 [Thread-3] DEBUG de.cgs.vwtools.monitor.server.IOUtils - Beginning
capture of input stream content...
But sometimes just sometimes ...
--- sever log
0 [main] DEBUG de.cgs.vwtools.monitor.server.Server - Listening on port 33333
14703 [IoThreadPool-1] DEBUG de.cgs.vwtools.monitor.server.Server -
/127.0.0.1:1779
14750 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils -
Beginning capture of input stream content...
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils - Reader
is ready to be read!
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils -
Encountered eof charachter.
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils -
Writing amount = 274
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils - Read 275 bytes
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.IOUtils -
Completed capturing input stream content in [0s].
15125 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.Server - Request
captured: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cpuRequest className="de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler"
xmlns="http://cgs.de/vwtools/monitor/cpu/handler"><retreiveSnapshot
xmlns=""><dateTo>1136976475190</dateTo></retreiveSnapshot></cpuRequest>
15735 [Thread-2] DEBUG de.cgs.vwtools.monitor.server.RequestDispatcher
- Dispatching request to
de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler
15735 [Thread-2] DEBUG
de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler - Processing
request<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cpuRequest className="de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler"
xmlns="http://cgs.de/vwtools/monitor/cpu/handler"><retreiveSnapshot
xmlns=""><dateTo>1136976475190</dateTo></retreiveSnapshot></cpuRequest>
15781 [Thread-2] DEBUG
de.cgs.vwtools.monitor.cpu.handler.CpuRequestHandler - Retreiving
snapshots.
Of course the client log doesn't differ too much from the unsuccessful attempt.
What I can't understand is why this startegy sometimes (rather seldom)
succeeds and most of the times fails?
And another question would of course be how can I rectify this?
When server and client both use IOUtills with reading and writing
directly to socket streams things work out rather nicely.
Thanks for any comments, questions, suggestions etc.
Cheers
Piyush
Re: [MINA] Need some enlightenment ...
Posted by Trustin Lee <tr...@gmail.com>.
It seems like you didn't capture the thread dump when the CPU usage is 100%,
right? The dump looks very normal.
I found that Reader.ready() is a non-blocking operation. If the data
doesn't come in immediately, the read loop will consume a lot of CPU until
the data is ready. So I guess this is not a MINA problem.
Trustin
2006/1/13, Piyush Purang <pp...@gmail.com>:
>
> Hi Trustin,
>
> Thanks for looking into my problem. I am attaching thread dumps taken
> at different time points of the running system (server in one VM and
> client in another..bombarding the server with requests that are mostly
> dropped/ignored .. client also refuses to accept the response most of
> the time.. though I did saw atleast once when it (client) did receive
> something that the server had written out as response.)
>
> Hope this helps. I couldn't find anything suspicious in the thread
> dump. Certainly no deadlocks. (I also monitored the two jvms using
> jconsole for an extended period of time).
>
> Cheers
> Piyush
>
> On 1/13/06, Trustin Lee <tr...@gmail.com> wrote:
> > Hi Piyush,
> >
> > 2006/1/11, Piyush Purang <pp...@gmail.com>:
> > > I have been trying to quickly integrate MINA into a small project that
> > > i have undertaken.
> > >
> > > I decided to use the HTTPProtocolHandler example as my guide. So in
> > > the run method of my Worker thread I have these two lines of code tha
> > > basically try and read all of the request at one go. (Is that
> > > adviced?)
> >
> > <snip/>
> >
> > > Of course the client log doesn't differ too much from the unsuccessful
> > attempt.
> > >
> > > What I can't understand is why this startegy sometimes (rather seldom)
> > > succeeds and most of the times fails?
> > >
> > > And another question would of course be how can I rectify this?
> > >
> > > When server and client both use IOUtills with reading and writing
> > > directly to socket streams things work out rather nicely.
> > >
> > > Thanks for any comments, questions, suggestions etc.
> >
> > Why don't you give us the full thread dump? It will clarify which
> component
> > is responsible for this problem.
> >
> > Thanks,
> > Trustin--
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > PGP Key ID: 0x854B996C
>
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
Re: [MINA] Need some enlightenment ...
Posted by Piyush Purang <pp...@gmail.com>.
Hi Trustin,
Thanks for looking into my problem. I am attaching thread dumps taken
at different time points of the running system (server in one VM and
client in another..bombarding the server with requests that are mostly
dropped/ignored .. client also refuses to accept the response most of
the time.. though I did saw atleast once when it (client) did receive
something that the server had written out as response.)
Hope this helps. I couldn't find anything suspicious in the thread
dump. Certainly no deadlocks. (I also monitored the two jvms using
jconsole for an extended period of time).
Cheers
Piyush
On 1/13/06, Trustin Lee <tr...@gmail.com> wrote:
> Hi Piyush,
>
> 2006/1/11, Piyush Purang <pp...@gmail.com>:
> > I have been trying to quickly integrate MINA into a small project that
> > i have undertaken.
> >
> > I decided to use the HTTPProtocolHandler example as my guide. So in
> > the run method of my Worker thread I have these two lines of code tha
> > basically try and read all of the request at one go. (Is that
> > adviced?)
>
> <snip/>
>
> > Of course the client log doesn't differ too much from the unsuccessful
> attempt.
> >
> > What I can't understand is why this startegy sometimes (rather seldom)
> > succeeds and most of the times fails?
> >
> > And another question would of course be how can I rectify this?
> >
> > When server and client both use IOUtills with reading and writing
> > directly to socket streams things work out rather nicely.
> >
> > Thanks for any comments, questions, suggestions etc.
>
> Why don't you give us the full thread dump? It will clarify which component
> is responsible for this problem.
>
> Thanks,
> Trustin--
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> PGP Key ID: 0x854B996C
Re: [MINA] Need some enlightenment ...
Posted by Trustin Lee <tr...@gmail.com>.
Hi Piyush,
2006/1/11, Piyush Purang <pp...@gmail.com>:
>
> I have been trying to quickly integrate MINA into a small project that
> i have undertaken.
>
> I decided to use the HTTPProtocolHandler example as my guide. So in
> the run method of my Worker thread I have these two lines of code tha
> basically try and read all of the request at one go. (Is that
> adviced?)
<snip/>
Of course the client log doesn't differ too much from the unsuccessful
> attempt.
>
> What I can't understand is why this startegy sometimes (rather seldom)
> succeeds and most of the times fails?
>
> And another question would of course be how can I rectify this?
>
> When server and client both use IOUtills with reading and writing
> directly to socket streams things work out rather nicely.
>
> Thanks for any comments, questions, suggestions etc.
Why don't you give us the full thread dump? It will clarify which component
is responsible for this problem.
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C