RE: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.

[Alfred Bakia]

Thanks, Jon.
I did in fact compare all the settings between the servers, including the 
logging settings. They are exactly the same. 

But there is new information. In a detailed comparison of the Java code between 
the servers, I spotted one difference. Something sets apart the instance that 
is logging the Warning "AJP13 protocol: Reuse is set to false". The instance 
includes a REST API. As Sherlock Holmes said, "When you have eliminated all 
which is impossible, then whatever remains, however improbable, must be the 
truth." 

I am now looking into how the combination REST - Tomcat - IIS can trigger the 
warning.

Regards,

Alfred


-Oorspronkelijk bericht-
Van: jonmcalexan...@wellsfargo.com.INVALID 
 
Verzonden: 11 June 2020 23:57
Aan: users@tomcat.apache.org
Onderwerp: RE: Warning "AJP13 protocol: Reuse is set to false" written logs 
every second of every day. Please help.

Perhaps also compare your logging sensitivity between the servers.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

-Original Message-
From: Christopher Schultz 
Sent: Thursday, June 11, 2020 12:55 PM
To: users@tomcat.apache.org
Subject: Re: Warning "AJP13 protocol: Reuse is set to false" written logs every 
second of every day. Please help.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alfred,

On 6/11/20 11:57, Alfred Bakia wrote:
> Hi Everyone,
>
> This is my very first mail to the users list since joining yesterday. 
> Not an auspicious start. But I hope I will be able to contribute in 
> future. I seek your help for a persistent issue in one of our 
> ColdFusion instances.
>
> Description of issue: ColdFusion 2018 is an application server that 
> uses Tomcat 9.0.21. Our ColdFusion installation consists of instances.
> The instances are independent application servers, each with its own 
> Tomcat installation and Java Virtual Machine. The Java version is 
> 11.0.7.
>
> Each ColdFusion instance serves web content via the web server IIS.
> We have configured an AJP connector for the communication between 
> Tomcat and IIS. The relevant settings are
>
>
> *   In server.xml
>
>  redirectPort="8445" protocol="AJP/1.3" tomcatAuthentication="false"
> maxThreads="500" packetSize="65535"/>
>
>
> *   In isapi_redirect.properties
>
> iis_buffer_enable= true
>
>
> *   In workers.properties
>
> worker.list=sr1studierdr1
>
> worker.sr1studierdr1.type=ajp13
>
> worker.sr1studierdr1.host=localhost
>
> worker.sr1studierdr1.port=8012
>
> worker.sr1studierdr1.connection_pool_size=800
>
> worker.sr1studierdr1.connection_pool_timeout=60
>
> worker.sr1studierdr1.max_reuse_connections=400''
>
> On one of the instances (name: 'sr1studierdr1'), the following WARNING 
> is written to isapi_redirect.log every second or so:
>
>
> *   [Thu Jun 11 16:44:57.739 2020] [11308:15392] [warn]
> ajp_process_callback::jk_ajp_common.c (2242): (sr1studierdr1) AJP13
> protocol: Reuse is set to false
>
> Nevertheless, the application seems to work as intended.
>
> We're at a loss why this is happening only to this particular 
> instance. There are no such warnings in other instances that share 
> exactly the same settings.
>
> Do you know what is causing the warning, "AJP13 protocol: Reuse is set 
> to false", or how to solve this?

I have no idea, but Google seemed able to come up with this:

https://forums.iis.net/t/1229345.aspx?Error+AJP13+protocol+Reuse+is+set+
to+false+on+log+file+

Does that help at all?

Apache httpd configuration of mod_jk has a DisableReuse flag that can be set, 
but I don't see such a thing for IIS.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ib9wACgkQHPApP6U8
pFiTzxAAljUf3DhO5zCex044toYxhtsrjb0ARCpFggrOXWiKBHHAyvnsMe/d1CFb
Tp5BLQdoWD1qorCkXMvFAYAdFOcbgmxMuUb3dkyHiq9JMZxINz3vOUXGtyqKfTLd
IT8VZ+kUSUq3brcoqMdkCNNpILAVNprtwCJdMoPSilVufG2vksjbBS2PT6YzSsXS
EaOb138vVb82HA6vvtOsi9EbOvh1cRVhZ2sIQlvrYsoTjeRD4QmRbmIQw+TcMPag
gtZtf46TyAtQSOs1L50LxRL1YXQLpsFNLKMItgTXEcooA/0RXUK1p8uG3Mr4G2my
L88nDE7zNxbGUHVGmMDx7p8EN839xcI1fEZJWv9+hTP/GbnsWR8TFNxWbv3Jjn7U
sOayEP/bgrFivKof57owHOo1FzcKaNGciUSMTTtUKqjHv0UpgcFAP1dAl5Py2xc7
E/oIw8ulgkxzri7Ge+Tczkt9CQlZIai8ZeIqtHpXtMEO6WRyC6qUZEmjq2PDMQLz
8c1UFqnfKcGHNaHGgQBL4MPxvl/lyIRa0CtxP7NsytsCnBOWzpVRY1EV7G8595Kg

