Re: [VOTE] Release build 6.0.31
On 24.01.2011 22:51, jean-frederic clere wrote: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag - builds fine - build result looks consistent with binaries Some javadoc warnings but AFAIK TC6 was never 100% clean w.r.t. javadoc. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release build 6.0.31
2011/1/25 jean-frederic clere jfcl...@gmail.com: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [x] Beta That is because of issue observed with Nio connector. https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 I am not saying broken, because other connectors run OK for me. Though, as 6.0.31 goal was to resolve regression with Nio it does not quite serve that purpose. The above mentioned issue is present in 6.0.30 as well. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50648] RpcChannel improvements
https://issues.apache.org/bugzilla/show_bug.cgi?id=50648 --- Comment #3 from Olivier Costet ocos...@zenprise.com 2011-01-27 06:17:20 EST --- @Mark Sorry about that. I'll file seperate entries and will try to match the style. (In reply to comment #2) 2. What type of exceptions have you seen here? Reply failed callback, is a strange callback, since the receiver, not the sender would receive that callback. That would make for some confusing programming logic. The sender will simply timeout, and not get the reply, and has to act accordingly. But I'm not sure the receiver needs to be notified. I haven't /seen/ any exceptions, but I would assume any exception that can be thrown by a normal Channel#send could come up here, since a Channel#send is what happens. The RpcCallback interface contains both callbacks that are invoked on the sender (leftOver) and receiver (replyRequest) side. If that isn't confusing, I don't see why adding one would be. The specific case where I felt the need for such a callback was one where I was shuttling instances across nodes -- by shuttling I mean removing them from one and putting them on the other. I would receive a request through the RpcChannel for an instance, look it up, unregister it locally, pack it in the reply, send it. If the sending failed, I would want to re-register it locally, so as not to lose data. Whatever you may think of that usage, the fact remains that there's a discrepancy between requests on an RpcChannel, where the sender is notified of communication errors, and replies on the RpcChannel, where he (the sender of the reply) isn't. Even though in both cases it's the same Channel#send that is performed. 3. The external loaders IMHO don't belong here. For the applications that wish to provide custom class loading, I would simply send messages using the ByteMessage class. That way you have full control over what is happening. It's true, you could use ByteMessages. Although as an API user, your code would become more clunky, and you'd lose the ability to quickly look up the message's class. Wouldn't it be nice to have, though? It makes things easier, cleaner and doesn't add any significant overhead. Also, as things stand, the tribes API is somewhat misleading in that it offers to send Serializable messages (methods like Channel#send take Serializable arguments), when in practice all your app's classes are excluded, no matter how Serializable they may be. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] New: Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 Summary: Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call Product: Tomcat 7 Version: 7.0.6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Cluster AssignedTo: dev@tomcat.apache.org ReportedBy: ocos...@zenprise.com The RpcChannel API user registers an RpcCallback to be notified of communication events. However, there is no callback method for the case where the sending of a response message fails. This entry proposes the addition of a callback method for such cases. CAVEAT: this proposal modifies the RpcCallback interface. RpcCallback is currently implemented by at least four tomcat classes, EchoRpcTest in org.apache.catalina.tribes.demos, and AbstractReplicatedMap, ReplicatedMap ad LazyReplicatedMap in org.apache.catalina.tribes.tipis. The attached patch does not include the implementation of the additional interface method for those classes, as this coder did not feel qualified to tell how it should be implemented. They could probably simply be NOOPs, however. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #1 from Olivier Costet ocos...@zenprise.com 2011-01-27 06:57:27 EST --- Reproducing comments from https://issues.apache.org/bugzilla/show_bug.cgi?id=50648: Filip Hanik wrote: 2. What type of exceptions have you seen here? Reply failed callback, is a strange callback, since the receiver, not the sender would receive that callback. That would make for some confusing programming logic. The sender will simply timeout, and not get the reply, and has to act accordingly. But I'm not sure the receiver needs to be notified. I haven't /seen/ any exceptions, but I would assume any exception that can be thrown by a normal Channel#send could come up here, since a Channel#send is what happens. The RpcCallback interface contains both callbacks that are invoked on the sender (leftOver) and receiver (replyRequest) side. If that isn't confusing, I don't see why adding one would be. The specific case where I felt the need for such a callback was one where I was shuttling instances across nodes -- by shuttling I mean removing them from one and putting them on the other. I would receive a request through the RpcChannel for an instance, look it up, unregister it locally, pack it in the reply, send it. If the sending failed, I would want to re-register it locally, so as not to lose data. Whatever you may think of that usage, the fact remains that there's a discrepancy between requests on an RpcChannel, where the sender is notified of communication errors, and replies on the RpcChannel, where he (the sender of the reply) isn't. Even though in both cases it's the same Channel#send that is performed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50670] New: Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes
https://issues.apache.org/bugzilla/show_bug.cgi?id=50670 Summary: Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes Product: Tomcat 7 Version: 7.0.6 Platform: All OS/Version: All Status: NEW Keywords: PatchAvailable Severity: enhancement Priority: P2 Component: Cluster AssignedTo: dev@tomcat.apache.org ReportedBy: ocos...@zenprise.com Since the tribes classes are loaded by the tomcat loader, if the messages sent through tribes are instances of classes defined in the webapp, attemps to deserialize them will fail. AbstractReplicatedMap includes a mechanism for the API user to specify class loaders to be used when deserializing map entries. This entry proposes a similar mechanism for the RpcChannel. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50670] Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes
https://issues.apache.org/bugzilla/show_bug.cgi?id=50670 --- Comment #1 from Olivier Costet ocos...@zenprise.com 2011-01-27 08:46:47 EST --- Reproducing comments from https://issues.apache.org/bugzilla/show_bug.cgi?id=50648: Filip Hanik wrote: 3. The external loaders IMHO don't belong here. For the applications that wish to provide custom class loading, I would simply send messages using the ByteMessage class. That way you have full control over what is happening. It's true, you could use ByteMessages. Although as an API user, your code would become more clunky, and you'd lose the ability to quickly look up the message's class. Wouldn't it be nice to have, though? It makes things easier, cleaner and doesn't add any significant overhead. Also, as things stand, the tribes API is somewhat misleading in that it offers to send Serializable messages (methods like Channel#send take Serializable arguments), when in practice all your app's classes are excluded, no matter how Serializable they may be. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50670] Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes
https://issues.apache.org/bugzilla/show_bug.cgi?id=50670 --- Comment #2 from Olivier Costet ocos...@zenprise.com 2011-01-27 08:47:54 EST --- Created an attachment (id=26560) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26560) svn diff -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #2 from Olivier Costet ocos...@zenprise.com 2011-01-27 08:49:08 EST --- Created an attachment (id=26561) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26561) svn diff CAVEAT: this proposal modifies the RpcCallback interface. RpcCallback is currently implemented by at least four tomcat classes, EchoRpcTest in org.apache.catalina.tribes.demos, and AbstractReplicatedMap, ReplicatedMap ad LazyReplicatedMap in org.apache.catalina.tribes.tipis. The attached patch does not include the implementation of the additional interface method for those classes, as this coder did not feel qualified to tell how it should be implemented. They could probably simply be NOOPs, however. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50648] RpcChannel improvements
https://issues.apache.org/bugzilla/show_bug.cgi?id=50648 --- Comment #4 from Olivier Costet ocos...@zenprise.com 2011-01-27 08:50:53 EST --- Filed separe enhancement requests: https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 (replyFailed) https://issues.apache.org/bugzilla/show_bug.cgi?id=50670 (class loaders) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642 --- Comment #2 from Mark Thomas ma...@apache.org 2011-01-27 08:41:35 EST --- Looking at the KeepAliveCache more closely, the currently solution is the wrong approach. Because the thread only exists for as long as it is needed and is re-created as necessary it has to be dealt with on web application stop. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: [VOTE] Release build 6.0.31
On 01/27/2011 10:30 AM, Konstantin Kolinko wrote: 2011/1/25 jean-frederic clerejfcl...@gmail.com: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [x] Beta That is because of issue observed with Nio connector. https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 I am not saying broken, because other connectors run OK for me. Though, as 6.0.31 goal was to resolve regression with Nio it does not quite serve that purpose. The above mentioned issue is present in 6.0.30 as well. Ok then we should go for a 6.0.32 once it is solved. Cheers Jean-Frederic Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50673] New: Error when stopping Tomcat using services.msc
https://issues.apache.org/bugzilla/show_bug.cgi?id=50673 Summary: Error when stopping Tomcat using services.msc Product: Tomcat 7 Version: 7.0.6 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Packaging AssignedTo: dev@tomcat.apache.org ReportedBy: apa...@scribeofthenile.com When stopping Tomcat using services.msc, an error message is displayed: Windows could not stop the Apache Tomcat 7 service on Local Computer. Error 109: The pipe has been ended. Despite this error, Tomcat appears to stop normally. No such problem was encountered in 6.0.29. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50674] New: Some maven pom improvments
https://issues.apache.org/bugzilla/show_bug.cgi?id=50674 Summary: Some maven pom improvments Product: Taglibs Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Standard Taglib AssignedTo: dev@tomcat.apache.org ReportedBy: ol...@apache.org Hello, Here patches with some improvments for taglibs maven build. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50674] Some maven pom improvments
https://issues.apache.org/bugzilla/show_bug.cgi?id=50674 --- Comment #1 from olamy ol...@apache.org 2011-01-27 11:06:34 EST --- Created an attachment (id=26562) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26562) taglibs parent patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50674] Some maven pom improvments
https://issues.apache.org/bugzilla/show_bug.cgi?id=50674 --- Comment #2 from olamy ol...@apache.org 2011-01-27 11:07:10 EST --- Created an attachment (id=26563) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26563) taglibs standard patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50673] Error when stopping Tomcat using services.msc
https://issues.apache.org/bugzilla/show_bug.cgi?id=50673 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added OS/Version||All --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 11:15:10 EST --- Confirming. (Win XP SP3, Tomcat 7.0.6) The following command net start Tomcat7 executes successfully net stop Tomcat7 apparently fails, printing localized version of error message like the one reported by OP. Repeating net stop Tomcat7 prints message that the service has not been started. 1. This an issue with Commons Daemon service wrapper (procrun). The issue should be reported there. Tomcat 7.0.6 and 6.0.30 use Commons Daemon 1.0.5. https://issues.apache.org/jira/browse/DAEMON 2. Apparently it is just cosmetics. It does not break operation. Though some external scripts might be affected. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50651] NPE in InternalNioOutputBuffer.recycle
https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 --- Comment #10 from Filip Hanik fha...@apache.org 2011-01-27 11:24:16 EST --- (In reply to comment #9) Created an attachment (id=26557) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26557) [details] 2011-01-27_tc6_50651_CoyoteAdapter.patch Patch, in addition to the previous one: Recycle request and response in CoyoteAdapter#log() only if they were created there. +1 to this one. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 Filip Hanik fha...@apache.org changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Filip Hanik fha...@apache.org 2011-01-27 11:33:32 EST --- (In reply to comment #2) Created an attachment (id=26561) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26561) [details] svn diff CAVEAT: this proposal modifies the RpcCallback interface. RpcCallback is currently implemented by at least four tomcat classes, EchoRpcTest in org.apache.catalina.tribes.demos, and AbstractReplicatedMap, ReplicatedMap ad LazyReplicatedMap in org.apache.catalina.tribes.tipis. The attached patch does not include the implementation of the additional interface method for those classes, as this coder did not feel qualified to tell how it should be implemented. They could probably simply be NOOPs, however. I still don't understand this enhancement. What is the possibly use case for implementing replyFailed. The callback method replyFailed would get called to the receiver. And this is backwards. There is nothing the receiver can do if reply fails. There are no actions to be taken. It wont allow the receiver to retry the attempt. So the method is at best a no-op, but really just a method one has to implement with zero benefit. The sender still has to make a decision on what to do without a reply. best Filip -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1064187 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Thu Jan 27 16:38:08 2011 New Revision: 1064187 URL: http://svn.apache.org/viewvc?rev=1064187view=rev Log: votes 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=1064187r1=1064186r2=1064187view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 27 16:38:08 2011 @@ -105,25 +105,25 @@ PATCHES PROPOSED TO BACKPORT: Include context name in reload and stop log statements. Based on the patch by Marc Guillemot. http://people.apache.org/~kkolinko/patches/2011-01-23_tc6_48822.patch - +1: kkolinko, markt + +1: kkolinko, markt, fhanik -1: * Followup to r1061433 Be consistent with locks on sessionCreationTiming, sessionExpirationTiming in DeltaManager.resetStatistics(): use the same lock as elsewhere. http://svn.apache.org/viewvc?rev=1062398view=rev - +1: kkolinko, markt + +1: kkolinko, markt, fhanik -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 NPE in InternalNioOutputBuffer.recycle() https://issues.apache.org/bugzilla/attachment.cgi?id=26549 - +1: kkolinko, markt + +1: kkolinko, markt, fhanik -1: Additional patch: Recycle request and response in CoyoteAdapter#log() only if they were created there. https://issues.apache.org/bugzilla/attachment.cgi?id=26557 - +1: kkolinko + +1: kkolinko, fhanik -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Mark Thomas ma...@apache.org 2011-01-27 11:42:05 EST --- I believe I have a working patch but I have been unable to trigger the creation of the keep-alive thread to test it. A simple test case that triggers this thread creation is needed to resolve this issue. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1064189 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Thu Jan 27 16:44:32 2011 New Revision: 1064189 URL: http://svn.apache.org/viewvc?rev=1064189view=rev Log: Vote 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=1064189r1=1064188r2=1064189view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 27 16:44:32 2011 @@ -125,5 +125,5 @@ PATCHES PROPOSED TO BACKPORT: Recycle request and response in CoyoteAdapter#log() only if they were created there. https://issues.apache.org/bugzilla/attachment.cgi?id=26557 - +1: kkolinko, fhanik + +1: kkolinko, fhanik, markt -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Regarding c:forEach and memory usage
All, Today's (duplicate) bug report about held references in JSTL tags has me thinking. What is the resistance to fixing the problem of object retention in these tags? JSP 1.8.2 says that all page-scoped objects are released after the response is written or the request is forwarded to another handler. Doesn't that mean that something like this: c:set var=foos / c:forEach var=foos items=$foos ... /c:forEach will violate the spec by holding-on to the foos list indefinitely instead of flushing it after the response has been sent? I mean, I certainly understand the complaints being filed in BZ because, hey, the tags are holding onto these references and potentially eating up lots of memory. On the other hand, what's the resistance on the Tomcat side to fixing this? I can think of a couple of reasons: 1. This is a spec-compliance issue and the stance of the Tomcat team is that releasing these references violates the spec, and so it won't be done. 2. It's easy to disable tag pooling via configuration, which has the same effect as nulling all the data in these tag handlers. Since it's easy to disable tag pooling, there is no need to modify anything. 3. Nobody feels like writing a patch. I'd love to hear some comments. Thanks, -chris signature.asc Description: OpenPGP digital signature
Re: Regarding c:forEach and memory usage
On 27/01/2011 16:54, Christopher Schultz wrote: I'd love to hear some comments. It is a simple trade-off. Enable pooling, use more memory, have less GC vs Disable pooling, use less memory, have more GC The memory/GC required will vary depending on which tags are used and how they are used. I think this is a case where more education is required on the content of the JSP specification. The original bug [1] and [2] are well worth reading. Mark [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=25623 [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=16001 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat 5.5.32 Build
On 01/22/2011 11:01 AM, Jim Jagielski wrote: [X] Stable - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50640] Keystore in AbstractEndpoint doesn't have to be a file
https://issues.apache.org/bugzilla/show_bug.cgi?id=50640 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Mark Thomas ma...@apache.org 2011-01-27 12:40:00 EST --- The keystoreFile and truststoreFile attributes are intended to point to files. Given that, converting them to an absolute path in the setters seems reasonable. Whilst the BIO JSSE implementation does double check that an absolute path has been provided, the NIO JSSE implementation does not. I am more inclined to remove the double check from the BIO implementation than I am to duplicate it in NIO. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50627] Bug in Tomcat Comet. Event CometEvent.EventType.END is not fired when connection closed.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50627 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas ma...@apache.org 2011-01-27 12:42:51 EST --- Some APR fixes were also required for comet. These will also be in 7.0.7 onwards. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642 --- Comment #4 from Christopher Schultz ch...@christopherschultz.net 2011-01-27 12:43:04 EST --- Created an attachment (id=26564) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26564) Servlet that should trigger this thread to be created It's ugly, but it gets the job done. Stay away from SecurityManager :) You can run it from CLI, too. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50673] Error when stopping Tomcat using services.msc
https://issues.apache.org/bugzilla/show_bug.cgi?id=50673 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 12:48:44 EST --- I created https://issues.apache.org/jira/browse/DAEMON-195 I am closing this issue as INVALID - it is not ours. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #4 from Olivier Costet ocos...@zenprise.com 2011-01-27 12:55:27 EST --- (In reply to comment #3) I still don't understand this enhancement. What is the possibly use case for implementing replyFailed. The callback method replyFailed would get called to the receiver. And this is backwards. There is nothing the receiver can do if reply fails. There are no actions to be taken. It wont allow the receiver to retry the attempt. So the method is at best a no-op, but really just a method one has to implement with zero benefit. The sender still has to make a decision on what to do without a reply. To reiterate: The specific case where I felt the need for such a callback was one where I was shuttling objects across nodes -- by shuttling I mean removing them from one and putting them on the other. I would receive a request for a specific object through the RpcChannel, look the object up, unregister it locally, pack it in the reply, send the reply. If the sending failed, I would want to re-register the object locally, so as not to lose data. What is it that makes you consider this use-case invalid? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 Olivier Costet ocos...@zenprise.com changed: What|Removed |Added Status|NEEDINFO|NEW -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: Regarding c:forEach and memory usage
On Thu, Jan 27, 2011 at 11:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: ... I'd love to hear some comments. Some additional background: https://issues.apache.org/bugzilla/show_bug.cgi?id=33934 I haven't looked at the patch, so I'm not sure exactly how that got solved... -- Kris Schneider - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642 --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 13:22:23 EST --- Created an attachment (id=26566) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26566) Alternative implementation of the servlet Alternative implementation of the servlet, now using only official API to trigger the issue. Reflection is used only to inspect the state afterwards. To map the servlet: servlet servlet-nameissue50642/servlet-name servlet-classissue50642.HttpClientServlet/servlet-class /servlet servlet-mapping servlet-nameissue50642/servlet-name url-pattern/issue50642/url-pattern /servlet-mapping When being run as a servlet in TC 7.0.x it prints: KeepAliveThread: null, cl=null KeepAliveThread: Thread[Keep-Alive-Timer,8,system], cl=WebappClassLoader context: /examples delegate: false repositories: /WEB-INF/classes/ -- Parent Classloader: org.apache.catalina.loader.StandardClassLoader@19f953d -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50642] keepAliveProtection doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=50642 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEEDINFO|NEW -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1064252 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/catalina/connector/CoyoteAdapter.java java/org/apache/coyote/http11/InternalNioOutputBuffer.java webapps/docs/changelog.xml
Author: kkolinko
Date: Thu Jan 27 18:43:18 2011
New Revision: 1064252
URL: http://svn.apache.org/viewvc?rev=1064252view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50651
Fix NPE in InternalNioOutputBuffer.recycle().
- Do not throw NPE when recycle() is called more than once.
- Do not recycle the request in CoyoteAdapter#log() if it was not created there.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1064252r1=1064251r2=1064252view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 27 18:43:18 2011
@@ -114,16 +114,3 @@ PATCHES PROPOSED TO BACKPORT:
http://svn.apache.org/viewvc?rev=1062398view=rev
+1: kkolinko, markt, fhanik
-1:
-
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50651
- NPE in InternalNioOutputBuffer.recycle()
- https://issues.apache.org/bugzilla/attachment.cgi?id=26549
- +1: kkolinko, markt, fhanik
- -1:
-
- Additional patch:
- Recycle request and response in CoyoteAdapter#log() only if they were
- created there.
- https://issues.apache.org/bugzilla/attachment.cgi?id=26557
- +1: kkolinko, fhanik, markt
- -1:
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=1064252r1=1064251r2=1064252view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
Thu Jan 27 18:43:18 2011
@@ -349,9 +349,10 @@ public class CoyoteAdapter implements Ad
Request request = (Request) req.getNote(ADAPTER_NOTES);
Response response = (Response) res.getNote(ADAPTER_NOTES);
+boolean create = false;
if (request == null) {
-
+create = true;
// Create objects
request = connector.createRequest();
request.setCoyoteRequest(req);
@@ -374,8 +375,10 @@ public class CoyoteAdapter implements Ad
connector.getService().getContainer().logAccess(
request, response, time, true);
-request.recycle();
-response.recycle();
+if (create) {
+request.recycle();
+response.recycle();
+}
}
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=1064252r1=1064251r2=1064252view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
Thu Jan 27 18:43:18 2011
@@ -348,9 +348,10 @@ public class InternalNioOutputBuffer
// Recycle Request object
response.recycle();
-socket.getBufHandler().getWriteBuffer().clear();
-
-socket = null;
+if (socket != null) {
+socket.getBufHandler().getWriteBuffer().clear();
+socket = null;
+}
pos = 0;
lastActiveFilter = -1;
committed = false;
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=1064252r1=1064251r2=1064252view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Thu Jan 27 18:43:18 2011
@@ -43,6 +43,16 @@
!-- Section names:
General, Catalina, Coyote, Jasper, Cluster, Webapps, Other
--
+section name=Tomcat 6.0.32 (jfclere)
+ subsection name=Coyote
+changelog
+ fix
+bug50651/bug: Fix NPE in InternalNioOutputBuffer.recycle().
+(kkolinko)
+ /fix
+/changelog
+ /subsection
+/section
section name=Tomcat 6.0.31 (jfclere)
subsection name=Catalina
changelog
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50651] NPE in InternalNioOutputBuffer.recycle
https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 13:49:54 EST --- Both patches were applied and will be in 6.0.32. As I mentioned, the same changes to TC7 are already applied in r1022478 (7.0.4) and r1059548 (- 7.0.7). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1064254 - in /tomcat/tc6.0.x/trunk: ./ STATUS.txt java/org/apache/catalina/ha/session/DeltaManager.java webapps/docs/changelog.xml
Author: kkolinko Date: Thu Jan 27 18:58:55 2011 New Revision: 1064254 URL: http://svn.apache.org/viewvc?rev=1064254view=rev Log: Followup to r1061433 Be consistent with locks on sessionCreationTiming, sessionExpirationTiming in DeltaManager.resetStatistics(): use the same lock as elsewhere. Modified: tomcat/tc6.0.x/trunk/ (props changed) tomcat/tc6.0.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/session/DeltaManager.java tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc6.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Jan 27 18:58:55 2011 @@ -1 +1 @@ -/tomcat/trunk:601180,606992,612607,630314,640888,652744,653247,666232,673796,673820,677910,683969,683982,684001,684081,684234,684269-684270,685177,687503,687645,689402,690781,691392,691805,692748,693378,694992,695053,695311,696780,696782,698012,698227,698236,698613,699427,699634,701355,709294,709811,709816,710063,710066,710125,710205,711126,711600,712461,712467,713953,714002,718360,719119,719124,719602,719626,719628,720046,720069,721040,721286,721708,721886,723404,723738,726052,727303,728032,728768,728947,729057,729567,729569,729571,729681,729809,729815,729934,730250,730590,731651,732859,732863,734734,740675,740684,742677,742697,742714,744160,744238,746321,746384,746425,747834,747863,748344,750258,750291,750921,751286-751287,751289,751295,752323,753039,757335,757774,758249,758365,758596,758616,758664,759074,761601,762868,762929,762936-762937,763166,763183,763193,763228,763262,763298,763302,763325,763599,763611,763654,763681,763706,764985,764997,765662,768335,769979,770716,77 0809,770876,772872,776921,776924,776935,776945,777464,777466,777576,777625,778379,778523-778524,781528,781779,782145,782791,783316,783696,783724,783756,783762,783766,783863,783934,784453,784602,784614,785381,785688,785768,785859,786468,786487,786490,786496,786667,787627,787770,787985,789389,790405,791041,791184,791194,791224,791243,791326,791328,791789,792740,793372,793757,793882,793981,794082,794673,794822,795043,795152,795210,795457,795466,797168,797425,797596,797607,802727,802940,804462,804544,804734,805153,809131,809603,810916,810977,812125,812137,812432,813001,813013,813866,814180,814708,814876,815972,816252,817442,817822,819339,819361,820110,820132,820874,820954,821397,828196,828201,828210,828225,828759,830378-830379,830999,831106,831774,831785,831828,831850,831860,832214,832218,833121,833545,834047,835036,835336,836405,881396,881412,883130,883134,883146,883165,883177,883362,883565,884341,885038,885231,885241,885260,885901,885991,886019,888072,889363,889606,889716,8901 39,890265,890349-890350,890417,891185-891187,891583,892198,892341,892415,892464,892555,892812,892814,892817,892843,892887,893321,893493,894580,894586,894805,894831,895013,895045,895057,895191,895392,895703,896370,896384,897380-897381,897776,898126,898256,898468,898527,898555,898558,898718,898836,898906,899284,899348,899420,899653,899769-899770,899783,899788,899792,899916,899918-899919,899935,899949,903916,905020,905151,905722,905728,905735,907311,907513,907538,907652,907819,907825,907864,908002,908721,908754,908759,909097,909206,909212,909525,909636,909869,909875,909887,910266,910370,910442,910471,910485,910974,915226,915737,915861,916097,916141,916157,916170,917598,917633,918093,918489,918594,918684,918787,918792,918799,918803,918885,919851,919914,920025,920055,920298,920449,920596,920824,920840,921444,922010,926716,927062,927621,928482,928695,928732,928798,931709,932357,932967,935105,935983,939491,939551,940064,941356,941463,944409,944416,945231,945808,945835,945841,946686 ,948057,950164,950596,950614,950851,950905,951615,953434,954435,955648,955655,956832,957130,957830,958192,960701,961948,962865,962872,962881,962900,963106,963865,963868,964614,966177-966178,966292,966692,966863,981815,988448,991837,993042,1001955,1002185,1002263,1002274,1002349,1002359,1002362,1002481,1002514,1003461,1003481,1003488,1003556,1003572,1003581,1003861,1004393,1004409,1004415,1004868-1004869,1004912,1005452,1005467,1005647,1005802,1022120,1022134,1022323,1022415,1022606,1022623,1024224,1024251,1026042,1026784,1026912,1026920,1029767,1033415,1033448,1033842,1033897,1037715,1037794,1037887,1037924,1038041,1042022,1042029,1042447,1042452,1042494,1044944,1044987,1050249,1055055,1055236,1055458,1055975,1056264,1056828,1056889,1059881,1061412,1061442,1061446
svn commit: r1064257 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/core/ webapps/docs/
Author: kkolinko
Date: Thu Jan 27 19:06:19 2011
New Revision: 1064257
URL: http://svn.apache.org/viewvc?rev=1064257view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48822
Include context name in reload and stop log statements.
Based on the patch by Marc Guillemot.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_es.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_fr.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1064257r1=1064256r2=1064257view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 27 19:06:19 2011
@@ -100,10 +100,3 @@ PATCHES PROPOSED TO BACKPORT:
(kkolinko: not tested, thus not voting yet)
+1:
-1:
-
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48822
- Include context name in reload and stop log statements.
- Based on the patch by Marc Guillemot.
- http://people.apache.org/~kkolinko/patches/2011-01-23_tc6_48822.patch
- +1: kkolinko, markt, fhanik
- -1:
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties?rev=1064257r1=1064256r2=1064257view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings.properties
Thu Jan 27 19:06:19 2011
@@ -111,17 +111,18 @@ standardContext.parameter.duplicate=Dupl
standardContext.parameter.required=Both parameter name and parameter value are
required
standardContext.reloadingCompleted=Reloading this Context is completed
standardContext.reloadingFailed=Reloading this Context failed due to previous
errors
-standardContext.reloadingStarted=Reloading this Context has started
+standardContext.reloadingStarted=Reloading Context with name [{0}] has started
standardContext.resourcesStart=Error starting static Resources
standardContext.securityConstraint.pattern=Invalid url-pattern {0} in
security constraint
standardContext.servletMap.name=Servlet mapping specifies an unknown servlet
name {0}
standardContext.servletMap.pattern=Invalid url-pattern {0} in servlet mapping
standardContext.startCleanup=Exception during cleanup after start failed
standardContext.startFailed=Context [{0}] startup failed due to previous errors
+standardContext.startingContext=Exception starting Context with name [{0}]
standardContext.startingLoader=Exception starting Loader
standardContext.startingManager=Exception starting Manager
standardContext.startingWrapper=Exception starting Wrapper for servlet {0}
-standardContext.stoppingContext=Exception stopping Context
+standardContext.stoppingContext=Exception stopping Context with name [{0}]
standardContext.stoppingLoader=Exception stopping Loader
standardContext.stoppingManager=Exception stopping Manager
standardContext.stoppingWrapper=Exception stopping Wrapper for servlet {0}
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_es.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_es.properties?rev=1064257r1=1064256r2=1064257view=diff
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_es.properties
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/LocalStrings_es.properties
Thu Jan 27 19:06:19 2011
@@ -100,7 +100,7 @@ standardContext.parameter.duplicate = Du
standardContext.parameter.required = Es necesario poner nombre de
par\u00e1metro y valor de par\u00e1metro
standardContext.reloadingCompleted = Se ha completado la Regarga de este
Contexto
standardContext.reloadingFailed = Fall\u00f3 la recarga de este Contexto
debido a errores previos
-standardContext.reloadingStarted = Ha comenzado la recarga de este Contexto
+standardContext.reloadingStarted = Ha comenzado la recarga de Contexto [{0}]
standardContext.resourcesStart = Error arrancando Recursos est\u00e1ticos
standardContext.securityConstraint.pattern = url-pattern {0} inv\u00e1lida
en restricci\u00f3n de seguridad
standardContext.servletMap.name = El mapeo de Servlet especifica un nombre de
servlet desconocido {0}
@@ -110,7 +110,7 @@ standardContext.startFailed = Fall\u00f3
standardContext.startingLoader = Excepci\u00f3n arrancando Cargador
standardContext.startingManager = Excepci\u00f3n
DO NOT REPLY [Bug 48822] Include contest name in reload and stop log statements
https://issues.apache.org/bugzilla/show_bug.cgi?id=48822 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 14:07:38 EST --- Fixed in 6.0.x with r1064257 and will be in 6.0.32. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50650] Connector#setProperty(String, String) does not set explicit property values
https://issues.apache.org/bugzilla/show_bug.cgi?id=50650 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50496] AccessLogValve not logging size correctly for %B with enabled compression
https://issues.apache.org/bugzilla/show_bug.cgi?id=50496 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Mark Thomas ma...@apache.org 2011-01-27 14:38:18 EST --- After some reflection, I think this does need to be a WONTFIX for 6.0.x. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1064275 - /tomcat/trunk/webapps/docs/jasper-howto.xml
Author: markt Date: Thu Jan 27 19:43:23 2011 New Revision: 1064275 URL: http://svn.apache.org/viewvc?rev=1064275view=rev Log: Typo Modified: tomcat/trunk/webapps/docs/jasper-howto.xml Modified: tomcat/trunk/webapps/docs/jasper-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/jasper-howto.xml?rev=1064275r1=1064274r2=1064275view=diff == --- tomcat/trunk/webapps/docs/jasper-howto.xml (original) +++ tomcat/trunk/webapps/docs/jasper-howto.xml Thu Jan 27 19:43:23 2011 @@ -254,8 +254,8 @@ set this to codetrue/code./li section name=Web Application Compilation pUsing Ant is the preferred way to compile web applications using JSPC. Note -that when pre-compiling JSPs, SMAP information only be included in the final -classes if suppressSmap is false and compile is true. +that when pre-compiling JSPs, SMAP information will only be included in the +final classes if suppressSmap is false and compile is true. Use the script given below (a similar script is included in the deployer download) to precompile a webapp: /p - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50631] InternalNioInputBuffer should honor maxHttpHeadSize
https://issues.apache.org/bugzilla/show_bug.cgi?id=50631
Konstantin Kolinko knst.koli...@gmail.com changed:
What|Removed |Added
OS/Version||All
--- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27
15:26:07 EST ---
For reference: this issue was created from the following thread on users@:
http://tomcat.markmail.org/thread/wjuhhyfllplmyly5
There is the following code in InternalNioInputBuffer#fill(boolean, boolean)
both in 6.0.31 and in 7.0.6:
if (parsingHeader) {
if (lastValid == buf.length) {
throw new IllegalArgumentException
(sm.getString(iib.requestheadertoolarge.error));
}
and it should take care of overflows. But there is also
InternalNioInputBuffer#expand(int) which is called from #readSocket().
I thought of the below patch (for trunk, not tested), but I see another
problem: I do not see InternalNioInputBuffer.buf being recycled (shrunk) after
its growth. I suspect that it should not be allowed to grow even when it is
body of the request that we are reading now. In InternalAprInputBuffer.fill()
and InternalInputBuffer.fill() the buffer can be reallocated, but the new
buffer will be of the same size as the old one.
Thus instead of the patch below I suspect that InternalNioInputBuffer.expand()
should fail unconditionally when ( newsize buf.length ).
Index: java/org/apache/coyote/http11/InternalNioInputBuffer.java
===
--- java/org/apache/coyote/http11/InternalNioInputBuffer.java(revision
1064206)
+++ java/org/apache/coyote/http11/InternalNioInputBuffer.java(working copy)
@@ -370,6 +370,10 @@
private void expand(int newsize) {
if ( newsize buf.length ) {
+if (parsingHeader) {
+throw new IllegalArgumentException(
+sm.getString(iib.requestheadertoolarge.error));
+}
byte[] tmp = new byte[newsize];
System.arraycopy(buf,0,tmp,0,buf.length);
buf = tmp;
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
Re: [VOTE] Release build 6.0.31
2011/1/27 jean-frederic clere jfcl...@gmail.com: On 01/27/2011 10:30 AM, Konstantin Kolinko wrote: 2011/1/25 jean-frederic clerejfcl...@gmail.com: The candidates binaries are available here: http://people.apache.org/~jfclere/tomcat-6/v6.0.31/ According to the release process, the 6.0.31 build corresponding to the tag TOMCAT_6_0_31 is: [x] Beta That is because of issue observed with Nio connector. https://issues.apache.org/bugzilla/show_bug.cgi?id=50651 I am not saying broken, because other connectors run OK for me. Though, as 6.0.31 goal was to resolve regression with Nio it does not quite serve that purpose. The above mentioned issue is present in 6.0.30 as well. Ok then we should go for a 6.0.32 once it is solved. Regarding the status for 6.0.32: 1. The fix for the above mentioned regression has been applied. 2. Of the currently open issues the following one is of concern: https://issues.apache.org/bugzilla/show_bug.cgi?id=50631 InternalNioInputBuffer should honor maxHttpHeadSize It affects 6.0 and 7.0. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50664] connectUsingDriver should use thread context classloader to load driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=50664 balusc bal...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID OS/Version||All --- Comment #1 from balusc bal...@gmail.com 2011-01-27 16:13:41 EST --- Reject this. The problem is caused by misconfiguration in Spring. But still, it may be safer to grab the classloader from the thread context. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
[Tomcat Wiki] Update of PoweredBy by andy smith
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by andy smith.
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=304rev2=305
--
=== Derecho.com ===
{{http://www.derecho.com/_img/derecho_dot_com_logo.gif}}
[[http://www.derecho.com/|Derecho.com]] Spanish law page, the biggest ebook
publisher, Law content provider and eLaw firm in Spain.
+ === Diecast Stars ===
+ {{http://www.diecaststars.com/skin/frontend/default/diecast/images/logo.png}}
[[http://www.diecaststars.com|diecast]] - Stockists of all major diecast brands.
+
=== DSpace ===
[[http://www.dspace.org/|DSpace]] is an open-source repository for research
materials. It is installed in numerous places, including
[[http://dspace.mit.edu|MIT]] and the
[[http://www.iue.it/LIB/Cadmus/InstallationNotes.shtml|European University
Institute]]. Detailed
[[http://www.dspace.org/technology/system-docs/install.html|installation
instructions]] are available.
@@ -261, +264 @@
{{http://www.neuromice.org/images/banner_neuro_02.gif}}
[[http://www.neuromice.org|NeuroMice]] has their own nice
[[http://www.neuromice.org/poweredBy.sc|PoweredBy]] page.
=== OfferMe.com.au ===
- {{http://www.offerme.com.au/images/layout/logo_home.gif}}
[[http://www.offerme.com.au|www.offerme.com.au]] - OfferMe.com.au is an all new
B2C trading platform in Australia using the Web2.0 concept.
+ {{http://www.offerme.com.au/images/layout/logo_home.gif}}
[[http://www.offerme.com.au|www.offerme.com.au]] - OfferMe.com.au is an all new
B2C trading platform in Australia using the Web2.0 concept.
=== OptusNet ===
{{http://www.optus.com.au/dafiles/OCA/OptusHome/StaticFiles/Images/optus_logo.gif}}
[[http://optusnet.com.au|optusnet.com.au]] - An Australian ISP portal with
multiple brandings serving over 20 million page impressions per month.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50664] connectUsingDriver should use thread context classloader to load driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=50664 --- Comment #2 from Christopher Schultz ch...@christopherschultz.net 2011-01-27 16:44:21 EST --- I am in favor of using the context's WebappClassLoader when configuring a JNDI DataSource defined in context.xml. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #5 from Filip Hanik fha...@apache.org 2011-01-27 16:49:01 EST --- Hi Olivier, yes, I see the use case. I do have a different suggestion for the solution, as there is a significant change. I'm attaching a patch with the summary of 1. Not breaking the existing interfaces 2. Adding better feedback on a failure, and let the replying code decide course of action 3. feedback on success/completion of a reply Ability to handle async message sending. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50667] Tribes | RpcChannel | Add a callback for cases when an error occured sending a reply to an RP call
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667 --- Comment #6 from Filip Hanik fha...@apache.org 2011-01-27 16:50:07 EST --- Created an attachment (id=26567) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26567) Patch to include replyFailed functionality -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50664] connectUsingDriver should use thread context classloader to load driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=50664 --- Comment #3 from Filip Hanik fha...@apache.org 2011-01-27 17:08:04 EST --- (In reply to comment #2) I am in favor of using the context's WebappClassLoader when configuring a JNDI DataSource defined in context.xml. Yes, but this can cause problems when you use a global data source -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50664] connectUsingDriver should use thread context classloader to load driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=50664 --- Comment #4 from Konstantin Kolinko knst.koli...@gmail.com 2011-01-27 17:14:01 EST --- (In reply to comment #2) I am in favor of using the context's WebappClassLoader when configuring a JNDI DataSource defined in context.xml. Note, that context.xml is being read before WebappClassLoader is started. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: [VOTE] Release Tomcat 5.5.32 Build
2011/1/22 Jim Jagielski j...@jagunet.com: [x] Stable Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50677] New: Allow system property variables in catalina.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=50677
Summary: Allow system property variables in catalina.properties
Product: Tomcat 7
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: j...@riggs.me
We currently have two hardcoded variables that we substitute in
catalina.properties, ${catalina.base} and ${catalina.home}. Is there value in
expanding this functionality? Here is my scenario:
I have several apps, app1, app2, etc. I have a shared lib directory of jars
that the apps share. In addition, the apps may have several instances running
in different environments (prod, QA, dev, etc.), and each environment has a
corresponding version of the lib directory. The Tomcat configs for the apps
(catalina.base) are version-controlled.
Now, I want each instance of these apps (catalina.base) to be as portable as
possible without having to make a bunch of changes for each environment. So, I
want to be able to copy the app1-prod catalina.base to app1-qa and not have to
make a lot of local modifications to catalina.properties and friends to make it
work. My init script knows that app1-qa is a QA instance and needs to point to
the lib-qa shared directory. So, I set a system property in the init script
via CATALINA_OPTS: -Dshared.lib.dir=/path/to/lib-qa for QA and
-Dshared.lib.dir=/path/to/lib-prod for production. What I would like to do is
use this system property via ${property.name} in my common.loader in
catalina.properties. The result is that the catalina.base files are the exact
same from a configuration perspective without a bunch of local modifications.
I have created two proposed patches for this functionality. Both work well,
but each one has the potential for some slightly different behavior, so I would
like to hear the thoughts of the developers on each.
--
Proposal A (currently in production use for my environment):
The variable substitution takes place upon retrieval in
CatalinaProperties.getProperty(), pulling in the current value of the system
property. This allows other properties defined in catalina.properties to be
substituted. The (potential) downside or risk is that the value of a
catalina.property value may change over time if the system properties
referenced in its value are changed by the code during the JVM's lifecycle.
--
Proposal B:
The variable substitution takes place in the class initializer,
loadProperties(). This means that every call to
CatalinaProperties.getProperty() will return the same result, with system
property variables replaced with their value at the time the class was loaded.
The downside of this is that properties set in catalina.properties cannot be
used in other properties defined in that file, because they may not yet be set
based on the order they are returned by the Enumeration. This could be worked
around, but it would probably take another iteration over the properties (not
really a big deal).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 50677] Allow system property variables in catalina.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=50677 --- Comment #1 from Jim Riggs j...@riggs.me 2011-01-27 20:56:03 EST --- Created an attachment (id=26568) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26568) Proposal A Substitute on retrieval. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 50677] Allow system property variables in catalina.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=50677 --- Comment #2 from Jim Riggs j...@riggs.me 2011-01-27 20:56:37 EST --- Created an attachment (id=26569) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26569) Proposal B Substitute on initialization. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
Re: Regarding c:forEach and memory usage
It also interacts with tag reinitialization as described here: https://issues.apache.org/bugzilla/show_bug.cgi?id=49589 in that we hang on to the value when the tag is in the pool only to clear it when we use it. I think there are other optimizations that could be done to forEach but have not gotten around to looking for them. On Jan 27, 2011, at 8:54 AM, Christopher Schultz wrote: All, Today's (duplicate) bug report about held references in JSTL tags has me thinking. What is the resistance to fixing the problem of object retention in these tags? JSP 1.8.2 says that all page-scoped objects are released after the response is written or the request is forwarded to another handler. Doesn't that mean that something like this: c:set var=foos / c:forEach var=foos items=$foos ... /c:forEach will violate the spec by holding-on to the foos list indefinitely instead of flushing it after the response has been sent? I mean, I certainly understand the complaints being filed in BZ because, hey, the tags are holding onto these references and potentially eating up lots of memory. On the other hand, what's the resistance on the Tomcat side to fixing this? I can think of a couple of reasons: 1. This is a spec-compliance issue and the stance of the Tomcat team is that releasing these references violates the spec, and so it won't be done. 2. It's easy to disable tag pooling via configuration, which has the same effect as nulling all the data in these tag handlers. Since it's easy to disable tag pooling, there is no need to modify anything. 3. Nobody feels like writing a patch. I'd love to hear some comments. Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Regarding c:forEach and memory usage
On Jan 27, 2011, at 10:14 AM, Kris Schneider wrote: On Thu, Jan 27, 2011 at 11:54 AM, Christopher Schultz ch...@christopherschultz.net wrote: ... I'd love to hear some comments. Some additional background: https://issues.apache.org/bugzilla/show_bug.cgi?id=33934 I haven't looked at the patch, so I'm not sure exactly how that got solved... The original implementation evaluated all EL expressions in doStartTag saving the results in fields that were not cleared until release. The patch changes this so the expressions are evaluated as needed and the results are not saved; each expression is called at most once. In EL mode, only the expression source is retained when the tag is in the pool; in RT mode, the results set by the container are retained per the spec. -- Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
