Following error was encountered while shutdown, i m giving complete log message from startup to shutdown [INFO] Registry - -Loading registry information [INFO] Registry - -Creating new Registry instance [INFO] Registry - -Creating MBeanServer [INFO] Http11Protocol - -Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/4.1.18 [INFO] Http11Protocol - -Starting Coyote HTTP/1.1 on port 8080 [INFO] ChannelSocket - -JK2: ajp13 listening on 0.0.0.0/0.0.0.0:8009 [INFO] JkMain - -Jk running ID=0 time=10/100 config=d:\Tomcat 4.1.18 \conf\jk2.properties Stopping service Tomcat-Standalone java.net.BindException: Cannot assign requested address: connect at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:350) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:137) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:124) at java.net.Socket.<init>(Socket.java:268) at java.net.Socket.<init>(Socket.java:122) at org.apache.jk.common.ChannelSocket.destroy(ChannelSocket.java:417) at org.apache.jk.server.JkMain.stop(JkMain.java:308) at org.apache.jk.server.JkCoyoteHandler.destroy (JkCoyoteHandler.java:179) at org.apache.coyote.tomcat4.CoyoteConnector.stop (CoyoteConnector.java:1081) at org.apache.catalina.core.StandardService.stop (StandardService.java:546) at org.apache.catalina.core.StandardServer.stop (StandardServer.java:2224) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run (Catalina.java:624) what i figured out by looking at the code of "ChannelSocket.java" was that in method "init" of class "ChannelSocket" the following code if (getAddress() == null) setAddress("0.0.0.0"); is setting 'inet' variable to address 0.0.0.0, which is creating problems at the time of shutdown when method "destroy" is called and a new socket creation is tried which results in the above mentioned "Bind Exception"... if (inet == null) { s=new Socket("127.0.0.1", port ); }else{ s=new Socket(inet, port ); // setting soLinger to a small value will help shutdown the // connection quicker s.setSoLinger(true, 0); }
nobody seems to be interested in resolving this bug!!!
Fixed in CVS, next release of jk2 will probably have it.
Hi, We have the same issue here. If our customer does't want to reinstall Tomcat, how should we install the new fix? Is there a patch for this bug? Any information will be apprecicated. Thanks, -li1yang
The current stable release (4.1.24) of Tomcat does not fix this bug. Is there a patch available? How to build it? Simply replacing tomcat-jk2.jar with the one in Tomcat 5.0.2 (dated May 3rd) does not work.
This is still occuring in Tomcat 4.1.24 Bug 19098 seems to be a duplicate of this, but the resolution isn't helpful.
*** Bug 17702 has been marked as a duplicate of this bug. ***
*** Bug 19098 has been marked as a duplicate of this bug. ***
Is there any actual movement on this? I could really do with a fix for it, and am willing to put some work in myself, but in order to fix the bug I'd have to know where the source for tomcat-jk.jar itself is, I suspect - and I can't find that... It's not in the Tomcat 4.1.27 source distribution - where does it come from?
Right. This doesn't look like it's been fixed in CVS at all, as far as I can see - Costin, can you remember why you made the comment you did? (The original comment about the cause of the problem is spot on.) I'm using Tomcat 4.1.27, and have modified the source locally just to check whether inet.toString().equals ("0.0.0.0/0.0.0.0") and use 127.0.0.1 if so. That doesn't feel like a good fix to me, however - I don't like comparing the contents of .toString with anything else. Do we know why inet is being set to 0.0.0.0 in the first place? Is there anything wrong with leaving it as null, but using an inet address of 0.0.0.0 in init instead? Really, this is a question of whether other classes will assume that inet is going to have a non-null value. (It's got package protection, so is available from other classes.) I don't think I know enough about jk2 to fix this *properly* myself, though I may well be able to fix it well enough to make do for the installations I'll be using it with (eg no JMX etc). I certainly need to get it cleared up to *some* extent before I can ship Tomcat 4.1 with our product. Does anyone with a bit more knowledge (not saying much :) fancy commenting on this, or shall I implement my own somewhat hacky solution for my own private use? (I really don't think I could come up with one I'd be happy enough to submit as a patch.)
AFAIKT this was fixed for the 2.0.4 release of jk2. See http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat- connectors/jk/java/org/apache/jk/common/ChannelSocket.java? r1=1.44&r2=1.45&diff_format=h There has not been a TC4 release since this date. TC5.0.20 or later will include it.