NullPointerException in CoyoteOutputStream

[Mark A. Claassen]

We were doing some load testing and we started getting a NullPointerException 
at the stack trace below.  We don't get the NPE all the time, so I am guessing 
some of these objects got corrupted somehow.
One place the clear() method is called from is the recycle() method in the 
Response object from the same package.

Has anyone seen this before?  My Internet searches did not reveal any other 
reports of this.  Is this something that has already been fixed in the course 
of other changes?

The version of Tomcat is 9.0.12 and we are using the openSSL underneath all 
this.

Thanks,
Mark

---
 at 
org.apache.catalina.connector.CoyoteOutputStream.checkNonBlockingWrite(CoyoteOutputStream.java:134)
 at 
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:95)
 at 
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
 at dsi.core.io.ByteCounterOutputStream.write(ByteCounterOutputStream.java:37)

--- CoyoteOutputStream
private boolean checkNonBlockingWrite() {
boolean nonBlocking = !ob.isBlocking(); <-- Line 134
if (nonBlocking && !ob.isReady()) {
throw new 
IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
}
return nonBlocking;
}
--- CoyoteOutputStream
/**
 * Clear facade.
 */
void clear() {
ob = null;
}
--- CoyoteOutputStream
@Override
public void close() throws IOException {
ob.close();
}
---

Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect 
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
assumes no legal liability or responsibility for the posting. 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: NullPointerException in CoyoteOutputStream

[calder]

On Fri, Jun 12, 2020, 10:36 Mark A. Claassen  wrote:

> We were doing some load testing and we started getting a
> NullPointerException at the stack trace below.  We don't get the NPE all
> the time, so I am guessing some of these objects got corrupted somehow.
> One place the clear() method is called from is the recycle() method in the
> Response object from the same package.
>
> Has anyone seen this before?  My Internet searches did not reveal any
> other reports of this.  Is this something that has already been fixed in
> the course of other changes?
>
> The version of Tomcat is 9.0.12 and we are using the openSSL underneath
> all this.
>
> ---
>  at
> org.apache.catalina.connector.CoyoteOutputStream.checkNonBlockingWrite(CoyoteOutputStream.java:134)
>  at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:95)
>  at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
>  at dsi.core.io
> .ByteCounterOutputStream.write(ByteCounterOutputStream.java:37)
>


Apologies ... but this doesn't look like a complete stack trace, to include
any "caused by" statements (and the originating statement)


 CoyoteOutputStream
> private boolean checkNonBlockingWrite() {
> boolean nonBlocking = !ob.isBlocking(); <-- Line 134
> if (nonBlocking && !ob.isReady()) {
> throw new
> IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
> }
> return nonBlocking;
> }
> --- CoyoteOutputStream
> /**
>  * Clear facade.
>  */
> void clear() {
> ob = null;
> }
> --- CoyoteOutputStream
> @Override
> public void close() throws IOException {
> ob.close();
> }
> ---

RE: NullPointerException in CoyoteOutputStream

[Mark A. Claassen]

Thanks for the reply, and sorry for the confusion.  I catch the error in my 
code and format it in a custom way, which is why it may look a bit different 
than what you expect.
That was not the complete stack, but the top is the top, which implies that 
'ob' is null

After the ByteCounterOutputStream line, there is more of my code until I 
eventually get to:
HttpServlet.service(HttpServlet.java:660)
The ByteCounterOutputStream wraps the HttpServletResponse.getOutputStream() and 
the error occurs when it is trying to write to the stream.


My code has been relatively unchanged for years. Additionally, this load test 
has succeeded using this version of tomcat of 10,000s of iterations.  
However, maybe some once-in-a-million occurrence happened and corrupted at 
least of one instance of the CoyoteOutputStream?  
And then whenever one of these gets reused, I can't write to the output stream.

