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 <[EMAIL PROTECTED]> 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: > > > >> [EMAIL PROTECTED] > > > >> > For additional commands, e-mail: > > > >> > [EMAIL PROTECTED] > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
