[Bug 57251] WAR deployment unbelievably slow when unpackWARs=false

https://issues.apache.org/bugzilla/show_bug.cgi?id=57251 Francisco A. Lozano changed: What|Removed |Added CC||floz...@gmail.com -- You ar

[Bug 57528] Random NPE when sending multipart content

https://issues.apache.org/bugzilla/show_bug.cgi?id=57528 Francisco A. Lozano changed: What|Removed |Added CC||floz...@gmail.com -- You ar

[Bug 50504] Allow setting query string character set trough request attribute

https://issues.apache.org/bugzilla/show_bug.cgi?id=50504 --- Comment #6 from Mark Thomas --- The query string remains as bytes until it is required (if at all). Take a look at Http11InputBuffer.parseRequestLine() in trunk and when it is called. Hence why setting the character encoding on the req

svn commit: r1657764 - /tomcat/trunk/java/org/apache/catalina/webresources/AbstractArchiveResource.java

Author: remm Date: Fri Feb 6 09:25:46 2015 New Revision: 1657764 URL: http://svn.apache.org/r1657764 Log: Related to BZ57528: improve the algorithm to handle an exception or null return value in getContent and avoid NPE or returning corrupted data. Modified: tomcat/trunk/java/org/apache/ca

Re: Hi

On 06/02/2015 07:46, Pravallika Peddi wrote: > Thanks Mark. > > I downloaded the source code from trunk using svn. checked out version > is: 1657747 > I am able to build it and Tomcat is running successfully in my environment. Great. > Can you help assign a bug or some assignment considering my

Re: Hi

Hello mark, Along what lines of development is tomcat looking for now? Thanking. You On 6 Feb 2015 15:01, "Mark Thomas" wrote: > On 06/02/2015 07:46, Pravallika Peddi wrote: > > Thanks Mark. > > > > I downloaded the source code from trunk usin

Early Access builds for JDK 9 b48, JDK 8u40 b23 & JDK 7u80 b05 are available on java.net

Hi Mark/Mladen, Now that JDK 9 Early Access build images are modular [1], there is a fresh Early Access build for JDK 9 b48 available on java.net. The summary of changes are listed here In addition, t

[Bug 45014] Request and Response classes should have wrappers for use in Valves

https://issues.apache.org/bugzilla/show_bug.cgi?id=45014 --- Comment #5 from mr.oliver.hernan...@gmail.com --- We're actually using JBoss 7.4, which my understanding is that internally it's using a branched version of Tomcat 7. Remy, can you please clarify? What exactly is not the point? Are yo

[Bug 45014] Request and Response classes should have wrappers for use in Valves

https://issues.apache.org/bugzilla/show_bug.cgi?id=45014 --- Comment #6 from mr.oliver.hernan...@gmail.com --- Oh, forgot to mention, our servers are SSL enabled, and the issue only occurs when the requests are encrypted. So, tools like tcpdump/tcpmon won't help, we need to see the entire request

svn commit: r1657806 - /tomcat/tc8.0.x/trunk/java/org/apache/catalina/webresources/AbstractArchiveResource.java

Author: remm Date: Fri Feb 6 13:37:54 2015 New Revision: 1657806 URL: http://svn.apache.org/r1657806 Log: Related to BZ57528: improve the algorithm to handle an exception or null return value in getContent and avoid NPE or returning corrupted data. Modified: tomcat/tc8.0.x/trunk/java/org/a

[Bug 57536] configurable source ip

https://issues.apache.org/bugzilla/show_bug.cgi?id=57536 --- Comment #3 from Rainer Jung --- Some technical details: https://idea.popcount.org/2014-04-03-bind-before-connect/ I haven't checked the validity of each statement, but there seems to be now much info around for using bind() on the cli

[Bug 57536] configurable source ip

https://issues.apache.org/bugzilla/show_bug.cgi?id=57536 --- Comment #4 from Aaron Ogburn --- Rainer's summation of the feature request is spot on. Thanks! -- You are receiving this mail because: You are the assignee for the bug. ---

[Bug 56765] Classloader leak in Tomcat 8.0.9 caused by DBCP 2.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=56765 --- Comment #2 from prabash balasuriya --- Had the same issue and below is my gc root . Applied the solution mentioned here and it was successful. I am using tomcat-8.0.15 and downgraded tomcat-dbcp.jar file from tomcat-7.0.35. this -

svn commit: r1657844 - /tomcat/tc6.0.x/trunk/STATUS.txt

Author: markt Date: Fri Feb 6 14:43:15 2015 New Revision: 1657844 URL: http://svn.apache.org/r1657844 Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1657844&r1=1657843&r