CoyoteOutputStream.checkNonBlockingWrite(CoyoteOutputStream.java:134)
CoyoteOutputStream.write(CoyoteOutputStream.java:95)
CoyoteOutputStream.write(CoyoteOutputStream.java:89)
ByteCounterOutputStream.write(ByteCounterOutputStream.java:37) <-- My code 
doing a write()

private boolean checkNonBlockingWrite() {
boolean nonBlocking = !ob.isBlocking(); <-- 134 (NPE here implies ob is 
null)
if (nonBlocking && !ob.isReady()) {
throw new 
IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
}
return nonBlocking;
}
public void write(byte[] b, int off, int len) throws IOException {
boolean nonBlocking = checkNonBlockingWrite(); <-- 95
ob.write(b, off, len);
if (nonBlocking) {
checkRegisterForWrite();
}
}
public void write(byte[] b) throws IOException {
write(b, 0, b.length); <-- 89
}

-Original Message-
From: calder  
Sent: Friday, June 12, 2020 12:31 PM
To: Tomcat Users List 
Subject: Re: NullPointerException in CoyoteOutputStream

On Fri, Jun 12, 2020, 10:36 Mark A. Claassen  wrote:

> We were doing some load testing and we started getting a 
> NullPointerException at the stack trace below.  We don't get the NPE 
> all the time, so I am guessing some of these objects got corrupted somehow.
> One place the clear() method is called from is the recycle() method in 
> the Response object from the same package.
>
> Has anyone seen this before?  My Internet searches did not reveal any 
> other reports of this.  Is this something that has already been fixed 
> in the course of other changes?
>
> The version of Tomcat is 9.0.12 and we are using the openSSL 
> underneath all this.
>
> ---
>  at
> org.apache.catalina.connector.CoyoteOutputStream.checkNonBlockingWrite
> (CoyoteOutputStream.java:134)
>  at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStr
> eam.java:95)
>  at
> org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStr
> eam.java:89)
>  at dsi.core.io
> .ByteCounterOutputStream.write(ByteCounterOutputStream.java:37)
>


Apologies ... but this doesn't look like a complete stack trace, to include any 
"caused by" statements (and the originating statement)


 CoyoteOutputStream
> private boolean checkNonBlockingWrite() {
> boolean nonBlocking = !ob.isBlocking(); <-- Line 134
> if (nonBlocking && !ob.isReady()) {
> throw new
> IllegalStateException(sm.getString("coyoteOutputStream.nbNotready"));
> }
> return nonBlocking;
> }
> --- CoyoteOutputStream
> /**
>  * Clear facade.
>  */
> void clear() {
> ob = null;
> }
> --- CoyoteOutputStream
> @Override
> public void close() throws IOException {
> ob.close();
> }
> ---

Re: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alfred,

On 6/12/20 05:52, Alfred Bakia wrote:
> Thanks, Jon. I did in fact compare all the settings between the
> servers, including the logging settings. They are exactly the
> same.> But there is new information. In a detailed comparison of
> the Java code between the servers, I spotted one difference.
> Something sets apart the instance that is logging the Warning
> "AJP13 protocol: Reuse is set to false". The instance includes a
> REST API. As Sherlock Holmes said, "When you have eliminated all
> which is impossible, then whatever remains, however improbable,
> must be the truth."
>
> I am now looking into how the combination REST - Tomcat - IIS can
> trigger the warning.
...but this is being logged on the IIS side, not the Tomcat side. It's
very unlikely that the application is causing these log messages to be
displayed.

Same version(s) of IIS? Same versions of mod_jk?

- -chris

> -Oorspronkelijk bericht- Van:
> jonmcalexan...@wellsfargo.com.INVALID

