Summary: | java.net.bindException during shutdown in Tomcat 4.1.18 | ||
---|---|---|---|
Product: | Tomcat 4 | Reporter: | ankur <ankur_goel> |
Component: | Connector:Coyote JK 2 (deprecated) | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chris, Durgaprasad.Bhogadi, li1yang, mkrk, skeet |
Priority: | P3 | ||
Version: | 4.1.18 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | other |
Description
ankur
2003-02-19 07:05:16 UTC
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. |