[GitHub] [tomcat-connectors] gjaekel commented on pull request #7: Possible issue in ajp_read_fully_from_server()

2023-03-20 Thread via GitHub 


gjaekel commented on PR #7:
URL: https://github.com/apache/tomcat-connectors/pull/7#issuecomment-1476245704

   Yes, it's in the error log. It's also quite easy to Google for it if you 
know that you have to search for the keyword `limitrequestbody`. :o
   
   The dev's of our application in scope don't handle the http rc in detail.  
Because it's chunked for reason of streaming, the error rises during transfer, 
the (Java) application just got an exception about unexpected close of stream.
   
   @rainerjung Thank you!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [tomcat-connectors] gjaekel commented on pull request #7: Possible issue in ajp_read_fully_from_server()

2023-03-20 Thread via GitHub 


gjaekel commented on PR #7:
URL: https://github.com/apache/tomcat-connectors/pull/7#issuecomment-1476151899

   It seems, that the reason is very lame! With 
https://github.com/apache/httpd/commit/92499e20034485c5e2d29cb85940e309573d976e 
the default for _LimitRequestBody_ becomes **1GB** instead of **unlimited** 
before.
   
   Of course, this is changed in the docs 
(https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody) but IMHO 
there's nothing about this breaking change in the change logs! I'm very 
displeasured.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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

[GitHub] [tomcat-connectors] gjaekel commented on pull request #7: Possible issue in ajp_read_fully_from_server()

2023-03-20 Thread via GitHub 


gjaekel commented on PR #7:
URL: https://github.com/apache/tomcat-connectors/pull/7#issuecomment-1476084475

   Dear Mark,
   
   first let my thank you for quick reply. I understand you in a way that this 
is already a "death code path" that can't rise issues anymore.
   
   I actually "staring at the code" because I have to solve an Issue that 
appeared for us with the transition from Apache httpd-2.4.53 to 2.4.54 (and 
also 2.4.56). It's related to transmitting bigger amounts of data via POST 
requests using the httpd as a (ssl) reverse proxy for our Wildfly farm. Using 
the newer one, the ongoing request will fail after some seconds. At about 
~512M, the usecase becomes unstable (, .i.e. breaks some time) and at about 
~1GB, it fails virtually all the time.
   
   I yet don't have any idea, what's happening and what's the reason. In the 
*mod_jk* log, I found:
   ```
   20230316-101703.162 [37588:139628162045632] [info] 
ajp_read_into_msg_buff::jk_ajp_common.c (1549): (test-flyA) receiving data from 
client failed. Connection aborted or network problems
   20230316-101703.162 [37588:139628162045632] [info] 
ajp_process_callback::jk_ajp_common.c (2101): (test-flyA) Reading from client 
aborted or client network problems
   20230316-101703.162 [37588:139628162045632] [info] 
ajp_service::jk_ajp_common.c (2774): (test-flyA) sending request to tomcat 
failed (unrecoverable), because of client read error (attempt=1)
   20230316-101703.162 [37588:139628162045632] [info] service::jk_lb_worker.c 
(1600): service failed, worker test-flyA is in local error state
   20230316-101703.162 [37588:139628162045632] [info] service::jk_lb_worker.c 
(1619): unrecoverable error 400, request failed. Client failed in the middle of 
request, we can't recover to another instance.
   20230316-101703.162 [37588:139628162045632] [info] jk_handler::mod_jk.c 
(2991): Aborting connection for worker=test-flyAB
   20230316-101703.162 test-flyA 7.334024 400 
http://etc.dnb.de.test/aras/access/repositories/dma/artifacts/1235459136/unpackStream?pathfilter=content
   ```
   The version is mod_jk-1.2.48 and it's hold while switching the http 
versions. I don't understand what may trigger an issue in *mod_jk* while using 
the updated httpd.
   
   Do you have any hints for me?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


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