> Verzonden: 11 June 2020 23:57 Aan: users@tomcat.apache.org
> Onderwerp: RE: Warning "AJP13 protocol: Reuse is set to false"
> written
logs every second of every day. Please help.
>
> Perhaps also compare your logging sensitivity between the servers.
>
>
> Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice
> President
>
> Middleware Product Engineering Enterprise CIO | Platform Services
> | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel
> 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
>
> This message may contain confidential and/or privileged
> information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.
>
> -Original Message- From: Christopher Schultz
>  Sent: Thursday, June 11, 2020 12:55
> PM To: users@tomcat.apache.org Subject: Re: Warning "AJP13
> protocol: Reuse is set to false" written
logs every second of every day. Please help.
>
> Alfred,
>
> On 6/11/20 11:57, Alfred Bakia wrote:
>> Hi Everyone,
>
>> This is my very first mail to the users list since joining
>> yesterday. Not an auspicious start. But I hope I will be able to
>> contribute in future. I seek your help for a persistent issue in
>> one of our ColdFusion instances.
>
>> Description of issue: ColdFusion 2018 is an application server
>> that uses Tomcat 9.0.21. Our ColdFusion installation consists of
>> instances. The instances are independent application servers,
>> each with its own Tomcat installation and Java Virtual Machine.
>> The Java version is 11.0.7.
>
>> Each ColdFusion instance serves web content via the web server
>> IIS. We have configured an AJP connector for the communication
>> between Tomcat and IIS. The relevant settings are
>
>
>> *   In server.xml
>
>> > redirectPort="8445" protocol="AJP/1.3"
>> tomcatAuthentication="false" maxThreads="500"
>> packetSize="65535"/>
>
>
>> *   In isapi_redirect.properties
>
>> iis_buffer_enable= true
>
>
>> *   In workers.properties
>
>> worker.list=sr1studierdr1
>
>> worker.sr1studierdr1.type=ajp13
>
>> worker.sr1studierdr1.host=localhost
>
>> worker.sr1studierdr1.port=8012
>
>> worker.sr1studierdr1.connection_pool_size=800
>
>> worker.sr1studierdr1.connection_pool_timeout=60
>
>> worker.sr1studierdr1.max_reuse_connections=400''
>
>> On one of the instances (name: 'sr1studierdr1'), the following
>> WARNING is written to isapi_redirect.log every second or so:
>
>
>> *   [Thu Jun 11 16:44:57.739 2020] [11308:15392] [warn]
>> ajp_process_callback::jk_ajp_common.c (2242): (sr1studierdr1)
>> AJP13 protocol: Reuse is set to false
>
>> Nevertheless, the application seems to work as intended.
>
>> We're at a loss why this is happening only to this particular
>> instance. There are no such warnings in other instances that
>> share exactly the same settings.
>
>> Do you know what is causing the warning, "AJP13 protocol: Reuse
>> is set to false", or how to solve this?
>
> I have no idea, but Google seemed able to come up with this:
>
> https://forums.iis.net/t/1229345.aspx?Error+AJP13+protocol+Reuse+is+se
t+
>
>
>
to+false+on+log+file+
>
> Does that help at all?
>
> Apache httpd configuration of mod_jk has a DisableReuse flag that
> can be set, but I don't see such a thing for IIS.
>
> -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
>
>
> 

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Madhan,

On 6/12/20 00:57, Madhan Raj wrote:
> Just attached the outputs logs and my server.xml including my
> ecdsa cert. in keystoreand s_client outputs.txt file i have
> attached all the required cert and keystore outputs.

In-line would be better in the future. I hate having to save
attachments on my own computer and then edit them just to see them.
And then copy/paste to quote.

> [root@sapphire-69 conf]# keytool -list -v -keystore
> /usr/local/platform/.security/tomcat-ECDSA/certs/tomcat-ECDSA.keystore
> -storepass iY4VjgcxNrTLp57b  -storetype PKCS12log4j:WARN No
> appenders could be found for logger
> (com.cisco.ciscossl.provider.ciscojce.CiscoJEnv). log4j:WARN Please
> initialize the log4j system properly. log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info. Keystore type: PKCS12 Keystore provider: JsafeJCE

Could this be of interest (repeating above):
> Keystore provider: JsafeJCE

I didn't see certificateKeystoreProvider="JsafeJCE" in your
 configuration.

Does your RSA keystore show the same keystore provider if you dump it?

> [snip] [from keytool] Owner: L=blr, ST=kr, CN=sapphire-69-EC,
> OU=cisco, O=infy, C=IN [snip] Signature algorithm name:
> SHA384withECDSA Subject Public Key Algorithm: 384-bit EC key>
> [snip] [from openssl] X509v3 Subject Alternative Name:
> DNS:sapphire-69

Your CN is "sapphire-69-EC" and you have a SAN for "sapphire-69". Is
that also the hostname being used to connect?

> What client are you using to attempt the handshake? i am using
> openssl command line utility to test

Good.

> What error(s) do you get with the handshake?  secure negotiation
> not supported

That's not an error. It's one of many messages from openssl s_client:

