hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Synapse not able to send request to jboss server + solaris 5.9
Date Fri, 06 Jul 2007 16:40:30 GMT
On Fri, 2007-07-06 at 12:25 -0400, Sam Berlin wrote:
> If I can suggest a possible problem without actually looking or
> knowing the code at all...
> 
> Based on the symptons that it works from one OS to another, but
> doesn't work within the same OS, and that the sample code was using
> selector.select(0), selector.selectNow, and SelectionKey.OP_CONNECT...
> 
> Could the problem be that when the SocketChannel.connect is called, it
> is returning "true" (already connected), meaning that it does not need
> to go through the Selector at all?  I do not know if there is code
> that handles this case, or if this is even the place where something
> is going wrong, but it is a very likely and possible scenario, and is
> something we've often encountered when doing localhost tests.  What it
> boils down to is that when a SocketChannel.connect is called, it can
> either return false (meaning it has to be added to the selector and
> wait for an OP_CONNECT event), or true (meaning it is now connected
> and finishConnect doesn't even need to be called).  On localhost, it
> is very likely that connecting will immedaitely work.
> 

Hi Sam

This sounds very plausible. Presently DefaultConnectingIOReactor does
not check the return value of the socketChannel#connect() method. This
can well be it.

Thanks a million for this hint.

Oleg

> Sam
> 
> On 7/6/07, Oleg Kalnichevski <olegk@apache.org> wrote:
> > On Fri, 2007-07-06 at 08:56 -0700, balaji hari wrote:
> > > Oleg,
> > >
> > > Actually in DefaultConnectingIOReactor.processSessionRequests
> > >
> > > after this code segment
> > >
> > > SessionRequestHandle requestHandle = new SessionRequestHandle(request);
> > > key.attach(requestHandle);
> > > key.interestOps(SelectionKey.OP_CONNECT);
> > >
> > > we tried
> > >
> > > this.selector.select(0)
> > > this.selector.selectedKeys()
> > >
> > > This doesn't help!
> > >
> > > thanks
> > > Balaji
> > >
> >
> > All right. So, this one is not going to be easy. I need a little more
> > info about what is going on under hood to try to pinpoint the problem.
> > Could you please copy these classes from HttpCore contrib package [1],
> > patch your test code to use LoggingClientIOEventDispatch instead of
> > DefaultClientIOEventDispatch and turn on debug logging by passing the
> > following parameters to the JVM?
> >
> > -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog -Dorg.apache.commons.logging.simplelog.log.org.apache.http=DEBUG
> >
> > Oleg
> >
> > [1]
> > http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/tags/4.0-alpha5/contrib/src/main/java/org/apache/http/contrib/logging/
> >
> >
> > >
> > > olegk wrote:
> > > >
> > > > On Fri, 2007-07-06 at 07:29 -0700, balaji hari wrote:
> > > >
> > > > ...
> > > >
> > > >> > The above seems quite confusing to me.. If the sample code you
provide
> > > >> > can talk to an external Windows server, I don't see any reason
why it
> > > >> > cant talk to a Solaris server? Just to be certain.. do you have
any
> > > >> > firewalls or other software between the two boxes? Can you do
a "telnet
> > > >> > <solarishost> <httpport>" from the command line and
then a "GET /
> > > >> > HTTP/1.1" and see if you get some response back?
> > > >> >
> > > >> >
> > > >> ----------------------------------------------------------------------------------------------
> > > >> > No firewall issues, as we are able to do a telnet from solaris
box to
> > > >> the
> > > >> > server running on localhost
> > > >> > and able to retrieve response. This is how results look like
> > > >> >
> > > >> > solaris -> windows - yes
> > > >> > windows -> solaris - yes
> > > >> > solaris -> solaris (localhost) - no (synapse and jboss server
sitting
> > > >> on
> > > >> > the same machine can't talk to each other)
> > > >> >
> > > >
> > > > Very peculiar.
> > > >
> > > >>
> > > >> > Not sure what the problem could be other than with NIO (because
using
> > > >> > commons-httpclient API we are able to communicate to server running
in
> > > >> > solaris)
> > > >> >
> > > >> > This is the code segment from
> > > >> > org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.java
> > > >> >
> > > >> > try {
> > > >> >                 readyCount =
> > > >> this.selector.select(TIMEOUT_CHECK_INTERVAL);
> > > >> >             } catch (InterruptedIOException ex) {
> > > >> >                 throw ex;
> > > >> >             } catch (IOException ex) {
> > > >> >                 throw new IOReactorException("Unexpected selector
> > > >> > failure", ex);
> > > >> >             }
> > > >> >
> > > >> >             if (this.closed) {
> > > >> >                 break;
> > > >> >             }
> > > >> >
> > > >> >             processSessionRequests();
> > > >> >
> > > >> >             if (readyCount > 0) {
> > > >> >                 processEvents(this.selector.selectedKeys());
> > > >> >             }
> > > >> >
> > > >> > Even though
> > > >> >
> > > >> > key = socketChannel.register(this.selector, 0);
> > > >> >
> > > >> > returns a valid selector key, the select() method returns count
= 0.
> > > >> >
> > > >
> > > > This looks like a bug in Sun Solaris NIO implementation to me. However,
> > > > if just ignoring the readyCount value helps work the problem around I
do
> > > > not see a problem with including it into HttpCore.
> > > >
> > > > Could you please try patching the latest snapshot locally on a Solaris
> > > > 2.9 box and see if you can get the test suite pass successfully?
> > > >
> > > > Oleg
> > > >
> > > >>
> > > >> >
> > > >> ---------------------------------------------------------------------------------------------
> > > >> >
> > > >> >
> > > >> > Lets give this problem the due attention it deserves and try
to find
> > > >> its
> > > >> > root cause.
> > > >> >
> > > >> >
> > > >> >
> > > >> > Hope this helps.
> > > >> >
> > > >> > thanks
> > > >> > Balaji
> > > >> >
> > > >> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail:
> > > >> httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > >> > For additional commands, e-mail:
> > > >> > httpcomponents-dev-help@jakarta.apache.org
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > > httpcomponents-dev-help@jakarta.apache.org
> > > >
> > > >
> > > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message