Jerry,
On 11/30/21 14:17, Jerry Malcolm wrote:
Chris, Thanks for the response.
Sorry... forgot to include the TC ver -- 8.5.69.
I had a situation a while back where I spun a longrunning thread and
held the request object after the main response was returned. I fixed
that situation. In this situation, it is occurring on the main
request/response thread. Is there any situation where the request
object could be recycled before the associated response is returned?
Not usually. So the thread hitting the NPE is something like
[catalina-exec- ...]?
And you are sure you aren't doing anything funny with the request
object? No storing it in the session or getting a reference from some
cross-thread storage mechanism?
Looking at the code
(https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/connector/Request.java#L2465):
@Override
public StringBuffer getRequestURL() {
StringBuffer url = new StringBuffer();
String scheme = getScheme();
int port = getServerPort();
if (port < 0)
{
port = 80; // Work around java.net.URL bug
}
url.append(scheme);
url.append("://");
url.append(getServerName());
if ((scheme.equals("http") && (port != 80))
|| (scheme.equals("https") && (port != 443))) {
url.append(':'); // <<<< This is line 2465
url.append(port);
}
url.append(getRequestURI());
return url;
}
I don't see how an NPE could happen on that line.
But 8.5.69 was released on 2021-07-05, and that code is here:
https://github.com/apache/tomcat/blob/3e9dd49b20f9d6e270f8709d4f16d5595977595e/java/org/apache/catalina/connector/Request.java
This makes a little more sense:
@Override
public StringBuffer getRequestURL() {
StringBuffer url = new StringBuffer();
String scheme = getScheme();
int port = getServerPort();
if (port < 0)
{
port = 80; // Work around java.net.URL bug
}
url.append(scheme);
url.append("://");
url.append(getServerName());
if ((scheme.equals("http") && (port != 80)) // <<< This is 2465
|| (scheme.equals("https") && (port != 443))) {
url.append(':');
url.append(port);
}
url.append(getRequestURI());
return url;
}
So the scheme is null. That's odd, since getScheme is:
public String getScheme() {
return coyoteRequest.scheme().toString();
}
Oh, but coyoteRequest.scheme() returns a MessageBytes object whose
toString method can (somewhat surprisingly) return null(!) when the type
is T_NULL. And wouldn't you know it, here is the code for
MessageBytes.recycle() (which gets called whenever the request, and
therefore all of the various parts of the request, is recycled):
public void recycle() {
type=T_NULL;
byteC.recycle();
charC.recycle();
strValue=null;
hasStrValue=false;
hasHashCode=false;
hasLongValue=false;
}
So it definitely looks like your request has been recycled somehow.
-chris
On 11/29/2021 7:42 PM, Christopher Schultz wrote:
Jerry,
On 11/29/21 19:33, Jerry Malcolm wrote:
Can anyone tell me what I might be doing that would cause an NPE
inside the request object on getRequestURL()? The NPE only happens
about 10% of the time. I can't figure out what is happening
differently in that 10% of the calls to this code. Thx
java.lang.NullPointerException
at
org.apache.catalina.connector.Request.getRequestURL(Request.java:2465)
at
org.apache.catalina.connector.RequestFacade.getRequestURL(RequestFacade.java:868)
Thoughts:
1. Tomcat version?
2. Retained reference to request object that has been recycled?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