> # openssl s_client -connect localhost:443 CONNECTED(0003)
> 139656609052336:error:140790E5:SSL routines:ssl23_write:ssl
> handshake failure:s23_lib.c:177: --- no peer certificate available
> --- No client certificate CA names sent --- SSL handshake has read
> 0 bytes and written 247 bytes --- New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported Compression: NONE Expansion:
> NONE No ALPN negotiated SSL-Session: Protocol  : TLSv1.2 Cipher
> :  Session-ID: Session-ID-ctx: Master-Key: Key-Arg   : None PSK
> identity: None PSK identity hint: None SRP username: None Start
> Time: 1591935501 Timeout   : 300 (sec) Verify return code: 0 (ok)
> ---

You are using "localhost". What if you use "sapphire-69"?

...although localhost:8443 seems to work with your RSA certificate.

> If you configure *only* ESDSA, can you handshake? Or does ECDSA
> never work?   correct ECDSA never work for me. here in my case on
> port 443 i hosted only ECDSA keystore and on 8443 i have hosted RSA
> keystore. 8443 works like charm and 443 is down

> [From your config:]  ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>
>
protocols="TLSv1,TLSv1.1,TLSv1.2" sessionCacheSize="1"
> sessionTimeout="1800" sslProtocol="TLS" truststoreType="PKCS12">
Note that you can't handshake using an RSA authentication with an
ECDSA certificate. While those ECDHE-RSA-* ciphers in there won't
hurt, they will never work and are a little confusing.

What happens if you point this tool at your localhost:443 and
localhost:8443 endpoints?

https://github.com/ChristopherSchultz/ssltest

- -chris

> On Thu, Jun 11, 2020 at 1:47 PM Christopher Schultz
>  >
wrote:
>
> Madhan,
>
> On 6/10/20 22:08, Madhan Raj wrote:
>> Any insights please .
>
> How did you create your certificate?
>
> What are the details of your certificate and key? For example,
> which curve are you using? How many key bits? What type of
> signature on the certificate? What is the alias for that
> certificate in your keystore? Does it match what you have
> configured in Tomcat? Do you have a password on your keystore? Are
> you setting that correctly in your  element? (I see no
> password in your posted config.)
>
> What client are you using to attempt the handshake?
>
> What error(s) do you get with the handshake?
>
> If you configure *only* ESDSA, can you handshake? Or does ECDSA
> never work?
>
> You haven't give us much to go on, other than "I can't get ESDSA
> to work" when it's pretty clear others can get it to work.
>
> -chris
>
>> On Thu, 4 Jun, 2020, 11:12 pm Madhan Raj,  
>> >>
>> wrote:
>
>> Hi Christopher,
>
>> Yes you correct I can only complete a handshake with RSA cert,
>> not ECDSA cert. when i try to connect with ECDSA ciphers using
>> s_client negotiation fails. Madhan
>
>> On Thu, Jun 4, 2020 at 12:41 PM Christopher Schultz
>> > 
>>  

Re: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.

[Konstantin Kolinko]

чт, 11 июн. 2020 г. в 18:57, Alfred Bakia :
>
> Description of issue:
> ColdFusion 2018 is an application server that uses Tomcat 9.0.21. Our 
> ColdFusion installation consists of instances. The instances are independent 
> application servers, each with its own Tomcat installation and Java Virtual 
> Machine. The Java version is 11.0.7.
>
> Each ColdFusion instance serves web content via the web server IIS.  We have 
> configured an AJP connector for the communication between Tomcat and IIS. The 
> relevant settings are
>
>
>   *   In server.xml
>
>  protocol="AJP/1.3" tomcatAuthentication="false" maxThreads="500" 
> packetSize="65535"/>

The packetSize has non-default value. The configuration reference [1]
says that the same value should be configured on the other side as
well, mentioning "max_packet_size" for mod_jk. I am not sure how that
is done for IIS.

[1] https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html


> On one of the instances (name: 'sr1studierdr1'), the following WARNING is 
> written to isapi_redirect.log every second or so:
>
>
>   *   [Thu Jun 11 16:44:57.739 2020] [11308:15392] [warn] 
> ajp_process_callback::jk_ajp_common.c (2242): (sr1studierdr1) AJP13 protocol: 
> Reuse is set to false

Searching the sources, the code that writes it appears to be in
native/common/jk_ajp_common.c

https://github.com/apache/tomcat-connectors/blob/master/native/common/jk_ajp_common.c#L2117

It is triggered by a value of a "reuse flag" field in an "END_RESPONSE" packet.

https://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html#End_Response

At Tomcat side the END_RESPONSE packet is sent by
AjpProcessor.finishResponse() and can send two kinds of an end
response packet: one with a "reuse" flag value and another with a "no
reuse".

