[Bug 56726] Part.write (String fileName) is not yet resolved to my understanding
https://issues.apache.org/bugzilla/show_bug.cgi?id=56726 Christopher Schultz changed: What|Removed |Added Status|NEW |NEEDINFO OS||All --- Comment #1 from Christopher Schultz --- Perhaps your access is denied to that file/directory. Bug 54971 seems unrelated unless you think this has something to do with relative versus absolute path specifications. If you want any reasonable reply, you need to: a) post your multipart configuration (whether from web.xml or @Annotations) b) tell us the effective user under which Tomcat is running c) give details about the ownership of the directories mentioned in your error report attachment -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56725] Socket write error when streaming large file
https://issues.apache.org/bugzilla/show_bug.cgi?id=56725
--- Comment #4 from mardkra...@hotmail.com ---
I received more information form the author of the test, added more logging,
and am including more of the client-server log (minus a few of our custom
classes).
The test acts does the following:
1. send a new file
a. HEAD check if already exists - 404 (Not found)
b. PUT initial small file - 201 (Created)
2. start sending/updating 1GB file (on thread-x with a new HttpClient instance
built with same user setup)
a. HEAD check if already exisits - 200 (OK)
b. PUT large file
3. attempt to delete the file a few seconds after step 2 starts (on thread-y
with a new HttpClient instance built with same user setup)
a. DELETE file
We expect (and experience with 8.0.8) that step 3 returns with 409 (Conflict)
and step 2 returns with 200 (OK). However, we are experiencing with 8.0.9 that
step 2 gets cut off and can't complete.
receiving server's access logs
127.0.0.1 - - [16/Jul/2014:13:50:33 +] "HEAD
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 -
127.0.0.1 - - [16/Jul/2014:13:50:33 +] "HEAD
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 404 -
127.0.0.1 - - [16/Jul/2014:13:50:33 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
127.0.0.1 - - [16/Jul/2014:13:50:33 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 201 -
127.0.0.1 - - [16/Jul/2014:13:50:39 +] "HEAD
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 -
127.0.0.1 - - [16/Jul/2014:13:50:39 +] "HEAD
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 200 -
127.0.0.1 - - [16/Jul/2014:13:50:51 +] "DELETE
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
127.0.0.1 - - [16/Jul/2014:13:50:51 +] "DELETE
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 204 -
127.0.0.1 - - [16/Jul/2014:13:50:54 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
127.0.0.1 - - [16/Jul/2014:13:50:55 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
127.0.0.1 - - [16/Jul/2014:13:50:56 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
127.0.0.1 - - [16/Jul/2014:13:50:57 +] "PUT
/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd
HTTP/1.1" 401 1114
cleint server's logs
13:50:33.443 INFO http-nio-8710-exec-2 Logger.info - Before request
[method=PUT;server=http://localhost:8710;uri=/application/api/file/conflictApp/files/a57f597a-bb7f-4221-8097-e4d9222c61cd?null;client=127.0.0.1]
13:50:33.625 WARN http-nio-8710-exec-2 RestTemplate.handleResponseError - HEAD
request for
"http://localhost:8700/management/api/storage/fileManagement/article/conflictApp/a57f597a-bb7f-4221-8097-e4d9222c61cd";
resulted in 404 (Not Found); invoking error handler
13:50:33.931 INFO http-nio-8710-exec-2 Logger.info - After request
[method=PUT;server=http://localhost:8710;uri=/application/api/file/conflictApp/files/a57f597a-bb7f-4221-8097-e4d9222c61cd?null;client=127.0.0.1]
13:50:39.184 INFO http-nio-8710-exec-3 Logger.info - Before request
[method=PUT;server=http://localhost:8710;uri=/application/api/file/conflictApp/files/a57f597a-bb7f-4221-8097-e4d9222c61cd?null;client=127.0.0.1]
13:50:51.072 INFO http-nio-8710-exec-4 Logger.info - Before request
[method=DELETE;server=http://localhost:8710;uri=/application/api/file/conflictApp/files/a57f597a-bb7f-4221-8097-e4d9222c61cd?null;client=127.0.0.1]
13:50:51.199 INFO http-nio-8710-exec-4 Logger.info - After request
[method=DELETE;server=http://localhost:8710;uri=/application/api/file/conflictApp/files/a57f597a-bb7f-4221-8097-e4d9222c61cd?null;client=127.0.0.1]
13:50:55.518 INFO http-nio-8710-exec-3 DefaultRequestDirector.tryExecute - I/O
exception (java.net.SocketException) caught when processing request to
{}->http://localhost:8700: Connection reset by peer: socket write error
13:50:55.521 INFO http-nio-8710-exec-3 DefaultRequestDirector.tryExecute -
Retrying request to {}->http://localhost:8700
13:50:56.524 INFO http-nio-8710-exec-3 DefaultRequestDirector.tryExecute - I/O
exception (java.net.SocketException) caught when processing request to
{}->http://localhost:8700: Connection reset by peer: socket write error
13:50:56.527 INFO http-nio-8710-exec-3 DefaultRequestDirector.tryExecute -
Retrying request to {}->http://localhost:8700
13:50:57.5
[Bug 56725] Socket write error when streaming large file
https://issues.apache.org/bugzilla/show_bug.cgi?id=56725 --- Comment #5 from Remy Maucherat --- 56693 ? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56731] New: EL-Expression with escaped single quote leads to ELException
https://issues.apache.org/bugzilla/show_bug.cgi?id=56731 Bug ID: 56731 Summary: EL-Expression with escaped single quote leads to ELException Product: Tomcat 7 Version: 7.0.54 Hardware: PC Status: NEW Severity: regression Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: c.lu...@gmail.com Created attachment 31822 --> https://issues.apache.org/bugzilla/attachment.cgi?id=31822&action=edit Error page with stack trace from tomcat Hi Folks, the following line in an 2.2-XML-JSP worked in Tomcat 7.0.39 but triggers an ELException in Tomcat 7.0.54 (see attachment for details): test I seems that the expression "'\'test\''" leads to the the problem because including it in parenthesis solves the problem in 7.0.54: test The problem is that we have a lot of similar expressions containing escaped single quotes in our webapp. Thanks for your help, Christof Luick. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56725] Socket write error when streaming large file
https://issues.apache.org/bugzilla/show_bug.cgi?id=56725 --- Comment #6 from Christopher Schultz --- (In reply to mardkrause from comment #4) > I received more information form the author of the test, added more logging, > and am including more of the client-server log (minus a few of our custom > classes). > > The test acts does the following: > 1. send a new file > a. HEAD check if already exists - 404 (Not found) > b. PUT initial small file - 201 (Created) > 2. start sending/updating 1GB file (on thread-x with a new HttpClient > instance built with same user setup) > a. HEAD check if already exists - 200 (OK) > b. PUT large file What code handles the PUT to these URLs? Are you using Tomcat's WebDAV servlet, or something else? If it's something else, then you might want to take a look at that code. > 3. attempt to delete the file a few seconds after step 2 starts (on thread-y > with a new HttpClient instance built with same user setup) > a. DELETE file Are you issuing the DELETE request before step 2b has completed? It shouldn't matter -- most OSs will let you write to a deleted file as long as the file handle was valid when it was opened -- but I'm curious. > We expect (and experience with 8.0.8) that step 3 returns with 409 > (Conflict) and step 2 returns with 200 (OK). However, we are experiencing > with 8.0.9 that step 2 gets cut off and can't complete. Is the exception shown here from the "client server" or the "server server"? I only ask because the log mysteriously changes date formats between the INFO and the SEVERE log messages. I also notice that every request gets a 401 (Unauthorized) response. Are you checking for that and stopping? Read Konstantin's comment #3 about aborted uploads: if you get a 401 response, you are probably going to hit that limit with a "large" file and find your connection forcibly closed. I think your test isn't providing correct credentials, and I think it's not checking HTTP status codes when executing a PUT. ;) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56733] New: Memory leak when JkOption +FlushPackets is enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=56733 Bug ID: 56733 Summary: Memory leak when JkOption +FlushPackets is enabled Product: Tomcat Connectors Version: 1.2.40 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: mod_jk Assignee: dev@tomcat.apache.org Reporter: do...@moonteeth.com This appears to be the same as: https://issues.apache.org/bugzilla/show_bug.cgi?id=42366 I'm opening a new one though since that one is so old. If this is incorrect please let me know. The issue is reproducible with any fairly recent mod_jk but I'm testing 1.2.40 right now. httpd -V output: Server version: Apache/2.2.27 (Win32) Server built: May 15 2014 17:04:25 Server's Module Magic Number: 20051115:33 Server loaded: APR 1.5.0, APR-Util 1.5.3 Compiled using: APR 1.5.0, APR-Util 1.5.3 Architecture: 32-bit Server MPM: WinNT threaded: yes (fixed thread count) forked: no Server compiled with -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled) -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/apache" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error.log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" What i did was simply created a 600mb file using dd if=/dev/urandom plopped it into tomcat's webapps/example directory configured JkMount /examples/* ajpWorker and used wget to download it. I ran wget in a loop and eventually stopped it when private bytes hit around 300MB. I can't reliably reproduce it with all workers.properties options. For example this: worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8010 worker.tomcat1.max_packet_size=8192 worker.tomcat1.connection_pool_size=120 worker.tomcat1.connection_pool_minsize=8 worker.tomcat1.connection_pool_timeout=900 triggers the problem but this alone: worker.tomcat1.type=ajp13 worker.tomcat1.host=localhost worker.tomcat1.port=8010 does not. I'm in the process of testing to see if the connection_pool configuration may be what's doing it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56733] Memory leak when JkOption +FlushPackets is enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=56733 Andy Wang changed: What|Removed |Added OS||All --- Comment #1 from Andy Wang --- Oh, in case this helps, this is the debugdiag stack for the memory allocations: Function Destination libapr_1!allocator_alloc+d6 msvcr100!malloc libapr_1!apr_palloc+d9 libapr_1!allocator_alloc libaprutil_1!apr_brigade_create+11 libapr_1!apr_palloc libhttpd!ap_rflush+19 libaprutil_1!apr_brigade_create mod_jk!ws_flush+1a libhttpd!ap_rflush mod_jk!ajp_process_callback+586 mod_jk!ajp_get_reply+c4 mod_jk!ajp_process_callback mod_jk!ajp_service+60a mod_jk!ajp_get_reply mod_jk!service+82f mod_jk!jk_handler+6ea libhttpd!ap_run_handler+25 libhttpd!ap_invoke_handler+a2 libhttpd!ap_run_handler libhttpd!ap_process_request+3e libhttpd!ap_invoke_handler libhttpd!ap_process_http_connection+52 libhttpd!ap_process_request libhttpd!ap_run_process_connection+25 libhttpd!ap_process_connection+33 libhttpd!ap_run_process_connection libhttpd!worker_main+a7 libhttpd!ap_process_connection msvcr100!_callthreadstartex+1b msvcr100!_threadstartex+64 kernel32!BaseThreadInitThunk+e ntdll!__RtlUserThreadStart+70 ntdll!_RtlUserThreadStart+1b ntdll!__RtlUserThreadStart msvcr100!_threadstartex -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56733] Memory leak when JkOption +FlushPackets is enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=56733 --- Comment #2 from Christopher Schultz --- The max_packet_size is the default (8192) so that's not likely it. The connection_pool sizes are likely the differentiating factor. Did you build mod_jk yourself, or use a pre-built one? Do you know what version of APR is being used under the hood? The call mod_jk makes to ap_rflush looks fairly innocuous. That call is also made in ws_write if the request is for headers only (e.g. a HEAD request). Can you try this with and without +FlushPackets and try a huge number of HEAD requests to see if you can also trigger a memory leak? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56733] Memory leak when JkOption +FlushPackets is enabled
https://issues.apache.org/bugzilla/show_bug.cgi?id=56733 --- Comment #3 from Andy Wang --- I was able to reproduce this both with my own mod_jk as well as with the mod_jk binary build from apache.org. The APR I used to build mine was the APR that's part of the apache 2.2.27 source tree so it's: Server loaded: APR 1.5.0, APR-Util 1.5.3 Compiled using: APR 1.5.0, APR-Util 1.5.3 I'll try the HEAD test tomorrow and see what comes up. Do you think it's worth trying to figure out how the connection pool configuration plays into this by tweaking those a bit more? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
