> -----Original Message----- > From: Daniel Mikusa [mailto:dmik...@vmware.com] > Sent: Wednesday, September 12, 2012 2:14 PM > To: Tomcat Users List > Subject: Re: HTTP NIO connector not supporting IPv6 > > On Sep 12, 2012, at 2:44 PM, Jeffrey Janner wrote: > > >> -----Original Message----- > >> From: Daniel Mikusa [mailto:dmik...@vmware.com] > >> Sent: Wednesday, September 12, 2012 10:00 AM > >> To: Tomcat Users List > >> Subject: Re: HTTP NIO connector not supporting IPv6 > >> > >> On Sep 12, 2012, at 1:29 AM, Aditi Sinha wrote: > >> > >>> Thanks Dan, Jeff. > >>> > >>> > >>> > >>> There are no errors in catalina.log file. > >>> > >>> The connector tags are defined as below in server.xml. This > >>> configuration does not support IPv6. > >>> > >>> > >>> <Connector port="8080" protocol="*HTTP/1.1*" > >> connectionTimeout="20000" > >>> redirectPort="8443" /> > >>> > >>> > >>> > >>> <Connector port="8443" protocol="* > >>> org.apache.coyote.http11.Http11NioProtocol*" SSLEnabled="true" > >>> maxThreads="150" > >>> > >>> scheme="https" secure="true" clientAuth="false" > >> sslProtocol="TLS" > >>> keystoreFile="xxxxxx" keystorePass="xxxxxx"/> > >>> > >> > >> Tried it on my MBP (10.7 w/Java 1.6.0_35) and it worked fine. Tried > >> on Windows XP (only version I have available) w/ Java 1.6.0_35 and > >> was able to replicate the problem behavior. According to the > >> following bug report this is a limitation of the OS / JVM. Looks > >> like a recent versions of Windows and a recent version of the JVM > are > >> required to resolve this. > >> > >> Try upgrading from 1.6.0_25 to 1.6.0_35. > >> > >> http://bugs.sun.com/view_bug.do?bug_id=6230761 > >> > >> Dan > >> > > One workaround is to explicitly define the IPv4 and IPv6 addressing > in the <connector>. > > That is, add address="0.0.0.0" for any IPv4 connectors and > > address="[::]" for any IPv6 connectors. (Or use your real addresses > instead of the "any" addresses listed here.) This means setting up 2 > sets of connectors for each port/protocol, but there's nothing wrong > with being explicit. > > This is what I had to do to get the APR protocol to set up for IPv4. > > > With all due respect, I do not think that this is going to work for the > poster. You're saying that your workaround was for an issue with the > APR connector, but the poster is using the NIO connector. The APR > connector does not use NIO or the JVM, so I don't think your workaround > is relevant. In fact I tried your workaround previously without > success. The problem is that on older versions of Windows (pre-vista) > and older versions of the JVM, the NIO libraries do not support IPv6 > (see bug report). > > As a side note, the poster could switch from NIO to the APR connector, > and it would likely resolve his problem (just like he reported > switching to the BIO connector resolved his problem). Just assuming > that the poster wants to stick with the NIO connector. > > Dan >
Yes, Dan. But the OP stated he is using Windows Server 2008, which is the server version of "Vista". Since he doesn't say he's on 2008 R2 (which is Windows 7 Server), so we'll assume that he's at least at a Vista-level networking. The bug you mention is specifically about dual-mode socket support, that is, being able to specify the port and not the address and having Java set up to sockets which listen/talk on both the IPv4 & IPv6 addresses of the machine. At least if I read it correctly. Re-reading it, it might not be there for NIO, no matter what you try. My work-around would specifically show whether the support is there or not for IPv6 in NIO, i.e., use it as a diagnostic tool, if nothing else. But yes, reading the bug, really closely, makes it appear that the support for NIO IPv6 was not back-ported to JDK6 until this last July, specifically 6u33-b34. So the OP should probably start up upgrading his Java to jdk1.6_34 or later and see if that doesn't fix it first. Personally, I prefer the APR to NIO, but mainly because SSL is easier to manage under APR. I believe there are some esoteric advantages to using NIO, but I'd have to go back to the comparison chart to tell you what they are. The OP may have a specific use case that requires those features. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