https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/coyote/ajp/AjpProcessor.java#L104
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/coyote/ajp/AjpProcessor.java#L1049.

If there is a severe error that does not allow reuse of the
connection, the "no reuse" packet is sent. I wonder how you encounter
such an error.

Do you have an access log configured in Tomcat and what does it show?

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: NullPointerException in CoyoteOutputStream

[Konstantin Kolinko]

пт, 12 июн. 2020 г. в 18:36, Mark A. Claassen :
>
> We were doing some load testing and we started getting a NullPointerException 
> at the stack trace below.  We don't get the NPE all the time, so I am 
> guessing some of these objects got corrupted somehow.
> One place the clear() method is called from is the recycle() method in the 
> Response object from the same package.
>
> Has anyone seen this before?  My Internet searches did not reveal any other 
> reports of this.  Is this something that has already been fixed in the course 
> of other changes?
>
> The version of Tomcat is 9.0.12 and we are using the openSSL underneath all 
> this.

Why not the current version (9.0.36)?

Also
https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-TroubleshootingunexpectedResponsestateproblems

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Junk characters in SOAP request after upgrade to tomcat 9.0.31

[Martin Grigorov]

Hi,

On Fri, Jun 12, 2020 at 8:17 AM Naveen Kumar  wrote:

> Hi All,
>
> Can someone please help on this ? It is in production and affecting many
> customers. Upgrading tomcat is a big task.
> Any pointers will be really appreciated.
>

You say "If I upgrade tomcat to 9.0.35, the error disappears." - this is
the right solution - upgrade to the latest release. We make releases
because there are bug fixes and improvements.

If you just want to know which particular commit caused the regression you
experience in 9.0.31 then you have two options:
1) read the changelogs and try to figure out
2)  'git bisect' Tomcat sources:
git clone https://github.com/apache/tomcat
git bisect start
git bisect good tag/9.0.24
git bisect bad tag/9.0.31
ant clean
ant
deploy your app and test


>
> Thanks
> Naveen
>
> On Wed, Jun 10, 2020 at 4:24 PM Naveen Kumar  wrote:
>
> > Hi Luis,
> >
> > Thanks for your suggestion.
> > But I am wondering what has changed in 9.0.31. Because my webapp works
> > perfectly fine in 9.0.24 and 9.0.35.
> >
> > Thanks
> > Naveen
> >
> > On Wed, Jun 10, 2020 at 2:52 PM Luis Rodríguez Fernández <
> > uo67...@gmail.com> wrote:
> >
> >> Hello Naveen,
> >>
> >> Recently we have had a similar issue migrating a webapp from another
> >> application server to tomcat. We solved it specifying
> >> UTF-8 in the
> >> web.xml descriptor.
> >>
> >> You can read here [1] the long story :)
> >>
> >> Hope it helps,
> >>
> >> Luis
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding
> >>
> >>
> >> El mié., 10 jun. 2020 a las 11:08, Naveen Kumar ()
> >> escribió:
> >>
> >> > Hi All,
> >> >
> >> > I have a webapp A which has few SOAP services and I consume those
> >> services
> >> > from webapp B.
> >> > I started getting below error since I upgraded the tomcat to 9.0.31
> >> (from
> >> > 9.0.24):
> >> > com.sun.xml.ws.transport.http.HttpAdapter.invokeAsync Couldn't create
> >> SOAP
> >> > message due to exception: XML reader error:
> >> > javax.xml.stream.XMLStreamException: java.io.EOFException: Unexpected
> >> EOF
> >> >
> >> > Then I wrote a filter at webapp A to intercept the request and I could
> >> see
> >> > that some junk characters are added in the SOAP request.
> >> >
> >> > If I upgrade tomcat to 9.0.35, the error disappears.
> >> >
> >> > Problematic request:
> >> > LoggingFilter.doFilter - The servlet  request soap mapping  body is:à
> >>  8Ï
> >> > S(http://schemas.xmlsoap.org/soap/envelope/ð??? Envelope??? Body8Ï
> ns13
> >> >
> >> > Correct request:
> >> > The servlet  request soap mapping  body is: >> > encoding='UTF-8'?> >> >
> >> > Does anyone know what could be the possible reason for this?
> >> >
> >> > Thanks in advance.
> >> > - Naveen
> >> >
> >>
> >>
> >> --
> >>
> >> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail
> better."
> >>
> >> - Samuel Beckett
> >>
> >
>