[Bug 56765] Classloader leak in Tomcat 8.0.9 caused by DBCP 2.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=56765 Mark Thomas changed: What|Removed |Added Component|jdbc-pool |Catalina Version|unspecif

[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to

https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #4 from andrew jardine --- I have tried this with 2 nodes all the way up to 5 nodes -- all configured the same, all the same results. The odd thing is that it only seems to affect sessions that are marked as Primary on the node

svn commit: r1657855 - /tomcat/tc6.0.x/trunk/STATUS.txt

Author: markt Date: Fri Feb 6 15:10:32 2015 New Revision: 1657855 URL: http://svn.apache.org/r1657855 Log: Proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1657855&r1=1657854&r

[Bug 57544] New: Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 Bug ID: 57544 Summary: Server CPU maxed out (100% per core) randomly after 10 to 30 hours Product: Tomcat 8 Version: 8.0.18 Hardware: PC OS: Linux

[Bug 57544] Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 --- Comment #1 from Xavier F. Kral --- We have a dedicated self-managed server running Ubuntu with Java 8 and Tomcat. That's all. Since we upgraded from Tomcat 7 to Tomcat 8.0.18, the server CPU cores becomes maxed out after a dozen of hour

[Bug 57544] Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 --- Comment #2 from Xavier F. Kral --- Created attachment 32438 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32438&action=edit To configure the JVM JDK 1.8 running Tomcat 8.0.18 -- You are receiving this mail because: You ar

[Bug 57544] Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 --- Comment #3 from Xavier F. Kral --- Created attachment 32439 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32439&action=edit Minimum configuration of the webapp that exhibits the issue -- You are receiving this mail becaus

[Bug 57544] Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 --- Comment #4 from Mark Thomas --- Yep. If you enter that loop with pos == 0 it is going to enter an infinite loop. The loop doesn't need to be there anyway. System.arrayCopy() is smart enougth to handle the problem the loop is trying to

svn commit: r1657907 - /tomcat/trunk/java/org/apache/coyote/http11/Http11InputBuffer.java

Author: markt Date: Fri Feb 6 17:58:12 2015 New Revision: 1657907 URL: http://svn.apache.org/r1657907 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 Fix potential infinite loop if pos == 0 Only need to update lastValid & pos if bytes have been moved. Modified: tomcat/trunk

svn commit: r1657908 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/coyote/http11/AbstractInputBuffer.java webapps/docs/changelog.xml

Author: markt Date: Fri Feb 6 18:01:02 2015 New Revision: 1657908 URL: http://svn.apache.org/r1657908 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 Fix potential infinite loop if pos == 0 Only need to update lastValid & pos if bytes have been moved. Modified: tomcat/tc8.0

svn commit: r1657910 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/http11/AbstractInputBuffer.java webapps/docs/changelog.xml

Author: markt Date: Fri Feb 6 18:03:10 2015 New Revision: 1657910 URL: http://svn.apache.org/r1657910 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 Fix potential infinite loop if pos == 0 Only need to update lastValid & pos if bytes have been moved. Modified: tomcat/tc7.0

[Bug 57544] Server CPU maxed out (100% per core) randomly after 10 to 30 hours

https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

svn commit: r1657977 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Author: rjung Date: Fri Feb 6 21:58:35 2015 New Revision: 1657977 URL: http://svn.apache.org/r1657977 Log: Fix typo in Changelog. Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7

[Bug 57546] New: Memory Leak in SecureNioChannel

https://issues.apache.org/bugzilla/show_bug.cgi?id=57546 Bug ID: 57546 Summary: Memory Leak in SecureNioChannel Product: Tomcat 8 Version: 8.0.18 Hardware: PC OS: Windows NT Status: NEW Severity: major

svn commit: r1657993 - /tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

Author: kkolinko Date: Fri Feb 6 23:40:02 2015 New Revision: 1657993 URL: http://svn.apache.org/r1657993 Log: Fix one more typo in the changelog Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/vi

Re: svn commit: r1657910 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/coyote/http11/AbstractInputBuffer.java webapps/docs/changelog.xml

2015-02-06 21:03 GMT+03:00 : > Author: markt > Date: Fri Feb 6 18:03:10 2015 > New Revision: 1657910 > > URL: http://svn.apache.org/r1657910 > Log: > Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=57544 > Fix potential infinite loop if pos == 0 > Only need to update lastValid & pos if byt

Françoise Rebel est absente.

Je serai absent(e) du 06/02/2015 au 16/02/2015. Je répondrai à votre message dès mon retour. Je vous souhaite de bonnes fêtes de fin d'année. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional comman