Re: WebSockets in Tomcat 6
On 3/15/2012 6:54 AM, Mark Thomas wrote:
On 14/03/2012 17:42, Filip Hanik Mailing Lists wrote:
http://people.apache.org/~fhanik/reports/servers/
Attached is a patch that leverages the Tomcat WebSocket API with
minimalistic changes and uses that to implement WebSockets in Tomcat
6.0.x http://people.apache.org/~fhanik/websockets-for-tomcat-6.patch
Nice. There was me hoping the WebSocket support would be a driver for
upgrading to 7.0.x. Oh well. Having the the support in 6.0.x is very nice.
This implementation doesn't touch the endpoints or any real connector
logic, making it risk free. The only change that could do anything,
would be the XXXProcessor +if (statusCode ==
HttpServletResponse.SC_SWITCHING_PROTOCOLS) { +
outputBuffer.addActiveFilter +
(outputFilters[Constants.IDENTITY_FILTER]); +} else
Those look OK to me. I do wonder if the changes to
CometEventImpl#setTimeout() might cause a surprise for someone though.
yes it could, but I doubt it. I felt it was very important to not change the
API for a . release of Tomcat 6 this late in the game.
Instead of calling I can do
((Request)getField(request, event)).protocolSwitch();
and now that you mention it, I will change the patch to do just that. It is
much clearer.
Where it sets an identity filter when the user is switching
protocols. Otherwise Tomcat defaults to chunked encoding. You can
still see Tomcat 8 sends a Transfer-Encoding:chunked as part of a web
socket response.
That should probably be cleaned up although it doesn't matter that much
since no response body is sent back anyway.
This implementation also works with BIO connector, as Tomcat's
CometProcessor interface supports both, and let's the implementer
implement both Comet and non Comet in the same class.
Hopefully this patch shows 1. It's fairly risk free to implement this
in stables branches as Tomcat 6, and possibly Tomcat 7 (as we may
want to treat this as fairly stable and minimize refactoring this
late in the game) 2. Performance of Comet is similar to the non Comet
implementation 3. It took me 4 hours to do this migration, so it's
definitely very easy to work with Comet once you have the bulk work
done (the WebSocket protocol impl by Mark Thomas)
The test suite report is at
http://people.apache.org/~fhanik/reports/servers/
I would suggest we consider this for Tomcat 6(my experience is still
most users are using this version).
I have no problem with that.
For Tomcat 7, I would recommend
it, as it avoids refactoring, but I'm pretty neutral about it.
My only concern is that the issue Costin raised regarding scalability
since this approach retains the HttpProcessor along with the Request and
Response objects. I don't know how much of an issue scalability is going
to turn out to be but given the relatively low impact even of the
generic upgrade changes I think they should be safe. Looking into
back-porting that is next on my to-do list.
That is a valid point. If the chats are long running holding headers in memory,
is a waste.
The other thing to consider for Tomcat 7 is SPDY support in v7, if that is done using the same mechanism, then that may favor the Tomcat 8
approach
Filip
Mark
-
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
Re: WebSocket status
On 3/14/2012 8:14 AM, Mark Thomas wrote: On 14/03/2012 10:15, Johno Crawford wrote: On 8/03/2012 9:10 PM, Mark Thomas wrote: On 08/03/2012 09:12, Johno Crawford wrote: What's next / left on the TODO list Mark? Anything I can help out with? Porting the generic HTTP upgrade followed by the WebSocket code to 7.0.x. I don't think there is much for you to do there. WebSocket needs some documentation. My plan was to keep it light and point to the examples / Javadoc as much as possible. Performance / scalability with large numbers of users / connections needs looking at. If I am not mistaken there was talk about adding buffered readers, is this still on the table? Not at the moment because when I tried adding them they did nothing to improve performance of the Autobahn tests. They didn't hinder it either. If you have a test case that demonstrates a use case where they help then I'd be prepared to consider adding them. As I recall, the patch is pretty simple. it would just be a buffer on top of a buffer, as the connectors buffer underneath as well. Filip Maybe a chat example app? After all, everyone else seems to have one ;) At first this felt like double work as there had been some talk and progress regarding a chat example [1] however, I was a little concerned about the security of the implementation (no filtering of html entities), it doesn't line up with the current trunk source and I estimated implementation from scratch to be 30 minutes max. I saw that. I've been focussing on clearing the 7.0.x bug backlog ready for a release (that includes WebSocket) and was planning to look at the chat example once the backlog was clear. I think there are just two bugs left at the moment so I should get there soon. Cheers, Mark - 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
Re: WebSocket status
On 3/2/2012 2:13 AM, Mark Thomas wrote: You can't register on a selector using another thread. Bingo. That explains it. Is that documented anywhere? I'm not sure if the java.nio documentation says it, I think it does. The Selector object is not thread safe. trying to manipulate interestops and selectors from multiple threads, can lead to dead locks I'm off for the weekend, address the other stuff next week. Enjoy the weekend! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
On 3/1/2012 5:33 AM, Mark Thomas wrote: On 01/03/2012 11:31, Mark Thomas wrote: On 28/02/2012 21:29, Mark Thomas wrote: On 28/02/2012 18:53, Filip Hanik - Dev Lists wrote: On 2/28/2012 11:39 AM, Mark Thomas wrote: You may also be able to help with some problems I am having getting non-blocking behaviour between messages with NIO. I'm not 100% clear what is happening yet, but I think it is something like: - HTTP GET (with upgrade request arrives - Upgrade is processed - no ws frame on the wire (yet) so process of handing back to the selector starts - first ws frame arrives - socket is handed back to the selector - selector *does not* trigger indicating there is data to process - some delay of a few seconds - client sends another ws frame - selector triggers - both frames are processed I can take a look at this, I've not seen this behavior before, it's been very accurate. Very similar behaviour has been observed in the unit tests for Comet with the NIO connector ever since they were introduced. Send it my way, I will take a look I have done a little more experimentation and if I comment out line 1231 in the NioEndpoint: unreg(sk, attachment,sk.readyOps()); (part of the NIO Poller) all the problems I see with NIO + Autobahn + non-blocking reads go away. This is consistent with the description above. However, I don't think the solution is as simple as just commenting out this line as that would result in multiple calls to processSocket(), most of which would not be required and each call to processSocket() results in a thread being allocated to process the data. That said, I think some additional logic in process socket could handle this safely. What I think is happening is that because we call SelectionKey.interestOps(0) to prevent the poller triggering multiple times for the same request there is currently a small window where data can arrive for the next request that isn't read by a processing thread and doesn't trigger the poller. I have been thinking about a solution to this but I haven't written any code yet. Where I think we'll end up is with a small window where two poller events may be triggered for the same request which would result in an extra thread being allocated for a short period of time. I know more when I actually write the code. I have a draft patch [1] that seems to fix this. A similar change would be required for the Comet part of Poller.processKey() Thoughts and/or comments? Not knowing the NIO code very well, there might be a better way to achieve the same result that I haven't seen. I am going to take a look at it today. Commenting out a line like that doesn't seem right. It's got to fit in with the flow. The NIO is a fairly sensitive piece of code, and it's easy to break and get problems like that. Filip Mark [1] http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch - 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
Re: WebSocket status
I have a draft patch [1] that seems to fix this. A similar change would be required for the Comet part of Poller.processKey() Thoughts and/or comments? Not knowing the NIO code very well, there might be a better way to achieve the same result that I haven't seen. Mark [1] http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch I took a look at the patch. IMHO it's not the right way to go. You're adding in flags to compensate for the state machine in the selector. And by doing so, you will have the selector run more than it needs to, cause you have read interest turned on, on sockets that you are already processing, wasting CPU cycles. Filip - 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
Re: WebSocket status
Mark, what buffer size are you referring to increase for the web socket tests to all pass? Filip On 3/1/2012 9:42 AM, Mark Thomas wrote: On 01/03/2012 15:03, Filip Hanik - Dev Lists wrote: I have a draft patch [1] that seems to fix this. A similar change would be required for the Comet part of Poller.processKey() Thoughts and/or comments? Not knowing the NIO code very well, there might be a better way to achieve the same result that I haven't seen. Mark [1] http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch I took a look at the patch. IMHO it's not the right way to go. That doesn't surprise me. You know the NIO code better than I do. You're adding in flags to compensate for the state machine in the selector. Yep. On that topic, I couldn't find any decent information on the state machine in the selector. Do you know of any? There was a fair amount of guess work involved investigating this issue and a clearer picture of the state machine would help develop a better patch. And by doing so, you will have the selector run more than it needs to Yep. cause you have read interest turned on, Yep. on sockets that you are already processing, Yep. Agree with you completely up to this point. wasting CPU cycles. This part I wasn't so sure of. There is a problem here that affects WebSocket badly and Comet intermittently and fixing that problem may well require the trade off of additional processing. I compared the NIO blocking figures I have and the NIO non-blocking figures to see if there was a noticeable performance difference. The patch does impact performance. Typically it is3% but for large numbers of small packets it can be as high as ~15%. On this basis my patch is clearly far from ideal. I look forward to seeing what insights you have on how best to solve this for both WebSocket and Comet. Interestingly, I don't recall anything that suggests that this problem affects HTTP although it isn't impossible that there is a very slim window somewhere where HTTP may be affected. Mark - 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
Re: WebSocket status
I see, MessageInbound has hard coded receive buffers. Got it Filip On 3/1/2012 10:13 AM, Filip Hanik - Dev Lists wrote: Mark, what buffer size are you referring to increase for the web socket tests to all pass? Filip On 3/1/2012 9:42 AM, Mark Thomas wrote: On 01/03/2012 15:03, Filip Hanik - Dev Lists wrote: I have a draft patch [1] that seems to fix this. A similar change would be required for the Comet part of Poller.processKey() Thoughts and/or comments? Not knowing the NIO code very well, there might be a better way to achieve the same result that I haven't seen. Mark [1] http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch I took a look at the patch. IMHO it's not the right way to go. That doesn't surprise me. You know the NIO code better than I do. You're adding in flags to compensate for the state machine in the selector. Yep. On that topic, I couldn't find any decent information on the state machine in the selector. Do you know of any? There was a fair amount of guess work involved investigating this issue and a clearer picture of the state machine would help develop a better patch. And by doing so, you will have the selector run more than it needs to Yep. cause you have read interest turned on, Yep. on sockets that you are already processing, Yep. Agree with you completely up to this point. wasting CPU cycles. This part I wasn't so sure of. There is a problem here that affects WebSocket badly and Comet intermittently and fixing that problem may well require the trade off of additional processing. I compared the NIO blocking figures I have and the NIO non-blocking figures to see if there was a noticeable performance difference. The patch does impact performance. Typically it is3% but for large numbers of small packets it can be as high as ~15%. On this basis my patch is clearly far from ideal. I look forward to seeing what insights you have on how best to solve this for both WebSocket and Comet. Interestingly, I don't recall anything that suggests that this problem affects HTTP although it isn't impossible that there is a very slim window somewhere where HTTP may be affected. Mark - 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
On 2/28/2012 11:39 AM, Mark Thomas wrote: Thanks for the feedback. You may also be able to help with some problems I am having getting non-blocking behaviour between messages with NIO. I'm not 100% clear what is happening yet, but I think it is something like: - HTTP GET (with upgrade request arrives - Upgrade is processed - no ws frame on the wire (yet) so process of handing back to the selector starts - first ws frame arrives - socket is handed back to the selector - selector*does not* trigger indicating there is data to process - some delay of a few seconds - client sends another ws frame - selector triggers - both frames are processed I can force this behaviour 100% of the time with the debugger and it looks very similar to the issues we see intermittently with the Comet unit tests where two messages are processed at once. I am wondering if we have a race condition somewhere in the NIO code between: - determining there is no data to read - handling the socket back to the selector - new data arriving and if it is possible that for a particular sequence of events we can end up in the state where there is data to be read but the selector doesn't think so. I would normally assume my non-blocking code is doing something stupid (which it may well be anyway) but the similarity to the problem with the Comet unit test makes me suspect at least one root cause may be elsewhere. Any thoughts appreciated. (Note all of my non-blocking changes are currently sitting on my local hard drive. I can provide them if that would help.) Mark Alright, now that I'm all squared away with Autobahn and test cases running. Is there a specific unit test you have to produce this behavior? That would help me for digging through it. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1295724 - in /tomcat/trunk/webapps/examples/WEB-INF: classes/websocket/EchoMessage.java web.xml
On 3/1/2012 11:42 AM, Mark Thomas wrote: On 01/03/2012 18:27, fha...@apache.org wrote: Author: fhanik Date: Thu Mar 1 18:27:56 2012 New Revision: 1295724 URL: http://svn.apache.org/viewvc?rev=1295724view=rev Log: Allow the examples to configure the buffer on the fly Guess you beat me to it. The config needs to be commented out by default though. sure thing, I would assume for examples app, we'd have the most lenient, not the most safe/secure config. :) Mark - 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
Re: WebSocket status
hi Mark, sorry, I know you posted this earlier, thanks for reposting it to set
me straight.
Yes, it can make sense that you see the behavior you are. But in theory you
shouldn't.
If you call readSocket(false,bytes,off,maxRead), all the socket does is that it checks in the OS socket buffer to see if there is any data
available. If not, it immediately returns 0. This is the non blocking part of it. Now, since you call this part of a servlet, the socket is
set in zero interest mode (meaning, we don't want the socket poller to be reacting if data is coming in, this will cause concurrency issues
and poor performance)
So, what happens is that
1. You call read(block=false)
2. Your 1) call finishes, returns 0
3. Data arrives, ends up in the OS TCP receive buffer
4. You finish your servlet request lifecycle and return the socket to the
poller, with read interest
In step four, the poller should awake immediately for a read operation if there
is data in the.
However, what seems to be happening is a misuse of NIO in Http11NioProtocol
@Override
protected void upgradePoll(SocketWrapperNioChannel socket,
ProcessorNioChannel processor) {
connections.put(socket.getSocket(), processor);
SelectionKey key = socket.getSocket().getIOChannel().keyFor(
socket.getSocket().getPoller().getSelector());
key.interestOps(SelectionKey.OP_READ);
((KeyAttachment) socket).interestOps(
SelectionKey.OP_READ);
}
You can't register on a selector using another thread. This is most likely the cause of the problem, is the incorrect registration. You see,
you shouldn't be touching the poller from anywhere in the code itself. When the SocketProcessor returns, it needs to decide if the socket
goes back into the poller, for what operation, or if it needs to be cancelled/closed.
If you look at SocketProcessor.run method, the very last thing that is
happening here is
final SelectionKey fk = key;
final int intops = handshake;
final KeyAttachment ka = (KeyAttachment)fk.attachment();
ka.getPoller().add(socket,intops);
But my guess is that these new if/else clauses are bypassing this.
I'll work on a fix for this, and check it in so that you can see.
On a completely separate note, this WebSocket implementation seems to have caused a lot of duplicate code. I would have assumed the most
simple way to implement WebSockets would be on top of the existing Comet implementation. This implementation already generates the READ
event when data arrives, and you have the ability to check available() to see if there is more data to be read. This would too have avoided
single byte reads from the system buffers, since Comet reads in as much as possible, and then you can single byte read from Java heap memory.
The only thing you would have had to do, had you used Comet, was to turn off the filters that cause chunked-encoding, and you would have had
access to raw data directly from within. All the Upgrade classes, everything, would have sat directly in the highest level, never touching
the low level connectors.
Something food for thought :)
On 3/1/2012 11:15 AM, Mark Thomas wrote:
On 01/03/2012 18:01, Filip Hanik - Dev Lists wrote:
Alright, now that I'm all squared away with Autobahn and test cases
running. Is there a specific unit test you have to produce this behavior?
That would help me for digging through it.
Assuming you are running trunk, then what you'll currently have is NIO
is a purely blocking mode. The tests should all pass and take a minute
or two to run. If you apply the following patch, you'll enable
non-blocking reads for NIO at which point large numbers of tests should
start to fail / take forever / timeout. I usually just run the section 1
tests (i.e. cases: [1.*]) in fuzzing_client_spec.json when
investigating these are they are mostly small payloads easy to trace.
HTH,
Mark
--- a/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
+++ b/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
@@ -104,12 +104,10 @@ public class UpgradeNioProcessor extends
UpgradeProcessorNioChannel {
@Override
public int read(boolean block, byte[] bytes, int off, int len)
throws IOException {
-// TODO Implement non-blocking reads. Should be as simple as
replacing
-// true with block in the two lines below
if (len maxRead) {
-return readSocket(true, bytes, off, maxRead);
+return readSocket(block, bytes, off, maxRead);
} else {
-return readSocket(true, bytes, off, len);
+return readSocket(block, bytes, off, len);
}
}
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional
Re: svn commit: r1295978 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11NioProtocol.java upgrade/UpgradeNioProcessor.java
Thanks for that John, I'll fix that too.
Filip
On 3/1/2012 4:42 PM, Johno Crawford wrote:
On 2/03/2012 12:05 AM, fha...@apache.org wrote:
Author: fhanik
Date: Thu Mar 1 23:05:51 2012
New Revision: 1295978
URL: http://svn.apache.org/viewvc?rev=1295978view=rev
Log:
Fix WebSocket's non blocking call
http://tomcat.markmail.org/thread/drj7zgq2csfdnvoh#query:+page:1+mid:y4dheqpm2wx5xzba+state:results
Looks like the same usage in
org.apache.coyote.http11.Http11NioProtocol.Http11ConnectionHandler#longPoll ?
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=1295978r1=1295977r2=1295978view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java Thu Mar
1 23:05:51 2012
@@ -296,12 +296,7 @@ public class Http11NioProtocol extends A
protected void upgradePoll(SocketWrapperNioChannel socket,
ProcessorNioChannel processor) {
connections.put(socket.getSocket(), processor);
-
-SelectionKey key = socket.getSocket().getIOChannel().keyFor(
-socket.getSocket().getPoller().getSelector());
-key.interestOps(SelectionKey.OP_READ);
-((KeyAttachment) socket).interestOps(
-SelectionKey.OP_READ);
+socket.getSocket().getPoller().add(socket.getSocket());
}
}
}
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java?rev=1295978r1=1295977r2=1295978view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/upgrade/UpgradeNioProcessor.java
Thu Mar 1 23:05:51 2012
@@ -104,12 +104,10 @@ public class UpgradeNioProcessor extends
@Override
public int read(boolean block, byte[] bytes, int off, int len)
throws IOException {
-// TODO Implement non-blocking reads. Should be as simple as replacing
-// true with block in the two lines below
if (len maxRead) {
-return readSocket(true, bytes, off, maxRead);
+return readSocket(block, bytes, off, maxRead);
} else {
-return readSocket(true, bytes, off, len);
+return readSocket(block, bytes, off, len);
}
}
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.1.23
[+1] Released Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
On 2/28/2012 11:39 AM, Mark Thomas wrote: On 28/02/2012 16:58, Filip Hanik - Dev Lists wrote: On 2/28/2012 4:08 AM, Mark Thomas wrote: WebSocket is working with good performance and passing all Autobahn tests on BIO, NIO and APR. Currently, all three connectors using blocking IO throughout so there is a one to one mapping between threads and connections. Therefore, scalability is not what it could be for NIO and APR. The remaining TODOs are: Essential: a) move to non-blocking between messages b) address the threading issues around message sending c) add some documentation Nice to haves: - better examples (Petr Praus, Jonathan Drake Slávka are working on a chat application) - non-blocking throughout for NIO (requires much more state to be maintained and a change to the API - not sure it is worth it) I did this for Comet in the sandbox, and it is totally doable. But in my opinion, it's not worth the effort. It is much easier to just increase the buffer size at the network level, and voila, it wont block. I can't imagine WebSocket's message based system would be using very large messages, it's definitely not suited for that. Thanks for the feedback. You may also be able to help with some problems I am having getting non-blocking behaviour between messages with NIO. I'm not 100% clear what is happening yet, but I think it is something like: - HTTP GET (with upgrade request arrives - Upgrade is processed - no ws frame on the wire (yet) so process of handing back to the selector starts - first ws frame arrives - socket is handed back to the selector - selector *does not* trigger indicating there is data to process - some delay of a few seconds - client sends another ws frame - selector triggers - both frames are processed I can take a look at this, I've not seen this behavior before, it's been very accurate. I can force this behaviour 100% of the time with the debugger and it looks very similar to the issues we see intermittently with the Comet unit tests where two messages are processed at once. I am wondering if we have a race condition somewhere in the NIO code between: - determining there is no data to read - handling the socket back to the selector - new data arriving and if it is possible that for a particular sequence of events we can end up in the state where there is data to be read but the selector doesn't think so. I would normally assume my non-blocking code is doing something stupid (which it may well be anyway) but the similarity to the problem with the Comet unit test makes me suspect at least one root cause may be elsewhere. Any thoughts appreciated. (Note all of my non-blocking changes are currently sitting on my local hard drive. I can provide them if that would help.) Send it my way, I will take a look Mark - 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
Re: AccessLogValve enhancement
On 2/16/2012 2:12 PM, Konstantin Kolinko wrote: Do not send attachments to this mailing list ever! The world could implode!! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: AccessLogValve enhancement
On 2/17/2012 8:55 AM, Francis Galiegue wrote: While AccessLogValve is the subject... Any chance we can do away with the default, unparseable timestamp format? With Apache, it is allowed to specify the timestamp using strftime(3)-like format, I'd like to be able to do the same with Tomcat's AccessLogValve using SimpleDateFormat patterns... Submit a patch to bugzilla at issues.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml
The current behavior is a lot cleaner, (it just broke existing installations), as removing the XML file when the tomcat is not running actually undeploys the app. When the war was expanded into appBase before, it would have still been deployed. On 1/14/2012 10:57 AM, Mark Thomas wrote: On 13/01/2012 22:04, Filip Hanik - Dev Lists wrote: I'm looking for a better reason for this change. What was the reasoning behind this limitation, as it breaks years of compatibility. Workaround is to point docBase to a directory. The reasoning was that the documentation said one thing (that WARs outside the appBase would not be unpacked into the appBase) while the code did exactly the opposite but did not handle any of the special cases it should have. The documentation was the same (and had been for many years) for 5.5.x, 6.0.x and 7.0.x. I choose to align the code with the documentation on that occasion as it was simpler than making sure that the unpackWARs option worked correctly. The deployment process is full of edge cases (although fortunately a lot fewer than there were in the 4.1.x days) and it would have taken a fair amount of time to go through them and check that they were all handled correctly. As an aside, it would probably be a good idea if we documented all the use cases that deployment is meant to handle. It would make it easier to assess any future changes. I also took into account the following: - the current behaviour was undocumented (the documentation stated the opposite would happen) - the workaround (use a directory for the external docBase rather than a WAR) was simple. I'm not against a change to the documented behaviour and expanding external WARs into the docBase but any change along those lines would need to be carefully thought through. I don't think it is as simple as just unpacking the WAR, particularly for undeployment and context.xml updates (e.g. a context.xml update that changed the docBase would need special handling). Mark best Filip On 3/11/2011 11:40 AM, ma...@apache.org wrote: Author: markt Date: Fri Mar 11 18:40:13 2011 New Revision: 1080719 URL: http://svn.apache.org/viewvc?rev=1080719view=rev Log: Don't unpack WAR files if they are not located in the Host's appBase. - 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
Re: svn commit: r1080719 - in /tomcat/trunk: java/org/apache/catalina/startup/ContextConfig.java webapps/docs/changelog.xml
I'm looking for a better reason for this change. What was the reasoning behind
this limitation, as it breaks years of compatibility.
Workaround is to point docBase to a directory.
best
Filip
On 3/11/2011 11:40 AM, ma...@apache.org wrote:
Author: markt
Date: Fri Mar 11 18:40:13 2011
New Revision: 1080719
URL: http://svn.apache.org/viewvc?rev=1080719view=rev
Log:
Don't unpack WAR files if they are not located in the Host's appBase.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1080719r1=1080718r2=1080719view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Fri Mar 11
18:40:13 2011
@@ -672,12 +672,6 @@ public class ContextConfig
Host host = (Host) context.getParent();
String appBase = host.getAppBase();
-boolean unpackWARs = true;
-if (host instanceof StandardHost) {
-unpackWARs = ((StandardHost) host).isUnpackWARs()
- ((StandardContext) context).getUnpackWAR();
-}
-
File canonicalAppBase = new File(appBase);
if (canonicalAppBase.isAbsolute()) {
canonicalAppBase = canonicalAppBase.getCanonicalFile();
@@ -711,6 +705,13 @@ public class ContextConfig
context.getWebappVersion());
String pathName = cn.getBaseName();
+boolean unpackWARs = true;
+if (host instanceof StandardHost) {
+unpackWARs = ((StandardHost) host).isUnpackWARs()
+((StandardContext) context).getUnpackWAR()
+(docBase.startsWith(canonicalAppBase.getPath()));
+}
+
if (docBase.toLowerCase(Locale.ENGLISH).endsWith(.war)
!file.isDirectory() unpackWARs) {
URL war = new URL(jar: + (new File(docBase)).toURI().toURL() +
!/);
docBase = ExpandWar.expand(host, war, pathName);
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1080719r1=1080718r2=1080719view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Fri Mar 11 18:40:13 2011
@@ -50,6 +50,10 @@
inside server.xml and log a warning that the configuration has been
corrected. (markt)
/add
+fix
+Donapos;t unpack WAR files if they are not located in the Hostapos;s
+appBase. (markt)
+/fix
/changelog
/subsection
subsection name=Other
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3500 - Release Date: 03/11/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1183612 [2/2] - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
No grudge held :) I'm just bringing it up since very many files have been reformatted for the sake of formatting. And when tracing down a problem, I, and I suspect others too, often use SVN history to figure out what and how changed. So a formatting change that makes satisfies a personal formatting preference for one developer, down the line can make it a lot harder to trace changes for others. Filip On 1/13/2012 3:34 PM, Konstantin Kolinko wrote: 2012/1/14 Filip Hanik - Dev Listsdevli...@hanik.com: Commits like this, make it very difficult to trace down changes in the SVN history. I know both Mark and Konstantin are very keen on formatting, to the point where it overrides the priority of tracing down changes. I may be alone, but I'd prefer that we don't do this mega format entire file for no apparent purpose commits anymore. It is technical issue due to broken git-svn client that committed this file with wrong line-ends (violating Subversion protocol). It was discussed here on dev@tomcat (and users@subversion) in October 2011. It is nothing to grudge about. (Anyway to lookup the history further requires just several clicks in viewvc to ask annotations starting with different revision.) http://tomcat.markmail.org/thread/f4rdxrjvrenc6tg6 http://subversion.markmail.org/thread/uovs5c7mgcnyp4an Filip On 10/15/2011 3:47 AM, kkoli...@apache.org wrote: Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java?rev=1183612r1=1183611r2=1183612view=diff == --- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original) +++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sat Oct 15 09:47:39 2011 @@ -1,2514 +1,2514 @@ -/* - * Licensed to the Apache Software Foundation (ASF) under one or more - * contributor license agreements. See the NOTICE file distributed with - * this work for additional information regarding copyright ownership. - * The ASF licenses this file to You under the Apache License, Version 2.0 - * (the License); you may not use this file except in compliance with - * the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an AS IS BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - */ (no need to quote 2K of text) 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
Re: Proposal: use tomcat-version-number in server.xml Server element?
On 12/2/2011 10:11 AM, Konstantin Kolinko wrote: 2011/12/2 Christopher Schultzch...@christopherschultz.net: All, This may be a waste of time, but it's worth suggesting IMO. We have lots of users who try to upgrade between major versions of Tomcat by simply installing the new Tomcat somewhere, copying their configuration over (primarily server.xml), dumping their webapps into webapps/, starting the server, and then running to the users' list when it doesn't work. I was thinking that we could add a version attribute to server.xml's Server element that could allow Tomcat to bomb on startup if the version wasn't correct/compatible. -1 1. I strongly dislike relying on any numbers in such a feature. As people say, you should not rely on numbers, but on the features that are available. I have the exact opposite reaction. It seems like a strong -1 here is an engineering preference, specifically from one that already knows the product inside and out. However, I run into this very often, with Apache Tomcat and other products. Where ease of use is hindered by the product having almost zero validation of it's own configuration. It's very different making a -1 statement from behind a developer IDE, but try to sit next to a customer with 3000 tomcat instances running and tell that administrator why Tomcat is not telling him his config is wrong, cause the config changed between 5.0 and 5.5 2. It is social problem. You cannot teach people with this feature. People will always be smarter than your tool. Opposite again, ease of use comes from the tool. advanced usage comes from the people. I'd suspect that the first thing that most people faced with such problem will do is to edit the number. They wouldn't read the docs. so then there is room for a different solution, but yet attacking the same problem. 3. It does not prevent someone from Googling ancient articles and copying parts of config from there. It does not solve it, but it refers to the very problem to address, and actuates that it is a problem. So it seems like, the problem is obvious, the solution may not be enough. Chris, this would be your queue to rethink the solution one step further down the line. Not too long ago, I add in a property validator. Tomcat used to silently ignored invalid attributes, so misspellings such as Server sport=-1 shutdowns=SHUTDOWN This used to run with default values, with zero logging. This has been addressed for the most part. but there are still loop wholes, particularly with values and elements Filip (Someone cited an article from year 2001 just recently. Surprisingly it was still relevant - that part of Servet spec did not change much). 4. Version number can be changed by vendor or by site Admin. Speaking of relying on features: - Tomcat 6 server.xml should not start with Tomcat 7, because some LifeCycle listener implementations were removed. - Tomcat 5.5 and 6.0 differ in loader configuration in catalina.properties How about mentioning your issue somewhere in the FAQ? Though I think it is already mentioned on http://apache.org/migration.html 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
Re: Tomcat 6.0.34
On 9/7/2011 11:48 AM, Anand, Amit (Contractor) wrote: All, Kinda new to tomcat but have a couple quick questions which came up regarding CVE-2011-3109 (Bug 51698). Questions: Any timeline to when stable release of 6.0.34 is supposed to be released? Just follow this list. That's the best way to track it. Also what does in trunk specifically mean? Does that mean if I download say version 6.0.29 as of now, it will have the fix? trunk is a development source code branch, there is also one for 7.0.x and 6.0.x tomcat versions I do not know if this is the appropriate place to ask but would appreciate any help or guidance. Thank you Amit Anand Federal Trade Commission Sr. Unix Engineer (Contractor) 202-326-2394 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1157874 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/ConnectionPool.java
Thank you!
On 8/26/2011 7:31 AM, Konstantin Kolinko wrote:
2011/8/25 Konstantin Kolinkoknst.koli...@gmail.com:
URL: http://svn.apache.org/viewvc?rev=1157874view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51583
1) I think that because of this change the while (con != null) {
loop may run infinitely, because when pool.size() is 0 the con
variable is never set to null. You'll repeatedly release the same
connection.
2) Note that this change is in changelog for 7.0.21, but actually it
is not in TC7, because svn:externals property on tc7.0.x/trunk/modules
has not been updated.
I fixed the loop and updated externals in TC7.
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
Re: [VOTE] Grant Olivier Lamy commit karma to the Tomcat repo (for the Maven plugin)
+1 On 8/25/2011 8:44 AM, Mark Thomas wrote: Subject says it all. Here is my +1 to start this off. Mark - 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
Re: is this acceptor threadsafe?
On 8/15/2011 6:34 AM, Ҷï wrote:
/**
* Server socket acceptor thread.
*/
protected class Acceptor implements Runnable {
/**
* The background thread that listens for incoming TCP/IP connections
and
* hands them off to an appropriate processor.
*/
public void run() {
// Loop until we receive a shutdown command
while (running) {
// Loop if endpoint is paused
while (paused) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// Ignore
}
}
try {
// Accept the next incoming connection from the server
socket
SocketChannel socket = serverSock.accept();
if we have more than 1 acceptors,will the statement of serverSock.accept() be
theadsafe?
yes, and serverSock.accept will lock, so there is no need for more than one
acceptor thread, more than one thread will just queue up on the lock
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.19
[X] Stable - go ahead and release as 7.0.19 Stable On 7/14/2011 3:21 AM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.19 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.19/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_19/ The proposed 7.0.19 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.19 Alpha [ ] Beta - go ahead and release as 7.0.19 Beta [ ] Stable - go ahead and release as 7.0.19 Stable Cheers, Mark - 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
Re: svn commit: r1144061 - in /tomcat/trunk: build.xml modules/jdbc-pool/build.xml res/maven/mvn-pub.xml res/maven/tomcat-jdbc.pom webapps/docs/project.xml
On 7/10/2011 6:59 AM, Rainer Jung wrote:
Hi Filip,
On 07.07.2011 23:40, fha...@apache.org wrote:
Author: fhanik
Date: Thu Jul 7 21:40:05 2011
New Revision: 1144061
URL: http://svn.apache.org/viewvc?rev=1144061view=rev
Log:
Include jdbc-pool into tomcat release.
Added:
tomcat/trunk/res/maven/tomcat-jdbc.pom
Modified:
tomcat/trunk/build.xml
tomcat/trunk/modules/jdbc-pool/build.xml
tomcat/trunk/res/maven/mvn-pub.xml
tomcat/trunk/webapps/docs/project.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1144061r1=1144060r2=1144061view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Thu Jul 7 21:40:05 2011
...
@@ -680,6 +689,12 @@
mkdir dir=${tomcat.build}/webapps/docs/funcspecs /
!-- XSL processing --
+copy tofile=webapps/docs/jdbc-pool.xml file=${tomcat.jdbc.dir}/doc/jdbc-pool.xml
overwrite=true
+!-- jdbc-pool documentation --
+filterset
+filter token=TOMCAT_PROJECT_DEST value=project.xml/
+/filterset
+/copy
xslt basedir=webapps/docs
destdir=${tomcat.build}/webapps/docs
extension=.html
@@ -691,6 +706,8 @@
param name=build-date expression=${today}/
param name=year expression=${year}/
/xslt
+!-- remove jdbc-pool documentation --
+delete file=webapps/docs/jdbc-pool.xml/
xslt basedir=webapps/docs/appdev
destdir=${tomcat.build}/webapps/docs/appdev
extension=.html
Removing the file directly after generating the docs means the docs for
jdbc-pool are build every time, even if they are still up to date.
@@ -840,8 +857,16 @@
failonerror=false/
copy file=${jdt.jar} todir=${tomcat.build}/lib /
-/target
+!-- build the jdbc-pool jar and source jar--
+echo message=Building Tomcat JDBC pool libraries/
+ant antfile=${tomcat.jdbc.dir}/build.xml dir=${tomcat.jdbc.dir} inheritall=false
target=clean-and-build
+property name=tomcat.juli.jar value=${tomcat-juli.jar}/property
+property name=skip.download value=set/
+/ant
+copy file=${tomcat-jdbc.jar} todir=${tomcat.build}/lib overwrite=true/
+/target
+
Again, since you are calling clean-and-build, we will always rebuild
jdbc-pool.
Wouldn't it suffice to remove the copied docs file and to clean
jdbc-pool during the clean target?
Something along the lines of:
http://people.apache.org/~rjung/patches/tomcat-jdbc-pool-build-clean.patch
you can commit, no need to ask :) trunk is still CTR
Regards,
Rainer
-
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
Re: [jdbc-pool] AT sign in manifest (filtered version strings)
feel free to commit the fix On 7/10/2011 2:38 PM, Rainer Jung wrote: I tested the jdbc-pool building, which is part of the release right now. The manifest contains patterns of the form @@VERSION@@, e.g. org.apache.tomcat.jdbc.pool;version=@@VERSION@@; org.apache.tomcat.jdbc.pool.interceptor;version=@@VERSION@@; org.apache.tomcat.jdbc.pool.jmx;version=@@VERSION@@; Bundle-Version: @@VERSION@@ which result in @1.1.0.1@ after filtering. Full Manifest: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 11.0-b16 (Sun Microsystems Inc.) Export-Package: org.apache.tomcat.jdbc.pool;version=@1.1.0.1@; uses :=javax.management,javax.naming,javax.naming.spi,javax.sql, org.apac he.tomcat.jdbc.pool.jmx, org.apache.tomcat.jdbc.pool.interceptor;ver sion=@1.1.0.1@; uses:=javax.management.openmbean,org.apache.tomcat .jdbc.pool, org.apache.tomcat.jdbc.pool.jmx;version=@1.1.0.1@; use s:=javax.management,org.apache.tomcat.jdbc.pool Bundle-Vendor: Apache Software Foundation Bundle-Version: @1.1.0.1@ Bundle-Name: Apache Tomcat JDBC Connection Pool Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.apache.tomcat.jdbc Import-Package: javax.management;version=0, javax.management.openmb ean;version=0, javax.naming;version=0, javax.sql;version=0, org .apache.juli.logging;version=[6.0.18, 7.0.0) I guess it should only be single at signs, like @VERSION@? Regards, Rainer - 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
Re: Distributable contexts and non-serializable session attributes
go ahead add it in, if you add in a flag to toggle the behavior, and the flag is defaulted to today's behavior. you're safe, and you give
users an option
Filip
On 7/10/2011 1:38 PM, Rainer Jung wrote:
I implemented an addition to DeltaManager which allows to filter which
session attributes actually get replicated (not yet committed).
This is useful, because many applications
- use non-serializable session attributes, so
it is not possible to simply replicate everything
- do not actually need everything replicated, because they
can bootstrap all they need from a login context if a filter
detects, that a failover has happened.
In these cases it can also help to reduce replication traffic a lot.
Unfortunately I stu,bled into some code in StandardSession:
public void setAttribute(String name, Object value, boolean notify) {
...
if ((manager != null) manager.getDistributable()
!(value instanceof Serializable))
throw new IllegalArgumentException
(sm.getString(standardSession.setAttribute.iae, name));
...
}
This means if you enable distributable, then you can no longer set any
non-serializable session attribute. The code is not recent, it goes back
to at least TC 3.3.
I understand, that it is helpful to devs being informed about
serialization/replication problems. But I think it is too strict to
enforce this in StandardSession whch is the base class of all our
cluster sessions and we always delegate to
StandardSession.setAttribute() after some cluster specific handling.
The SPEC says:
The container must accept objects that implement the Serializable interface.
- The container may choose to support storage of other designated
objects in the
HttpSession, such as references to Enterprise JavaBeans components and
transactions.
- Migration of sessions will be handled by container-specific facilities.
The distributed servlet container must throw an IllegalArgumentException for
objects where the container cannot support the mechanism necessary for
migration
of the session storing them.
(and some more in 7.7.2).
I think checking for serializability in StandardSession isn't good,
because AFAIK StandardSession isn't used by any mechanism Tomcat
supports to implement distributable.
And in DeltaSession I would like to have the check optional, i.e. only
check if the configuration wants the attribute to be replicated.
By default all attributes will be replicated as is today, but by
configuration one will be able to choose attributes to replicate using a
regexp against the attribute name.
Any remarks?
Rainer
-
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
Re: svn commit: r1144061 - in /tomcat/trunk: build.xml modules/jdbc-pool/build.xml res/maven/mvn-pub.xml res/maven/tomcat-jdbc.pom webapps/docs/project.xml
On 7/7/2011 5:55 PM, Konstantin Kolinko wrote: 2011/7/8fha...@apache.org: Author: fhanik Date: Thu Jul 7 21:40:05 2011 New Revision: 1144061 URL: http://svn.apache.org/viewvc?rev=1144061view=rev Log: Include jdbc-pool into tomcat release. Added: tomcat/trunk/res/maven/tomcat-jdbc.pom 1) svn:eol-style for pom Modified: tomcat/trunk/build.xml tomcat/trunk/modules/jdbc-pool/build.xml tomcat/trunk/res/maven/mvn-pub.xml tomcat/trunk/webapps/docs/project.xml --- tomcat/trunk/webapps/docs/project.xml (original) +++ tomcat/trunk/webapps/docs/project.xml Thu Jul 7 21:40:05 2011 @@ -70,6 +70,8 @@ item name=29) Windows Servicehref=windows-service-howto.html/ item name=30) Windows Authentication href=windows-auth-howto.html/ +item name=31) Tomcat's JDBC Pool + href=jdbc-pool.html/ /menu menu name=Reference 2) Where jdbc-pool.html comes from? You forgot to commit it? Or is it supposed to be copied from elsewhere during build. it comes from modules/jdbc-pool/doc/jdbc-pool.xml and that gets built during the build process 3) The documentation pages are listed not only in the menu that you updated, but also on the index.html page. Please update that one as well. will do, thanks for the feedback Filip 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
Re: svn commit: r1137607 - /tomcat/trunk/bin/catalina.sh
On 6/20/2011 8:06 AM, Mladen Turk wrote: On 06/20/2011 03:53 PM, Rainer Jung wrote: On 20.06.2011 15:41, Mladen Turk wrote: In general all commands except those that start a Tomcat (and thus deploy webapps etc.) should not use that type of params. They should go into CATALINA_OPTS. Everything that you can use multiple times in parallel, even for the helper programs can go in JAVA_OPTS. Hmm, make sense. Seems there is general missunderstanding of those two. People usually put in JAVA_OPTS what actually belongs to CATALINA_OPTS. don't matter what people put where, as long as we don't break backwards compatibility. as long as configtest doesn't rely on system variables that can be put CATALINA_OPTS, such as -Dhttp.port=8080 :) Dunno what to think actually at the moment. Regards - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Plan for 7.0.15
I'd like to suggest that we include tomcat-jdbc.jar in the 7.0.15 release. DBCP will still be the default, but allows users to configure an alternative fairly easily without downloading separate libraries. It's easy to include in the build process, the jar is very small, so it doesn't bloat the distribution thoughts? Filip On 6/2/2011 7:36 AM, Mark Thomas wrote: All, Another month has rolled by so I am starting to look at a 7.0.15 release. The main things in this release will be the new NIO AJP connector along with the usual assortment of bug fixes. I want to finish the fix for BZ 51278 for 7.0.15 so with that work and running the TCKs before the tag, expect a tag sometime over the weekend with the vote early next week. The usual caveats about bug fixes taking longer than expected, $work priorities and $life getting in the way apply so the schedule may slip. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1511/3674 - Release Date: 06/01/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Plan for 7.0.15
On 6/3/2011 10:13 AM, Mark Thomas wrote: On 03/06/2011 17:07, Filip Hanik - Dev Lists wrote: I'd like to suggest that we include tomcat-jdbc.jar in the 7.0.15 release. DBCP will still be the default, but allows users to configure an alternative fairly easily without downloading separate libraries. It's easy to include in the build process, the jar is very small, so it doesn't bloat the distribution thoughts? +1 to the idea of including jdbc-pool but there will be a fair number of changes required to build.xml (and maven scripts etc) and I'd prefer to get 7.0.15 out of the way and include this in 7.0.16 to give us a little longer to bed in the changes. sounds like a good plan Filip Mark Filip On 6/2/2011 7:36 AM, Mark Thomas wrote: All, Another month has rolled by so I am starting to look at a 7.0.15 release. The main things in this release will be the new NIO AJP connector along with the usual assortment of bug fixes. I want to finish the fix for BZ 51278 for 7.0.15 so with that work and running the TCKs before the tag, expect a tag sometime over the weekend with the vote early next week. The usual caveats about bug fixes taking longer than expected, $work priorities and $life getting in the way apply so the schedule may slip. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1511/3674 - Release Date: 06/01/11 - 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1382 / Virus Database: 1511/3678 - Release Date: 06/03/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: LocalXA patch proposition
hi Philippe, open a bugzilla item https://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%20Modules Add your patch there, and I will happily take a look thanks for contributing Filip On 5/24/2011 8:31 AM, Philippe Mouawad wrote: Hello, I have implemented for Ofbiz a port of DBCP Local XA feature that uses Tomcat JDBC Pool. I would like to contribute this feature to Tomcat JDBC Pool because it seems to me the right place, is it something that interests the project. It would introduce the following compilation dependency: - JTA 1.1 Thank you Regards Philippe - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1375 / Virus Database: 1509/3655 - Release Date: 05/23/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Move to svnpubsub for /dist/tomcat
+1 sounds good Filip On 5/18/2011 7:38 AM, Mark Thomas wrote: All, We have the option to move to svnpubsub for managing our releases. Rather than copying artefacts to people.a.o and then waiting for rsync (every around 2 hours) we would commit the artefacts to svn and a commit hook would update the /dist/tomcat area on the www servers immediately. If folks would like to go this route, I am happy to do the work on our end to migrate /dist/tomcat to svnpubsub. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1321 / Virus Database: 1500/3643 - Release Date: 05/17/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
-1 for this change. 0 means infinite (no timeout)
http://download.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29
Filip
On 5/16/2011 1:31 AM, ma...@apache.org wrote:
Author: markt
Date: Mon May 16 07:31:23 2011
New Revision: 1103633
URL: http://svn.apache.org/viewvc?rev=1103633view=rev
Log:
Prevent infinite loop when readTimeout = 0
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633r1=1103632r2=1103633view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java Mon
May 16 07:31:23 2011
@@ -178,7 +178,7 @@ public class NioBlockingSelector {
keycount = 1;
att.resetReadLatch();
}
-if (readTimeout 0 (keycount == 0))
+if (readTimeout= 0 (keycount == 0))
timedout = (System.currentTimeMillis() - time)=
readTimeout;
} //while
if (timedout)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3640 - Release Date: 05/15/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1103633 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
I take back my -1
looking at the javadoc, it defines -1 as infinite.
So your commit is correct, but requires an addition
-att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
+if (readTimeout0) {
+ att.awaitReadLatch(Long.MAX_VALUE,TimeUnit.MILLISECONDS);
+} else {
+ att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
+}
Filip
On 5/16/2011 3:38 PM, Mark Thomas wrote:
On 16/05/2011 16:24, Filip Hanik - Dev Lists wrote:
-1 for this change. 0 means infinite (no timeout)
http://download.oracle.com/javase/6/docs/api/java/net/Socket.html#setSoTimeout%28int%29
The problem is that readTimeout is also used in line 169:
att.awaitReadLatch(readTimeout,TimeUnit.MILLISECONDS);
and in that case the timeout is not infinite, it is immediate (Rainer
checked the JRE source) which triggers a tight CPU burning loop.
Any suggestions for a better solution? How about changing a value of 0
to -1 at the start of the method?
Mark
Filip
On 5/16/2011 1:31 AM, ma...@apache.org wrote:
Author: markt
Date: Mon May 16 07:31:23 2011
New Revision: 1103633
URL: http://svn.apache.org/viewvc?rev=1103633view=rev
Log:
Prevent infinite loop when readTimeout = 0
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java?rev=1103633r1=1103632r2=1103633view=diff
==
---
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
(original)
+++
tomcat/trunk/java/org/apache/tomcat/util/net/NioBlockingSelector.java
Mon May 16 07:31:23 2011
@@ -178,7 +178,7 @@ public class NioBlockingSelector {
keycount = 1;
att.resetReadLatch();
}
-if (readTimeout 0 (keycount == 0))
+if (readTimeout= 0 (keycount == 0))
timedout = (System.currentTimeMillis() - time)=
readTimeout;
} //while
if (timedout)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3640 - Release Date: 05/15/11
-
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
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3641 - Release Date: 05/16/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 51189] New: Acceptor threads are blocked
on most OS:es there is a single lock for accepting new connections, so a better default is 1 for acceptor thread count. there is no performance gain in multiple threads, none that I was ever able to detect. Filip On 5/12/2011 2:32 AM, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=51189 Bug #: 51189 Summary: Acceptor threads are blocked Product: Tomcat 7 Version: 7.0.11 Platform: All OS/Version: Linux Status: NEW Severity: blocker Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: helinxi...@gmail.com Classification: Unclassified Hi, I deployed an web application on tomcat 7.0.11, it got acceptor threads blocked when it ran two weeks, and the mysql connections weren't released, I guess they are the same problem. I don't whether it is a bug of JIoEndpoint. Thanks a lot. EastMountain Thread dump below: http-bio-8080-Acceptor-3 daemon prio=10 tid=0x2aaab4148000 nid=0x141d waiting for monitor entry [0x419ac000] java.lang.Thread.State: BLOCKED (on object monitor) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:388) - waiting to lock0x2abd72beb518 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:211) at java.lang.Thread.run(Thread.java:619) http-bio-8080-Acceptor-2 daemon prio=10 tid=0x2aaab4898800 nid=0x141c runnable [0x411af000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390) - locked0x2abd72beb518 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:211) at java.lang.Thread.run(Thread.java:619) http-bio-8080-Acceptor-1 daemon prio=10 tid=0x2aaab45a4800 nid=0x141b waiting for monitor entry [0x4193] java.lang.Thread.State: BLOCKED (on object monitor) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:388) - waiting to lock0x2abd72beb518 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:211) at java.lang.Thread.run(Thread.java:619) http-bio-8080-Acceptor-0 daemon prio=10 tid=0x2aaab48a7800 nid=0x141a waiting for monitor entry [0x4116e000] java.lang.Thread.State: BLOCKED (on object monitor) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:388) - waiting to lock0x2abd72beb518 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:59) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:211) at java.lang.Thread.run(Thread.java:619) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.14
On 5/9/2011 5:31 PM, Mark Thomas wrote: [X] Stable - go ahead and release as 7.0.14 Stable - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: BIO performance issues
fan-tastic! Thank you! On 5/5/2011 9:56 AM, Mark Thomas wrote: On 04/05/2011 16:17, Filip Hanik - Dev Lists wrote: Here is what I propose, and you'll see that it's pretty much inline with what you suggest. a) add in a flag that lets keep alive be turned off during concurrency disableKeepAlivePercentage=75 this would be the default value. and would achieve exactly what you want in your a) a) restore disabling keep-alive when threads used= 75% of maxThreads b) remove maxConnections and associated code from the APR connector b) or you can simply make pollerSize==maxConnections meaning that setPollerSize(5000) is the same as setMaxConnections(5000) that way you retain the same properties across connectors c) remove the configuration options for maxConnections from the BIO connector I think you still misunderstand why maxConnections is there, at some point you need to push back on the TCP stack. and still be able to control when to accept new connections. Keep this setting in there, exactly as it is. d) use maxThreads instead of maxConnections for the BIO connector if you feel so strongly on this, simple set maxConnections=200 as the default value for BIO connector. All now implemented in trunk. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1321 / Virus Database: 1500/3617 - Release Date: 05/05/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 7.0.13
+1 Filip On 5/5/2011 10:00 AM, Mark Thomas wrote: All open bugs (apart from 49683 which should probably be re-classed as an enhancement) have been fixed in trunk, the BIO changes have been applied and recent enhancement requests (with patches) have been applied. I am about to start the testing cycle before tagging 7.0.13. If anyone can see anything at this point that needs fixing before the tag please shout asap. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1321 / Virus Database: 1500/3617 - Release Date: 05/05/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: BIO performance issues
On 5/3/2011 2:02 PM, Mark Thomas wrote: All, Summary --- While trying to align the documentation for maxConnections with the actual implementation a couple of performance issue have been identified with the BIO connector. All bar one of these have been fixed. A fix needs to be agreed for the remaining issue, ideally before the next 7.0.x release. Background -- New connections to the BIO connector are placed in a queue. When a thread is available, it takes the next connection of the queue and processes it. When the connection has been processed if the connection is kept-alive it is placed back on the queue. If there is no keep-alive the connection is closed. Scenario This ended up being very long, so I moved it to the end. The exact pattern of delays will vary depending on timeouts, request frequency etc. but the scenario shows an example of how delays can occur. The short version is that requests with data to process (particularly new connections) tend to get delayed in the queue waiting for a thread to process them when the threads are all tied up processing keep-alive connections. Root cause -- The underlying cause of all of the performance issues observed is when the threads are tied up doing HTTP keep-alive when there is no data process but there are other connections in the queue that do have data that could be processed. Solution A -- NIO is designed to handle this using a poller. That isn't available to BIO so I attempted to simulate it. That generated excessive CPU load so I do not think simulated polling is the tight solution. Solution B -- Return to the Tomcat 6 implementation where maxConnections == maxThreads. Additional clean-up --- maxConnections is unnecessary in APR since pollerSize performs the same function. I'd -1 to Solution A and Solution B, mostly because the very descriptive example below shows a scenario that can be configured around. I would say that - maxThreads=200 - maxConnections=1 - connectionTimeout=2 - keepAliveTimeout=2 is a gross misconfiguration for the BIO connector if you really expect this type of concurrency. the 20 second timeout stems from our 10Mbps network days. I can equally prove that the old implementation has no fairness what so ever. As some connections will stay on the backlog until they expire while some get accepted. In a similar fashion, we can also craft a test run that will yield a substantial improvement over the old implementation in throughput. So there is a test case to prove every scenario. Here is what I propose, and you'll see that it's pretty much inline with what you suggest. a) add in a flag that lets keep alive be turned off during concurrency disableKeepAlivePercentage=75 this would be the default value. and would achieve exactly what you want in your a) a) restore disabling keep-alive when threads used= 75% of maxThreads b) remove maxConnections and associated code from the APR connector b) or you can simply make pollerSize==maxConnections meaning that setPollerSize(5000) is the same as setMaxConnections(5000) that way you retain the same properties across connectors c) remove the configuration options for maxConnections from the BIO connector I think you still misunderstand why maxConnections is there, at some point you need to push back on the TCP stack. and still be able to control when to accept new connections. Keep this setting in there, exactly as it is. d) use maxThreads instead of maxConnections for the BIO connector if you feel so strongly on this, simple set maxConnections=200 as the default value for BIO connector. so if the new implementation has these default values for BIO maxThreads=200 maxConnections=200 disableKeepAlivePercentage=75 this will grant you the exact behavior of the old implementation, while giving others the benefit of configuring for better performance using BIO best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: BIO performance issues
On 5/4/2011 9:54 AM, Mark Thomas wrote: On 04/05/2011 16:17, Filip Hanik - Dev Lists wrote: On 5/3/2011 2:02 PM, Mark Thomas wrote: In a similar fashion, we can also craft a test run that will yield a substantial improvement over the old implementation in throughput. So there is a test case to prove every scenario. Could you outline what a test case looks like. It would help with the general understanding of what problem maxConnections is trying to solve. ok, we have an acceptor thread(AT) that does ServerSocket.accept() in an endless loop. In the previous implementation, the AT would accept the socket, then wait for a thread to become available to handle the connection. New incoming connections would then be handled by the backlog in the operating system. The old implementation was extremely unfair in how it handled the requests, some requests could get handled right away, while others could wait for long period of times (this is with the old impl). As you may be familiar, a client's connection may die in the backlog at which point the client has to attempt a new connection. if you really want a simple test case, then do maxThreads=200 clients=200 keepalive=on In the old impl, keep alive would be turned off and performance would suffer, even though the system has plenty of resources to handle it. while this test case is very narrow and simple, it's the other extreme of the use case you presented. The new implementation, queue based, was as a result to be able to disconnect a thread from a socket due to the new async requirements. Previously, a thread was married to a socket for as long as the socket was alive. Anyway, with the new implementation, just like with NIO, there is no longer a stopper on the acceptor thread (AT) it will happily keep accepting connections until you run out of buffer space or port numbers. This presents a DoS risk, this risk has existed in NIO for a while. So maxConnections has been put in place to stop accepting connections, and push back new connections into the backlog. so maxConnections exists to stop the acceptor thread from taking in more than it can handle. Here is what I propose, and you'll see that it's pretty much inline with what you suggest. Yep. That works for me. I do have some additional questions around maxConnections - mainly so I can get the docs right. c) remove the configuration options for maxConnections from the BIO connector I think you still misunderstand why maxConnections is there, at some point you need to push back on the TCP stack. Some more detail on exactly the purpose of maxConnections would be useful. The purposes I can see are: - limiting connections since the addition of the queue means they are not limited by maxThreads correct, a system with maxThreads=200 should be able to handle connections=500 with keep alive on and perform very well. - fair (order received) processing of connections? correct. almost no clients use pipelined requests, so chances that there is data on a new finished request is very slim. It is more probable that there is data on a request that was finished earlier in the cycle. I hope that explains it. And by default, with the config options/defaults I suggested, you'll get the exact behavior of the old connector, but can still benefit from the new connector logic - ? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1321 / Virus Database: 1500/3615 - Release Date: 05/04/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: bindOnInit and maxConnections for AJP connectors
On 5/3/2011 10:50 AM, Mark Thomas wrote: On 21/04/2011 20:21, Mark Thomas wrote: On 06/04/2011 22:51, Tim Whittington wrote: On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomasma...@apache.org wrote: On 05/04/2011 10:50, Tim Whittington wrote: Is what's actually going on more like: APR: use maxConnections == pollerSize (smallest will limit, but if pollerSize maxConnections then the socket backlog effectively won't be used as the poller will keep killing connections as they come in) NIO: use maxConnections to limit 'poller size' HTTP: use maxConnections. For keep alive situations, reduce maxConnections to something closer to maxThreads (the default config is 10,000 keepalive connections serviced by 200 threads with a 60 second keepalive timeout, which could lead to some large backlogs of connected sockets that take 50 minutes to get serviced) This is still an issue. I'm still thinking about how to address it. My current thinking is: - BIO: Introduce simulated polling using a short timeout (see below) - NIO: Leave as is - APR: Make maxConnections and pollerSize synonyms - All: Make the default for maxConnections 8192 so it is consistent with the current APR default. The other option is dropping maxConnections entirely from the NIO and APR connectors. That would align the code with the docs. The only downside is that the NIO connector would no longer have an option to limit the connections. I'm not sure that is much of an issue since I don't recall any demands for such a limit from the user community. Apologies for what I expect will turn out to be a long e-mail. I have reached the point where I believe the best way forward is: - remove maxConnections from NIO and APR - remove the ability to set maxConnections for BIO and hard code it to maxThreads -1 maxConnections serves a purpose. It protects against a DoS. There must be a way to configure a system to eventually push back, and not just keep accepting connections. Therefor the maxConnections should stay. - restore the disable keep-alive when75% BIO threads are in use why, make it configurable. I would believe that on many systems, the queued approach that BIO has, still can provide significant improvement in performance. If I don't want queued behavior, I'll just turn off keep alive. My reasoning is as follows: - Servlet 3.0 async requests mean that current connections in use may be greater then current threads in use. - This provides potential efficiency savings as less threads are required. - That connections may be greater than threads led to the new maxConnections attribute. the maxConnections attribute is simply to restrict the acceptor thread from just going on and on. It had nothing to do with servlet 3 or async. It's a protective measure for the server. - maxConnections maxThreads introduces an issue where a connection with data may be in the connection queue waiting for a thread whilst all the threads are busy doing nothing waiting for data on connections that will eventually time out. and this is still better than simply not accepting any connections at all. Right now, in order to work around the blocking aspect, one has to configure acceptCount so that connections are not simply turned away. - This issue can be fixed with simulated polling. I wouldn't do simulated polling. I'm not sure what benefit there would be. - Testing showed that simulated polling was very CPU intensive (I saw a typical increase from ~40% to ~50% CPU usage with 4 Tomcat threads, 2 'fast' client threads making requests as fast as they could, 10 'slow' client threads making a request every 5s and a pollTime of 100ms on an 8-core machine. - The additional resources required by simulated polling are likely to be greater than those saved by reduced thread usage. - It is therefore better to just increase maxThreads, expecting that not all of them will be used and hard-code maxConnections to the same number as maxThreads. Better still, just use NIO. you still need maxConnection Further, the complexity of BIO code required to support: - Optional configuration of maxConnections maxThreads - simulated polling when maxConnections maxThreads - auto-disabling of keep-alive for users that don't want the overhead of simulated polling when maxConnections == maxThreads was getting to the point where I had stability concerns. Given the above, and assuming there are no objections, I intend to implement the way forward I set out above tomorrow. I'm confused about what you are trying to do or achieve. What problems are you trying to solve? This email thread started with two missing attributes. I'd start a new thread describing the problem you are having. best Filip Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version:
Re: svn commit: r1094069 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/manager/ java/org/apache/catalina/session/ webapps/docs/
On 4/21/2011 8:00 AM, Mark Thomas wrote: On 19/04/2011 16:27, Filip Hanik - Dev Lists wrote: On 4/18/2011 4:39 AM, Mark Thomas wrote: On 18/04/2011 10:13, Remy Maucherat wrote: On Sat, 2011-04-16 at 22:25 +, ma...@apache.org wrote: Author: markt Date: Sat Apr 16 22:25:28 2011 New Revision: 1094069 URL: http://svn.apache.org/viewvc?rev=1094069view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 Don't trigger session creation listeners when changing the session ID during authentication. But the listeners have to be aware that the id changed. Why? I have checked the Servlet spec and I don't see any event defined for session ID changed. I also don't see anything (although I may have missed it) that says the ID must be constant. Every logical application that uses the ID as a key, would like to know that the ID has changed since the key is no longer valid. Those apps would rely on some sort event that the key is no longer there. regardless of what the servlet spec says, it's seems logical. That raises the question of what event to fire. There is nothing that keeps us from defining events. While adhering to the spec, it doesn't mean to limit us to it. This is a pretty important event, the change of the ID (key) to existing data. I'd be considering a ID_CHANGE_EVENT here The session lifecycle events are for whenspec-quoteAn HttpSession has been created, invalidated, or timed out./spec-quote. None of those apply in this case. Hence my leaning towards the view that no event should be fired. If this causes an issue for an application, it can always disable the session fixation protection and provide their own alternative protection. I assume that you are suggesting that the session invalidated + session created events are used, but as I said before, if those events are fired then the object binding and attribute change events should also be fired. I can see firing all these additional events being more likely to cause problems for applications that just a change of the session ID. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3593 - Release Date: 04/23/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: SpnegoAuthenticator feedback
On 4/21/2011 3:09 AM, Mark Thomas wrote:
On 20/04/2011 21:00, Filip Hanik - Dev Lists wrote:
Here are some thoughts on the implementation
Thanks for the feedback.
1. |com.sun.security.jgss.initiate is not needed
This definition is not needed in jaas.conf. Tomcat is not a client in
this case, it's a server accepting tickets.
the .initiate is only for clients that request a Kerberos ticket from
the KDC.
The example works fine removing this entry all together.
I think this will be required when we add support for using the server's
delegated credentials to connect to the directory to retrieve user
roles. I'll check this when I implement it and will remove it if I can.
yes, if you want tomcat to act as a client.
Acting like a client will mean a few different things, like
- configuring the module name for the client
- I'm pretty sure the configuration will be different here, you should not need
a keytab or principal, you're a client in this case.
2. com.sun.security.jgss.krb5.accept is not configurable
While the authenticator has the attribute loginConfigName, there seems
to be a place in the code where it omits this entry.
renaming this entry in jaas.conf and setting the loginConfigName will
fail to validate a ticket
Thanks. I'll add a BZ entry for this. I should be able to get to in in
time for 7.0.13 (unless someone beats me to it).
much appreciated
Filip
Mark
The problem code is here:
gssContext =
manager.createContext(manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY));
should look like
final GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionActionGSSCredential action =
new PrivilegedExceptionActionGSSCredential() {
public GSSCredential run() throws GSSException {
return manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY);
}
};
gssContext =
manager.createContext(Subject.doAs(lc.getSubject(), action));||
best
Filip
|
-
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
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1321 / Virus Database: 1500/3586 - Release Date: 04/20/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1095794 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11Processor.java webapps/docs/changelog.xml
On 4/21/2011 1:02 PM, ma...@apache.org wrote:
+int firstReadTimeout;
+if (queueTime= standardTimeout) {
+// Queued for longer than timeout but there might be
+// data so use shortest possible timeout
+firstReadTimeout = 1;
+} else {
+// Cast is safe since queueTime must be less than
+// standardTimeout which is an int
+firstReadTimeout = standardTimeout - (int) queueTime;
+}
+socket.getSocket().setSoTimeout(firstReadTimeout);
+if (!inputBuffer.fill()) {
+throw new EOFException(sm.getString(iib.eof.error));
}
}
+if (standardTimeout 0) {
+socket.getSocket().setSoTimeout(standardTimeout);
+}
+
inputBuffer.parseRequestLine(false);
not fully understanding the logic here. But if you ever run into a case where standardTimeout=0 and firstReadTimeout=1, then you'd have 1
millisecond timeout for the parse request line. And the request line, typically comes in one packet, but it is legal to send it up in two.
And you'd have an invalid SocketTimeoutException here, since 1 is no longer the correct timeout.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1095367 - in /tomcat/trunk: java/org/apache/catalina/startup/ java/org/apache/jasper/compiler/ java/org/apache/tomcat/util/scan/ webapps/docs/
On 4/20/2011 10:07 AM, Mark Thomas wrote: The new code is better than the old. You are welcome to try and improve it further although I don't think there is much more scope for improvement given the performance figures I am seeing. My suggestion here would be to: 1. When a JAR file has been scanned, then save the result of the scan to the work directory containing - name of jar - timestamp of the JAR - MD5 of jar - size of jar in bytes - result of scan This would serve a jar scanner cache. If I restart tomcat several times without any changes to the libraries, there is no need to incur the 12 second startup time. While 30s - 12s is a dramatic improvement, you can bring down the penalty of a scan even more. Ideally there is also an option to disable the cache, for the skeptic ones :) Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
SpnegoAuthenticator feedback
Here are some thoughts on the implementation
1. |com.sun.security.jgss.initiate is not needed
This definition is not needed in jaas.conf. Tomcat is not a client in this
case, it's a server accepting tickets.
the .initiate is only for clients that request a Kerberos ticket from the KDC.
The example works fine removing this entry all together.
2. com.sun.security.jgss.krb5.accept is not configurable
While the authenticator has the attribute loginConfigName, there seems to be a
place in the code where it omits this entry.
renaming this entry in jaas.conf and setting the loginConfigName will fail to
validate a ticket
The problem code is here:
gssContext = manager.createContext(manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY));
should look like
final GSSManager manager = GSSManager.getInstance();
final PrivilegedExceptionActionGSSCredential action =
new PrivilegedExceptionActionGSSCredential() {
public GSSCredential run() throws GSSException {
return manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME,
new Oid(1.3.6.1.5.5.2),
GSSCredential.ACCEPT_ONLY);
}
};
gssContext = manager.createContext(Subject.doAs(lc.getSubject(),
action));||
best
Filip
|
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1094069 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/manager/ java/org/apache/catalina/session/ webapps/docs/
On 4/18/2011 4:39 AM, Mark Thomas wrote: On 18/04/2011 10:13, Remy Maucherat wrote: On Sat, 2011-04-16 at 22:25 +, ma...@apache.org wrote: Author: markt Date: Sat Apr 16 22:25:28 2011 New Revision: 1094069 URL: http://svn.apache.org/viewvc?rev=1094069view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 Don't trigger session creation listeners when changing the session ID during authentication. But the listeners have to be aware that the id changed. Why? I have checked the Servlet spec and I don't see any event defined for session ID changed. I also don't see anything (although I may have missed it) that says the ID must be constant. Every logical application that uses the ID as a key, would like to know that the ID has changed since the key is no longer valid. Those apps would rely on some sort event that the key is no longer there. regardless of what the servlet spec says, it's seems logical. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1086706 - in /tomcat/trunk/java/org/apache/catalina: Realm.java authenticator/SpnegoAuthenticator.java realm/CombinedRealm.java realm/LocalStrings.properties realm/LockOutRealm.java r
On 4/7/2011 7:14 PM, Konstantin Kolinko wrote:
2011/4/8 Filip Hanik - Dev Listsdevli...@hanik.com:
On 3/29/2011 2:05 PM, ma...@apache.org wrote:
+ * @param certs The gssContext processed by the {@link
Authenticator}.
+ */
+public Principal authenticate(GSSContext gssContext);
+
+
we can continue to add methods and changing the interface, or we can do what
most other systems do
public Principal authenticate(Object auth);
Good idea.
Just Object, or some marker interface?
I'd do just object,
Filip
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1209 / Virus Database: 1500/3560 - Release Date: 04/08/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: bindOnInit and maxConnections for AJP connectors
On 4/8/2011 2:50 AM, Tim Whittington wrote: The input buffer is 8k by default (max header size), so this could be significant with a large maxConnections. significant in 1990 maybe :) even with 20k connections, this be a drop in the ocean compared to memory usage for today's applications - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: bindOnInit and maxConnections for AJP connectors
On 4/6/2011 3:51 PM, Tim Whittington wrote: b) Check the input buffer at the end of the loop in Http11Processor#process() and process the next request if there is any data in the input buffer. - No Increase in memory requirements. - Fixes issue 3 - Pipelined requests will get processed earlier (before they would have been placed at the back of the request processing queue) I think option b) is the way to go to fix issue +1 It's an unfair scheduling, but given issue 2 that's a fairly moot point with the BIO connector. sounds reasonable. this is how we used to do it (we may still) in APR. it avoids one context switch not needed, and in NIO we could do this too, since we can even check the network buffer without blocking best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1086706 - in /tomcat/trunk/java/org/apache/catalina: Realm.java authenticator/SpnegoAuthenticator.java realm/CombinedRealm.java realm/LocalStrings.properties realm/LockOutRealm.java r
On 3/29/2011 2:05 PM, ma...@apache.org wrote:
+ * @param certs The gssContext processed by the {@link Authenticator}.
+ */
+public Principal authenticate(GSSContext gssContext);
+
+
we can continue to add methods and changing the interface, or we can do what
most other systems do
public Principal authenticate(Object auth);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JSP Compiler swallows exceptions when removing files
yes
On 4/7/2011 1:32 PM, Christopher Schultz wrote:
All,
While reading the code for jasper.compiler.Compiler on an unrelated
errand, I noticed that the removeGeneratedFiles and
removeGeneratedClassFiles methods contain this code:
} catch (Exception e) {
// Remove as much as possible, ignore possible exceptions
}
This code appears in both TC 6.0.x trunk and TC 7.0.x trunk.
This situation seems worthy of a log statement, no?
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[RESULT] Re: [VOTE] Release jdbc-pool 1.1.0.1
Canceled. Not enough votes. Filip On 3/3/2011 12:24 PM, Filip Hanik - Dev Lists wrote: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.1 Alpha [ ] Beta - go ahead and release as 1.1.0.1 Beta [ ] Stable - go ahead and release as 1.1.0.1 Stable best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3479 - Release Date: 03/03/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1079575 - in /tomcat/trunk: java/org/apache/catalina/core/StandardContext.java java/org/apache/catalina/deploy/LocalStrings.properties java/org/apache/catalina/deploy/NamingResources.
namingResources.cleanupNoClose
couldn't you implement a closeMethod=close in theResource element, that
way the name of the method is configurable.
Filip
On 3/8/2011 3:15 PM, ma...@apache.org wrote:
Author: markt
Date: Tue Mar 8 22:15:34 2011
New Revision: 1079575
URL: http://svn.apache.org/viewvc?rev=1079575view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=25060
When stopping naming resources look for DataSource resources with a zero-arg
close() method and call it if one is found
Works with Commons DBCP.
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1079575r1=1079574r2=1079575view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Tue Mar 8
22:15:34 2011
@@ -5384,15 +5384,13 @@ public class StandardContext extends Con
setState(LifecycleState.STOPPING);
-// Currently this is effectively a NO-OP but needs to be called to
-// ensure the NamingResources follows the correct lifecycle
+// Binding thread
+ClassLoader oldCCL = bindThread();
+
if (namingResources != null) {
namingResources.stop();
}
-// Binding thread
-ClassLoader oldCCL = bindThread();
-
try {
// Stop our child containers, if any
Modified: tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties?rev=1079575r1=1079574r2=1079575view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/LocalStrings.properties Tue
Mar 8 22:15:34 2011
@@ -43,5 +43,10 @@ webxml.unrecognisedPublicId=The public I
webXml.version.nfe=Unable to parse [{0}] from the version string [{1}]. This
component of the version string will be ignored.
webXml.wrongFragmentName=Used a wrong fragment name {0} at web.xml
absolute-ordering tag!
+namingResources.cleanupCloseFailed=Failed to invoke close method for resource
[{0}] in container [{1}] so no cleanup was performed for that resource
+namingResources.cleanupCloseSecurity=Unable to retrieve close method for
resource [{0}] in container [{1}] so no cleanup was performed for that resource
+namingResources.cleanupNoClose=Resource [{0}] in container [{1}] does not have
a close method so no cleanup was performed for that resource
+namingResources.cleanupNoContext=Failed to retrieve JNDI naming context for
container [{0}] so no cleanup was performed for that container
+namingResources.cleanupNoResource=Failed to retrieve JNDI resource [{0}] for
container [{1}] so no cleanup was performed for that resource
namingResources.mbeanCreateFail=Failed to create MBean for naming resource
[{0}]
namingResources.mbeanDestroyFail=Failed to destroy MBean for naming resource
[{0}]
Modified: tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java?rev=1079575r1=1079574r2=1079575view=diff
==
--- tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java (original)
+++ tomcat/trunk/java/org/apache/catalina/deploy/NamingResources.java Tue Mar
8 22:15:34 2011
@@ -22,9 +22,14 @@ package org.apache.catalina.deploy;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.Serializable;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Hashtable;
+import javax.naming.NamingException;
+import javax.sql.DataSource;
+
import org.apache.catalina.Container;
import org.apache.catalina.Context;
import org.apache.catalina.Engine;
@@ -35,6 +40,7 @@ import org.apache.catalina.mbeans.MBeanU
import org.apache.catalina.util.LifecycleMBeanBase;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.naming.ContextBindings;
import org.apache.tomcat.util.res.StringManager;
@@ -949,11 +955,84 @@ public class NamingResources extends Lif
@Override
protected void stopInternal() throws LifecycleException {
+cleanUp();
setState(LifecycleState.STOPPING);
Re: [VOTE] Release jdbc-pool 1.1.0.1
On 3/10/2011 6:57 AM, Jim Jagielski wrote: Verified... This seems enough, imo, to warrant a Broken... not sure how this is broken :) The connection has been cancelled ie, removed for being abandoned. So you should not be able to use it anymore. There is a question if this should return a SQL exception instead of a NPE Filip On Mar 10, 2011, at 12:09 AM, Keiichi Fujino wrote: 2011/3/4 Filip Hanik - Dev Listsdevli...@hanik.com: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.1 Alpha [ ] Beta - go ahead and release as 1.1.0.1 Beta [X] Stable - go ahead and release as 1.1.0.1 Stable I tested jdbc-pool with simple applications. And it works well. However, when setting removeAbandoned=true, NPE is thrown out. It seems to occur when the Abandoned processing and SQL execution processing are executed at the same time. The synchronization of the Pool-Cleaner thread might not work correctly though I am not checking the code. The following are logs. =localhost.2011-03-10.log Mar 10, 2011 1:24:23 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jdbc] in context with path [/test] threw exception java.lang.NullPointerException at org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:125) at $Proxy9.prepareStatement(Unknown Source) at jdbc_pool.JDBCPoolServlet.doGet(JDBCPoolServlet.java:32) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:243) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) = -- Keiichi.Fujino - 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1497/3496 - Release Date: 03/10/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: STATUS.txt reviews
https://issues.apache.org/jira/browse/INFRA-3507 Filip On 3/10/2011 5:12 AM, Konstantin Kolinko wrote: 2011/3/3 Mark Thomasma...@apache.org: On 02/03/2011 20:57, Filip Hanik - Dev Lists wrote: I wanted to throw out an idea of an alternative or complementary way to handle our STATUS.txt files, and this solution can apply to our CTR branches as well. The solution would be http://www.reviewboard.org/ If there is an interest, I can spend some time configuring an instance for one of our branches and we can give it a test run and see if we like it. Any takers? If you go down that route, use the reviewboard instance provided by ASF infra. I am currently neutral on this. I can see the benefits of reviewboard but I like that by keeping things simple I can easily work off-line. There is a problem with out trunk/tc7 that there are patches that are work-in-progress or are hard to apply and would benefit from review. The current approach is using Bugzilla, but 1) there is no such list of ready-for-review items, like the STATUS file, and they may fell off the radar 2) it is hard to review them there, because you will need separate step to download the patch, and then comment in the text field or whatever If reviewboard can solve the above, it would be fine. From descriptions it looks that it is suited for pre-commit reviews. I have no experience with it, though. Thus I suggest to try it for our trunk. For the RTC branches though I think it is not a replacement for the STATUS. Maybe with more experience I will change my mind, but as of now the STATUS is more traceable and formal. I do not mind about links to reviewboard being mentioned in STATUS, like we mention the patches on people or message threads. The links to ASF reviewboard: https://blogs.apache.org/infra/entry/reviewboard_instance_running_at_the https://reviews.apache.org/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1497/3496 - Release Date: 03/10/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release jdbc-pool 1.1.0.1
On 3/9/2011 11:57 PM, Eiji Takahashi wrote: Hi developers. I encountered the same issue, too. I got following exception. an exception is expected if the connection has been abandoned. it's tricky, one can always throw a SQLException, which leads to a problem, what if a method is called that does not throw SQLException. we can check for this as well best Filip - java.lang.NullPointerException at org.apache.tomcat.jdbc.pool.interceptor.StatementCache$CachedStatement.closeInvoked(StatementCache.java:224) at org.apache.tomcat.jdbc.pool.interceptor.StatementDecoratorInterceptor$StatementProxy.invoke(StatementDecoratorInterceptor.java:226) at $Proxy1.close(Unknown Source) at test.PoolTestServlet.doPost(PoolTestServlet.java:30) at javax.servlet.http.HttpServlet.service(HttpServlet.java:641) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:306) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:354) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:108) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:558) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:379) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:283) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:209) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1671) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) --- When the busy connection reaches abandoned time-out, PoolCleaner calls ConnectionPool#abandon() for this connection. And, reset all Interceptors that is relevant to this connection. In the case of StatementCache, null is set to cacheSize and pcon. As a result, when CachedStatement.closeInvoked is executed, cacheSize.get() causes NPE. I think that other Interceptors also have same issue. I thought several solutions for this issue. (1) Prevent NPE at each Interceptors. (2) Create new interceptor for handling NPE, and set this interceptor to top of interceptor chain. - In this interceptor, change RuntimeException to SQLException. I think that (2) is better than (1), because (2) doesn't depend on design of each Interceptors. On Thu, Mar 10, 2011 at 2:09 PM, Keiichi Fujinokfuj...@apache.org wrote: 2011/3/4 Filip Hanik - Dev Listsdevli...@hanik.com: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.1 Alpha [ ] Beta - go ahead and release as 1.1.0.1 Beta [X] Stable - go ahead and release as 1.1.0.1 Stable I tested jdbc-pool with simple applications. And it works well. However, when setting removeAbandoned=true, NPE is thrown out. It seems to occur when the Abandoned processing and SQL execution processing are executed at the same time. The synchronization of the Pool-Cleaner thread might not work correctly though I am not checking the code. The following are logs. =localhost.2011-03-10.log Mar 10, 2011 1:24:23 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet [jdbc] in context with path [/test] threw exception java.lang.NullPointerException at org.apache.tomcat.jdbc.pool.ProxyConnection.invoke(ProxyConnection.java:125) at $Proxy9.prepareStatement(Unknown Source) at jdbc_pool.JDBCPoolServlet.doGet(JDBCPoolServlet.java:32) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at
Re: Where do we stand with maven publishing?
On 03/05/2011 09:49 AM, Henri Gomez wrote: And what about jdbc pool on Maven Central ? I want to, but it needs to pass a release first Filip 2011/3/4 Filip Hanik - Dev Listsdevli...@hanik.com: Where do we stand with publishing Tomcat jars/artifacts to a Maven repository. I see that the mvn-pub.xml has been updated, but I don't see where the source JARs are generated from. best Filip - 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release jdbc-pool 1.1.0.1
ping! jdbc-pool needs a bit vote tlc On 03/03/2011 12:24 PM, Filip Hanik - Dev Lists wrote: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.1 Alpha [ ] Beta - go ahead and release as 1.1.0.1 Beta [ ] Stable - go ahead and release as 1.1.0.1 Stable best Filip - 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
Re: Where do we stand with maven publishing?
On 3/5/2011 5:10 AM, Mark Thomas wrote: On 04/03/2011 23:46, Filip Hanik - Dev Lists wrote: Not in here http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/catalina/ what am I missing? Couple of things. The artifact IDs were changed for Tomcat 7 so you need to look here: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/tomcat-catalina/ I've looked back in svn and I know I changed the artifact ID but I can't remember exactly why. It may have been related to some reorganisation of the JARs that meant that they didn't have quite the same contents and dependencies. Even if the contents in a jar changes a bit, and dependencies change a bit, that is fine, since the version and dependency management of maven resolves that. I would have kept the same names. Despite the ASF repo being called ibiblio-rsync: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tomcat/ I think we replicate directly from the ASF to Maven central: http://repo2.maven.org/maven2/org/apache/tomcat/ given that Maven central has everything and ibiblio seems to be missing the more recent releases. yup, see that now. Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3482 - Release Date: 03/04/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.10
On 3/5/2011 7:32 AM, Mark Thomas wrote: [X] Stable - go ahead and release as 7.0.10 Stable - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Where do we stand with maven publishing?
On 03/04/2011 01:54 AM, Mark Thomas wrote: On 04/03/2011 00:33, Filip Hanik - Dev Lists wrote: Got it. It doesn't seem to be published to https://repository.apache.org/ nor to ibiblio http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/catalina/ Does it mean we're not running it anymore? It has been run for every stable Tomcat 7 release and the occasional snapshot. I run it once the release vote passes. Ok, I was assuming that even a 7 beta was an official release, and had expected the libraries to be in. best Filip ASF snapshots: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tomcat/tomcat-catalina/ ASF releases: http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tomcat/ Maven central repo: http://repo2.maven.org/maven2/org/apache/tomcat/ Mark - 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
Re: Where do we stand with maven publishing?
On 03/04/2011 12:18 PM, Mark Thomas wrote: On 04/03/2011 17:56, Filip Hanik - Dev Lists wrote: On 03/04/2011 01:54 AM, Mark Thomas wrote: On 04/03/2011 00:33, Filip Hanik - Dev Lists wrote: Got it. It doesn't seem to be published to https://repository.apache.org/ nor to ibiblio http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/catalina/ Does it mean we're not running it anymore? It has been run for every stable Tomcat 7 release and the occasional snapshot. I run it once the release vote passes. Ok, I was assuming that even a 7 beta was an official release, and had expected the libraries to be in. You're right. All of the releases with a releases are there. I see 7.0.0, 7.0.2, 7.0.4, 7.0.5, 7.0.6, 7.0.8. Not in here http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/catalina/ what am I missing? Mark - 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
Re: [VOTE] Release jdbc-pool 1.1.0.0
Thanks, I will get this taken care of, and reroll. Filip On 3/2/2011 8:21 PM, sebb wrote: On 2 March 2011 22:09, Filip Hanik - Dev Listsdevli...@hanik.com wrote: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.0/ tomcat-juli.jar has NOTICE and LICENSE files, but none of the pool jars do. apache-tomcat-jdbc-1.1.0.0-src.zip contains the file test/org/apache/tomcat/jdbc/test/Bug50571.java which is not in the SVN TAG. Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_0/ JDBC_POOL_1_1_0_0/test/org/apache/tomcat/jdbc/test/Bug50805.java has no AL header Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.0 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.0 Alpha [ ] Beta - go ahead and release as 1.1.0.0 Beta [ ] Stable - go ahead and release as 1.1.0.0 Stable best Filip - 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3478 - Release Date: 03/02/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[RESULT] [VOTE] Release jdbc-pool 1.1.0.0
I'll cancel this vote, get all the NOTICE and LICENSE files correct, as well as the tag matching the jars. best Filip On 3/2/2011 3:09 PM, Filip Hanik - Dev Lists wrote: Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.0/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_0/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.0 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.0 Alpha [ ] Beta - go ahead and release as 1.1.0.0 Beta [ ] Stable - go ahead and release as 1.1.0.0 Stable best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3477 - Release Date: 03/02/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release jdbc-pool 1.1.0.1
Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.1/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.1 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.1 Alpha [ ] Beta - go ahead and release as 1.1.0.1 Beta [ ] Stable - go ahead and release as 1.1.0.1 Stable best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Where do we stand with maven publishing?
Where do we stand with publishing Tomcat jars/artifacts to a Maven repository. I see that the mvn-pub.xml has been updated, but I don't see where the source JARs are generated from. best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1076736 - in /tomcat/trunk/modules/jdbc-pool: build.properties.default build.xml sign.sh test/org/apache/tomcat/jdbc/test/Bug50571.java test/org/apache/tomcat/jdbc/test/Bug50805.java
On 3/3/2011 1:25 PM, Konstantin Kolinko wrote: 2011/3/3fha...@apache.org: Author: fhanik Date: Thu Mar 3 19:20:38 2011 New Revision: 1076736 URL: http://svn.apache.org/viewvc?rev=1076736view=rev Log: Add missing files and license header Add NOTICE/LICENSE to all JAR files Added: tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/Bug50571.java svn:eol-style is missing for the new file. Just saying. I do not think it is a show-stopper. thanks, my home dir got wiped, and along with that, the svn settings Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3479 - Release Date: 03/03/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Where do we stand with maven publishing?
On 3/3/2011 5:25 PM, Konstantin Kolinko wrote: 2011/3/4 Filip Hanik - Dev Listsdevli...@hanik.com: Where do we stand with publishing Tomcat jars/artifacts to a Maven repository. I see that the mvn-pub.xml has been updated, but I don't see where the source JARs are generated from. Are you talking about Tomcat 7? res/maven/mvn.properties.default has: #Where do we load the libraries from tomcat.lib.path=../../output/build/lib tomcat.bin.path=../../output/build/bin tomcat.src.path=../../output/src-jars tomcat.embed.path=../../output/embed tomcat.embed.src.path=../../output/embed-src-jars tomcat.extras.path=../../output/extras tomcat.extras.src.path=../../output/extras-src-jars The files in those *-src-jars folders are generated when you do `ant release`. Got it. It doesn't seem to be published to https://repository.apache.org/ nor to ibiblio http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/catalina/ Does it mean we're not running it anymore? Filpi Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3480 - Release Date: 03/03/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
STATUS.txt reviews
I wanted to throw out an idea of an alternative or complementary way to handle our STATUS.txt files, and this solution can apply to our CTR branches as well. The solution would be http://www.reviewboard.org/ If there is an interest, I can spend some time configuring an instance for one of our branches and we can give it a test run and see if we like it. Any takers? Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: STATUS.txt reviews
On 3/2/2011 2:05 PM, Mark Thomas wrote: On 02/03/2011 20:57, Filip Hanik - Dev Lists wrote: I wanted to throw out an idea of an alternative or complementary way to handle our STATUS.txt files, and this solution can apply to our CTR branches as well. The solution would be http://www.reviewboard.org/ If there is an interest, I can spend some time configuring an instance for one of our branches and we can give it a test run and see if we like it. Any takers? If you go down that route, use the reviewboard instance provided by ASF infra. didn't know we had one, excellent! I am currently neutral on this. I can see the benefits of reviewboard but I like that by keeping things simple I can easily work off-line. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3477 - Release Date: 03/02/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release jdbc-pool 1.1.0.0
Source and Binary Packages http://people.apache.org/~fhanik/jdbc-pool/v1.1.0.0/ Tag http://svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_0/ Documentation http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html The proposed 1.1.0.0 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 1.1.0.0 Alpha [ ] Beta - go ahead and release as 1.1.0.0 Beta [ ] Stable - go ahead and release as 1.1.0.0 Stable best Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
On 2/28/2011 5:27 PM, Mark Thomas wrote: On 01/03/2011 00:16, Filip Hanik - Dev Lists wrote: On 2/28/2011 4:49 PM, Mark Thomas wrote: It isn't clear to me if you are voting -1 on the above commit, and the following commits. r1074675 Understood and agree those commits are broken. I'll get those backed out shortly. If you wish to do this, it should at least include: 1. input filters need to check if they retrieved the entire body if only partial, why even attempt a reneg and make your thread hang for soTimeout while it fails. this is another DoS scenario. the system knows if it read the entire body or not. it's part of the protocol itself, no need to rely on timeouts for a reneg to fail. 2. don't change the names of all the flags, since it makes the diffs so much harder to review. just change the lines pertinent to the change. 3. implement rehandshake as simple as possible, by using the handshake(...) and using its return code 4. SSLAuthenticator should have a flag to fail directly without trying to reneg if the connector is misconfigured to avoid reneg for clients vulnerable to the man in the middle reneg attack 5. SSLAuthenticator should be able to find out if the cert truly was client-auth or if it came from another source. otherwise, putting httpd/mod_jk in front of it, and I can bypass client-auth as the document states is required 6. And if you want the most performant solution, instead of opening a selector on the same thread, just call sslEngine.beginHandshake, add the connection to the poller, and return from the call all together. this way, the worker thread is not in use during a handshake, and it's done in the poller just like the initial hand shake. this protects you from slow clients using up threads. this is of course more complicated, so I would not expect it in the first iteration. I would say the other connectors would benefit from improvements in 1,4,5 as well. I agree on all of those points (with a few questions - see below). My current thinking is approaching it in this order. Do 2 in a separate commit. The flag needs to be renamed to ease confusion but a separate commit that does just that should be easy to review. Yes, that would be much better. Address 3 for the NIO connector. That will bring it in line with BIO and APR. Fix 1 for all connectors. I don't understand what you mean in point 4. Could you try and expand on that. Sure, a renegotiation with a non updated client, IIRC would bring CVE-2009-3555 SSL Man-In-The-Middle attack. Hence, some sysadmins should have the configuration option to only allow the initial handshake. Add in a flag that would say disableRenegotiation=true (or similar). Meaning, the only time the valve would work, is if the clientAuth=true in the connector. Fix 5. I may re-word the Javadoc again. Doing the client cert validation in httpd is valid. But how do you know it took place in httpd? Sounds like adding httpd/mod_jk in the mixture, Tomcat makes an assumption that client-auth took place. 6 is definitely more complicated. I did try this before but gave up. That was before I had anything working. It may well be easier to get there from a working solution. I can help you here. But I'd like the simple solution first. The reason the NIO connector doesn't use individual selectors, is that on some systems with high concurrency, having too many selectors made the system puke. Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
On 2/27/2011 4:30 AM, Mark Thomas wrote: On 25/02/2011 20:16, Filip Hanik - Dev Lists wrote: The simplest solution is, would be to use an individual selector. Register the socket and issue a select() on the thread you are running on. If you want to use a shared selector (like NIO does for reads and writes) it requires a bit more logic. I have implemented the simple solution and based on a quick test with the Eclipse debugger the handshake now blocks while waiting for client data. A review would be good since my understanding of NIO is not as good as yours. My initial recommendation is to pull out this change, and as default behavior, throw an exception if the SSLAuthenticator is trying to authenticate and the need-client-auth is not configured. There is much complexity in implementing the renegotiation without a unit test case, as there are both application buffers and network buffers in the NIO implementation that will need to be tested more carefully. So for the sake of not holding up releases, implement the exception case first, where you force the user to configure client authentication, until there is a configuration that we are more comfortable with. best Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.9
[X] Broken - do not release http://svn.apache.org/viewvc?rev=1075030view=rev http://svn.apache.org/viewvc?rev=1074675view=rev Are not completely correct implementations as they don't - support a timeout correctly - dont account for when a write is needed on the selector - they potentially garble a message body larger than the limit of the input buffer http://markmail.org/message/42nme6x2fwfvygqk Filip On 2/28/2011 9:57 AM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.9 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.9/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_9/ The proposed 7.0.9 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.9 Alpha [ ] Beta - go ahead and release as 7.0.9 Beta [ ] Stable - go ahead and release as 7.0.9 Stable Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
Just a little bit more on this. I'm not seeing where SSLAuthenticator.java validates that the request came in on a SSL connection, and what if the SSL cert came from mod_jk. I'm not sure what the requirements for CERT authentication is, but if it is that the cert MUST be validated against a trust store, then this valve, must make sure that the validation actually has taken place. Filip On 2/28/2011 11:06 AM, Filip Hanik - Dev Lists wrote: On 2/27/2011 4:30 AM, Mark Thomas wrote: On 25/02/2011 20:16, Filip Hanik - Dev Lists wrote: The simplest solution is, would be to use an individual selector. Register the socket and issue a select() on the thread you are running on. If you want to use a shared selector (like NIO does for reads and writes) it requires a bit more logic. I have implemented the simple solution and based on a quick test with the Eclipse debugger the handshake now blocks while waiting for client data. A review would be good since my understanding of NIO is not as good as yours. My initial recommendation is to pull out this change, and as default behavior, throw an exception if the SSLAuthenticator is trying to authenticate and the need-client-auth is not configured. There is much complexity in implementing the renegotiation without a unit test case, as there are both application buffers and network buffers in the NIO implementation that will need to be tested more carefully. So for the sake of not holding up releases, implement the exception case first, where you force the user to configure client authentication, until there is a configuration that we are more comfortable with. best Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.9
On 2/28/2011 11:30 AM, Mark Thomas wrote: On 28/02/2011 18:11, Filip Hanik - Dev Lists wrote: [X] Broken - do not release http://svn.apache.org/viewvc?rev=1075030view=rev http://svn.apache.org/viewvc?rev=1074675view=rev Are not completely correct implementations as they don't - support a timeout correctly That is an issue. Should be a relatively easy fix. I got this in my code base, I still recommend pulling out the change until all issues are taken care of. - dont account for when a write is needed on the selector I can't figure out what circumstances the handshake process would return OP_WRITE since it shouldn't ever be waiting for some other process to write data. Could you explain how this might happen? When you want to initiate a renegotiating from the server, you want to write data to the client notifying it of such. This happens when you call beginHandshake. beginHandshake generates the bytes needed to be sent to the client, so you must send them. So we make an attempt to send them. If the attempt to send them fails, meaning no bytes were accepted into the buffer, the handshake(...) calls returns OP_WRITE to let you know that you can be signaled for when this needs to take place. This is most unlikely to happen in a scenario like this, as there TCP buffers should have plenty of space in them and we should be able to take the bytes. However, from a state machine perspective, you still need to account for the state. The other mistake, is that there is an assumed OP_READ, even if the handshake completes. The change will require a bit more careful analysis to get right. Not to mention, this code, as you may have noticed, is fragile. - they potentially garble a message body larger than the limit of the input buffer This should be handled by the existing code although I didn't test it. Should be easy to write a unit test to confirm what happens in this case. Try to start sending a 25MB file upload together with your headers. Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.9
On 2/28/2011 12:00 PM, Mark Thomas wrote:
On 28/02/2011 18:45, Filip Hanik - Dev Lists wrote:
On 2/28/2011 11:30 AM, Mark Thomas wrote:
On 28/02/2011 18:11, Filip Hanik - Dev Lists wrote:
[X] Broken - do not release
http://svn.apache.org/viewvc?rev=1075030view=rev
http://svn.apache.org/viewvc?rev=1074675view=rev
Are not completely correct implementations as they don't
- support a timeout correctly
That is an issue. Should be a relatively easy fix.
I got this in my code base,
Could you commit it then?
I still recommend pulling out the change
until all issues are taken care of.
We can easily comment out the rehandshake() call if the issues aren't
fixed by the time we decide to do the next release.
- dont account for when a write is needed on the selector
I can't figure out what circumstances the handshake process would return
OP_WRITE since it shouldn't ever be waiting for some other process to
write data. Could you explain how this might happen?
When you want to initiate a renegotiating from the server, you want to
write data to the client notifying it of such. This happens when you
call beginHandshake.
beginHandshake generates the bytes needed to be sent to the client, so
you must send them.
So we make an attempt to send them. If the attempt to send them fails,
meaning no bytes were accepted into the buffer, the handshake(...) calls
returns OP_WRITE to let you know that you can be signaled for when this
needs to take place.
This is most unlikely to happen in a scenario like this, as there TCP
buffers should have plenty of space in them and we should be able to
take the bytes. However, from a state machine perspective, you still
need to account for the state.
So what is the right way to respond to an OP_WRITE? Select and wait for
the signal and then call handshakeWrap()?
you don't call handshakeWrap or unwrap, the handshake(boolean,boolean) does everything for you. You simply call select() with OP_WRITE, and
when it returns from that, you call handshake(...) again, and it automagically does the state machine for you
The other mistake, is that there is an assumed OP_READ, even if the
handshake completes.
I don't see what you mean here. Could you clarify please.
handshake(true, true);
297 if (handshakeStatus == HandshakeStatus.NEED_UNWRAP) {
298 // Block until there is data to read from the client
299 Selector selector = null;
again, this is ignoring the state machine. What you need to do here, is check
the results of handshake(true,true), not if NEED_UNWRAP is there.
it should be (in pseudo code):
loop:
int status = handshake(...);
switch (status): {
case 0: handshake-completed; return;
case -1: something went wrong; throw exception;
default: select.select(status);
end loop
The change will require a bit more careful analysis to get right. Not to
mention, this code, as you may have noticed, is fragile.
- they potentially garble a message body larger than the limit of the
input buffer
This should be handled by the existing code although I didn't test it.
Should be easy to write a unit test to confirm what happens in this case.
Try to start sending a 25MB file upload together with your headers.
Does it need to be that big? I was planning on writing a unit test that
POSTed 20 bytes to a resource that required CLIENT-CERT and then testing
with an input buffer of 100 bytes, 20 bytes and 5 bytes (or similar
numbers).
It would have to be bigger than maxPostSize for the data to remain in the
buffers
Filip
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3473 - Release Date: 02/28/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
Ok, I've done some research. My conclusion is that I'm -1 for this change. My suggestion on the other thread, that we should simply throw an exception if the server is not configured to handle client-auth in the connector still stands. Let me explain why: 1. The idea behind this code was that if the client is using SSL, the SSL request must have been authenticated against the trust store, meaning that the initial handshake did this. 2. If the server was not configured for client auth [1], the current implementation wants to do a renegotiation. 3. The current implementation tries to swallow up as much body content as possible, until maxPostSize has been filled up. This breaks in the following use case: 1. Client Opens TCP Session 2. Client Completes Initial Handshake 3. Client Sends HTTP Headers and Body of Size N, where NmaxPostSize When the server in this case has read the HTTP headers, it's already too late to renegotiate, since the body is already underway. The only time we could renegotiate, would be after the request had been read in its entirety. (There is a short window where this could happen, if the client had sent a 100-Continue header before the body was even started, but I'm excluding this use case for now.) Since we can't read the entire body without discarding it, we can't implement this as the way it has been. Hence the -1. Here is the proposed solution: 1. When SSLAuthenticator starts up, it should inspect configuration of the connector to make sure there is at least one connector with clientAuth=true in it Note: You need to decide what to do if there is only an AJP connector, do you trust that the webserver did client-auth on your behalf? 2. If a request comes in, and the system is not configured for client-auth, all a server can do is send a 400 Bad Request (or Not Authorized) back. Note: It should also send a Connection:close so that we can close the connection without having to read the body. (See Rainer's email about draining implications) 3. We should not implement server initiated renegotiation at this point in time, since we can't do it in a way it would allow for the system to handle the above use case. 4. We should not implement renegotiation period on the NIO connector at this time, since it would still risk a vulnerability with clients that are not updated. In short, the NIO code can safely be backed out. The solution is quite simple, and it does not involve modifying the connectors. [1] setNeedClientAuth(true); http://download.oracle.com/javase/6/docs/api/javax/net/ssl/SSLEngine.html#setNeedClientAuth(boolean) best Filip On 2/25/2011 1:16 PM, Filip Hanik - Dev Lists wrote: This looks like a CPU spinning handshake to me. The operation handshake(true, true); returns an IO interest to be registered with a selector. If the client is slow here or misbehaving, you could end up in a end less loop, and hence we can have introduced a very simple DoS vulnerability here. The simplest solution is, would be to use an individual selector. Register the socket and issue a select() on the thread you are running on. If you want to use a shared selector (like NIO does for reads and writes) it requires a bit more logic. I understand where you are going with this solution, and I can probably fix this today as I sit on the airplane on my way home. best Filip On 02/25/2011 12:19 PM, ma...@apache.org wrote: Author: markt Date: Fri Feb 25 19:19:13 2011 New Revision: 1074675 URL: http://svn.apache.org/viewvc?rev=1074675view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49284 Support SSL re-negotiation in the HTTP NIO connector There is a fair amount of renaming in this patch. The real work is in the new rehandshake() method in the SecureNioChannel. Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1074675r1=1074674r2=1074675view=diff == --- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java (original) +++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Feb 25 19:19:13 2011 @@ -23,6 +23,8 @@ import java.nio.channels.SelectionKey; import java.util.Locale; import java.util.concurrent.Executor; +import javax.net.ssl.SSLEngine; + import org.apache.coyote.ActionCode; import org.apache.coyote.Request; import org.apache.coyote.RequestInfo; @@ -42,7 +44,9 @@ import org.apache.tomcat.util.net.NioCha import org.apache.tomcat.util.net.NioEndpoint
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
On 2/28/2011 4:49 PM, Mark Thomas wrote: It isn't clear to me if you are voting -1 on the above commit, and the following commits. r1074675 If you wish to do this, it should at least include: 1. input filters need to check if they retrieved the entire body if only partial, why even attempt a reneg and make your thread hang for soTimeout while it fails. this is another DoS scenario. the system knows if it read the entire body or not. it's part of the protocol itself, no need to rely on timeouts for a reneg to fail. 2. don't change the names of all the flags, since it makes the diffs so much harder to review. just change the lines pertinent to the change. 3. implement rehandshake as simple as possible, by using the handshake(...) and using its return code 4. SSLAuthenticator should have a flag to fail directly without trying to reneg if the connector is misconfigured to avoid reneg for clients vulnerable to the man in the middle reneg attack 5. SSLAuthenticator should be able to find out if the cert truly was client-auth or if it came from another source. otherwise, putting httpd/mod_jk in front of it, and I can bypass client-auth as the document states is required 6. And if you want the most performant solution, instead of opening a selector on the same thread, just call sslEngine.beginHandshake, add the connection to the poller, and return from the call all together. this way, the worker thread is not in use during a handshake, and it's done in the poller just like the initial hand shake. this protects you from slow clients using up threads. this is of course more complicated, so I would not expect it in the first iteration. I would say the other connectors would benefit from improvements in 1,4,5 as well. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1074675 - in /tomcat/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/
This looks like a CPU spinning handshake to me.
The operation handshake(true, true); returns an IO interest to be
registered with a selector.
If the client is slow here or misbehaving, you could end up in a end
less loop, and hence we can have introduced a very simple DoS
vulnerability here.
The simplest solution is, would be to use an individual selector.
Register the socket and issue a select() on the thread you are running on.
If you want to use a shared selector (like NIO does for reads and
writes) it requires a bit more logic.
I understand where you are going with this solution, and I can probably
fix this today as I sit on the airplane on my way home.
best
Filip
On 02/25/2011 12:19 PM, ma...@apache.org wrote:
Author: markt
Date: Fri Feb 25 19:19:13 2011
New Revision: 1074675
URL: http://svn.apache.org/viewvc?rev=1074675view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49284
Support SSL re-negotiation in the HTTP NIO connector
There is a fair amount of renaming in this patch. The real work is in the new
rehandshake() method in the SecureNioChannel.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/net/NioChannel.java
tomcat/trunk/java/org/apache/tomcat/util/net/SecureNioChannel.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Fri Feb
25 19:19:13 2011
@@ -23,6 +23,8 @@ import java.nio.channels.SelectionKey;
import java.util.Locale;
import java.util.concurrent.Executor;
+import javax.net.ssl.SSLEngine;
+
import org.apache.coyote.ActionCode;
import org.apache.coyote.Request;
import org.apache.coyote.RequestInfo;
@@ -42,7 +44,9 @@ import org.apache.tomcat.util.net.NioCha
import org.apache.tomcat.util.net.NioEndpoint;
import org.apache.tomcat.util.net.NioEndpoint.KeyAttachment;
import org.apache.tomcat.util.net.SSLSupport;
+import org.apache.tomcat.util.net.SecureNioChannel;
import org.apache.tomcat.util.net.SocketStatus;
+import org.apache.tomcat.util.net.jsse.JSSEFactory;
/**
@@ -625,8 +629,25 @@ public class Http11NioProcessor extends
.setLimit(maxSavePostSize);
inputBuffer.addActiveFilter
(inputFilters[Constants.BUFFERED_FILTER]);
+
+SecureNioChannel sslChannel = (SecureNioChannel) socket;
+SSLEngine engine = sslChannel.getSslEngine();
+if (!engine.getNeedClientAuth()
!engine.getWantClientAuth()) {
+// Need to re-negotiate SSL connection
+engine.setNeedClientAuth(true);
+try {
+sslChannel.rehandshake();
+sslSupport = (new JSSEFactory()).getSSLSupport(
+engine.getSession());
+} catch (IOException ioe) {
+
log.warn(sm.getString(http11processor.socket.sslreneg,
+ioe));
+}
+}
try {
-Object sslO = sslSupport.getPeerCertificateChain(true);
+// use force=false since re-negotiation is handled above
+// (and it is a NO-OP for NIO anyway)
+Object sslO = sslSupport.getPeerCertificateChain(false);
if( sslO != null) {
request.setAttribute
(SSLSupport.CERTIFICATE_KEY, sslO);
Modified: tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties?rev=1074675r1=1074674r2=1074675view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/LocalStrings.properties Fri Feb
25 19:19:13 2011
@@ -31,6 +31,7 @@ http11processor.request.process=Error pr
http11processor.request.finish=Error finishing request
http11processor.response.finish=Error finishing response
http11processor.socket.info=Exception getting socket information
+http11processor.socket.sslreneg=Exception re-negotiating SSL connection
http11processor.socket.ssl=Exception getting SSL attributes
http11processor.socket.timeout=Error setting socket timeout
Modified:
Re: Reaching ulimit values for open files can generate huge log files
Wouldn't you build this into the logging framework, instead of one
specific component?
best
Filip
On 02/21/2011 08:21 AM, Mark Thomas wrote:
The ASF Sonar installation managed to generate 46GB of identical log
messages [1] today in the 8 hours it took to notice it was down.
While better monitoring would/should have identified the problem sooner,
it does demonstrate a problem with the acceptor threads in all three
endpoints. If there is a system-level issue that causes the accept()
call to always fail (such as hitting the ulimit) then the endpoint
essentially enters a loop where it logs an error message for every
iteration of the loop. This will result in many log messages per second.
I'd like to do something about this. I was thinking of something along
the lines of the following for each endpoint.
Index: java/org/apache/tomcat/util/net/JIoEndpoint.java
===
--- java/org/apache/tomcat/util/net/JIoEndpoint.java(revision 1072939)
+++ java/org/apache/tomcat/util/net/JIoEndpoint.java(working copy)
@@ -183,9 +183,19 @@
@Override
public void run() {
+int errorDelay = 0;
+
// Loop until we receive a shutdown command
while (running) {
+if (errorDelay 0) {
+try {
+Thread.sleep(errorDelay);
+} catch (InterruptedException e) {
+// Ignore
+}
+}
+
// Loop if endpoint is paused
while (paused running) {
try {
@@ -225,9 +235,15 @@
// Ignore
}
}
+errorDelay = 0;
} catch (IOException x) {
if (running) {
log.error(sm.getString(endpoint.accept.fail), x);
+if (errorDelay == 0) {
+errorDelay = 50;
+} else if (errorDelay 1600) {
+errorDelay = errorDelay * 2;
+}
}
} catch (NullPointerException npe) {
if (running) {
Thoughts / comments?
Mark
[1] http://pastebin.com/CrsujeW4
-
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
Re: Reaching ulimit values for open files can generate huge log files
On 02/22/2011 12:59 PM, Mark Thomas wrote:
On 22/02/2011 19:34, Filip Hanik - Dev Lists wrote:
Wouldn't you build this into the logging framework, instead of one
specific component?
You could, if you can find an efficient way to spot duplicate log
messages and then differentiate correctly between when you want the
duplicates and when you don't. I'm not sure how easy that would be.
Suggestions welcome.
I'd probably wouldn't care so much about duplication as I would care
about logging frequency/amount per thread and have ways to adjust that.
The other issue with the current code is that it is likely to chew up a
large chunk of CPU time. Fixing the log mechanism won't fix that.
the maxConnections setting however, would fix this issue, as that forces
the system to back off.
So, I would have no problem adding a delay for that error. It makes the
product more stable, it would have to be added to all end points, as I
suspect they all do the same thing.
Filip
Of course, the real solution is fix the ulimit issue in the first place
but Tomcat's behaviour in this error condition seems sufficiently bad to
justify some changes to handle it more gracefully.
Mark
best
Filip
On 02/21/2011 08:21 AM, Mark Thomas wrote:
The ASF Sonar installation managed to generate 46GB of identical log
messages [1] today in the 8 hours it took to notice it was down.
While better monitoring would/should have identified the problem sooner,
it does demonstrate a problem with the acceptor threads in all three
endpoints. If there is a system-level issue that causes the accept()
call to always fail (such as hitting the ulimit) then the endpoint
essentially enters a loop where it logs an error message for every
iteration of the loop. This will result in many log messages per second.
I'd like to do something about this. I was thinking of something along
the lines of the following for each endpoint.
Index: java/org/apache/tomcat/util/net/JIoEndpoint.java
===
--- java/org/apache/tomcat/util/net/JIoEndpoint.java(revision
1072939)
+++ java/org/apache/tomcat/util/net/JIoEndpoint.java(working copy)
@@ -183,9 +183,19 @@
@Override
public void run() {
+int errorDelay = 0;
+
// Loop until we receive a shutdown command
while (running) {
+if (errorDelay 0) {
+try {
+Thread.sleep(errorDelay);
+} catch (InterruptedException e) {
+// Ignore
+}
+}
+
// Loop if endpoint is paused
while (paused running) {
try {
@@ -225,9 +235,15 @@
// Ignore
}
}
+errorDelay = 0;
} catch (IOException x) {
if (running) {
log.error(sm.getString(endpoint.accept.fail), x);
+if (errorDelay == 0) {
+errorDelay = 50;
+} else if (errorDelay 1600) {
+errorDelay = errorDelay * 2;
+}
}
} catch (NullPointerException npe) {
if (running) {
Thoughts / comments?
Mark
[1] http://pastebin.com/CrsujeW4
-
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
-
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
Re: svn commit: r1071735 - /tomcat/trunk/modules/jdbc-pool/
On 02/17/2011 11:50 AM, Konstantin Kolinko wrote: -build.properties -includes -output done thanks - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1068989 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
I will fix it. Reattempt is managed in the channel itself at a much lower level. That has always been the case. Adding reattempt here is
ambiguous, so I will readjust the interface to return void.
best
Filip
On 2/10/2011 3:36 AM, Konstantin Kolinko wrote:
2011/2/9fha...@apache.org:
Author: fhanik
Date: Wed Feb 9 17:39:24 2011
New Revision: 1068989
URL: http://svn.apache.org/viewvc?rev=1068989view=rev
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50667
Move the callback outside try/catch to avoid duplicate callbacks
I do not quite get it.
JavaDoc comment for ExtendedRpcCallback#replyFailed(..) says
@return true if the callback would like to reattempt the reply, false
otherwise
In this code returning true will result in falling through and just a
duplicate call to the handler, now reporting success:
excallback.replySucceeded(rmsg.message, reply, sender);
I do not see any reattempt here.
Best regards,
Konstantin Kolinko
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068989r1=1068988r2=1068989view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 17:39:24 2011
@@ -158,9 +158,6 @@ public class RpcChannel implements Chann
channel.send(new Member[] {sender},
rmsg,replyMessageOptions ~Channel.SEND_OPTIONS_SYNCHRONIZED_ACK);
}
finished = true;
-if (excallback != null !asyncReply) {
-excallback.replySucceeded(rmsg.message, reply, sender);
-}
}catch ( Exception x ) {
if (excallback != null !asyncReply) {
finished = !excallback.replyFailed(rmsg.message,
reply, sender, x);
@@ -169,6 +166,9 @@ public class RpcChannel implements Chann
log.error(Unable to send back reply in
RpcChannel.,x);
}
}
+if (finished excallback != null !asyncReply) {
+excallback.replySucceeded(rmsg.message, reply, sender);
+}
}
}//end if
}
-
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
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3434 - Release Date: 02/10/11
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection draining when upload to large
On 2/10/2011 6:04 AM, Rainer Jung wrote: Servlet 3 standardizes file uploads. It contains the ability to limit on request size, pretty much the same as commons fileupload supported for many years. It seems when this conditions triggers the rest of the request inout stream is still drained at the end of the request. swallowInput is not being set to false. It seems there's still no server-side prevention against huge uploads possible. The upload is not put into memory, but the thread is only freed once the whole request body is read. Shouldn't Tomcat ignore the rest of data and close the connection in this case? standard soTimeout (read timeout) should apply. Meaning, if the client stops sending data, it should eventually result in an IOException and back out the thread. Filip Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3434 - Release Date: 02/10/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1068808 - /tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
I'm glad you commented, there should be no looping at all. It was a left over
from a previous proposal
fixed in r1068996
Filip
On 2/9/2011 2:35 AM, kkoli...@apache.org wrote:
Author: kkolinko
Date: Wed Feb 9 09:35:16 2011
New Revision: 1068808
URL: http://svn.apache.org/viewvc?rev=1068808view=rev
Log:
Followup to r1068549 - add annotations.
I thought about moving ErrorHandler instance creation outside the retry loop,
but actually that is not needed: looping happens only when asyncReply==false
and ErrorHandler is created only when asyncReply==true. Thus it is created only
once.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1068808r1=1068807r2=1068808view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Feb
9 09:35:16 2011
@@ -139,10 +139,11 @@ public class RpcChannel implements Chann
final Member fsender = sender;
if (excallback!=null asyncReply) {
handler = new ErrorHandler() {
+@Override
public void handleError(ChannelException x, UniqueId
id) {
excallback.replyFailed(request, response,
fsender, x);
}
-
+@Override
public void handleCompletion(UniqueId id) {
excallback.replySucceeded(request, response,
fsender);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3431 - Release Date: 02/08/11
-
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.32
On 02/02/2011 12:37 PM, jean-frederic clere wrote: [X] Stable - 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
Re: svn commit: r1063791 - in /tomcat/trunk: java/org/apache/catalina/tribes/group/RpcChannel.java webapps/docs/changelog.xml
hmm, it should probably throw the commented out channel exception
instead of simply bailing out with the flag set.
After all the timeout has not been reached, so the caller should not be
tricked into thinking that it has, since no one ever checks the
interrupted flag
Filip
On 01/26/2011 09:53 AM, ma...@apache.org wrote:
Author: markt
Date: Wed Jan 26 16:53:23 2011
New Revision: 1063791
URL: http://svn.apache.org/viewvc?rev=1063791view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=50648
Correctly set the interrupt status if a thread using RpcChannel is interrupted
waiting for a message reply.
Based on a patch by Olivier Costet.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java?rev=1063791r1=1063790r2=1063791view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/group/RpcChannel.java Wed Jan
26 16:53:23 2011
@@ -95,8 +95,7 @@ public class RpcChannel implements Chann
if ( rpcOptions != NO_REPLY ) collector.wait(timeout);
}
} catch ( InterruptedException ix ) {
-Thread.interrupted();
-//throw new ChannelException(ix);
+Thread.currentThread().interrupt();
}finally {
responseMap.remove(key);
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1063791r1=1063790r2=1063791view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Jan 26 16:53:23 2011
@@ -158,6 +158,11 @@
Be consistent with locks on sessionCreationTiming,
sessionExpirationTiming in DeltaManager.resetStatistics(). (kkolinko)
/fix
+fix
+bug50648/bug: Correctly set the interrupt status if a thread using
+codeRpcChannel/code is interrupted waiting for a message reply.
+Based on a patch by Olivier Costet. (markt)
+/fix
/changelog
/subsection
subsection name=Web applications
-
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
Re: Proposal: set default for Connector.allowCasualMultipartParsing to true
I'd opt for the default value to be true. I rather have usability than spec compliance. that's exactly what the STRICT_SERVLET_COMPLIANCE flag does, it opts for usability,performance etc rather than spec compliance, and the default value I believe is false on that flag. Filip On 01/21/2011 11:05 AM, Mark Thomas wrote: On 21/01/2011 17:57, Konstantin Kolinko wrote: 2011/1/21 Christopher Schultzch...@christopherschultz.net: All, I've just committed a fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=49711 (HttpServletRequest#getParts() does not work in a Filter) with a new configuration attribute on theConnector called allowCasualMultipartParsing whose default value is false. Please see BZ for details. I propose to make the default for this setting true unless STRICT_SERVLET_COMPLIANCE is set to TRUE. Any comments? Why is it on Connector? Won't it be better to have it on Context? Per Context seems reasonable to me. As far as defaults go, I'd rather non-spec compliant features were disabled by default. That way users have to explicitly enable them and can't complain about portability when they move their app to a different container that doesn't have the feature. Mark - 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
Re: Need a 6.0.31 release
+1 On 1/20/2011 9:09 AM, Mark Thomas wrote: The memory leak in the Tomcat 7 NIO connector [1] got back-ported to 6.0.x and included in 6.0.30. [2] I have proposed the fix for 6.0.x. Given the severity I think we need to approve the backport and start a 6.0.31 release asap. Mark [1] http://svn.apache.org/viewvc?view=revisionrevision=1050249 [2] http://svn.apache.org/viewvc?view=revisionrevision=1033341 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3391 - Release Date: 01/19/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1061451 - /tomcat/tc6.0.x/trunk/STATUS.txt
On 1/20/2011 11:45 AM, kkoli...@apache.org wrote: Author: kkolinko Date: Thu Jan 20 18:45:09 2011 New Revision: 1061451 URL: http://svn.apache.org/viewvc?rev=1061451view=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=1061451r1=1061450r2=1061451view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jan 20 18:45:09 2011 @@ -112,8 +112,16 @@ PATCHES PROPOSED TO BACKPORT: http://people.apache.org/~fhanik/dslink.patch +1: fhanik, funkman -1: + kkolinko: +1) Need to remove @Override at DataSourceLinkFactory.DataSourceHandler#invoke(). +Otherwise it does not compile with Java 5. That is because InvocationHandler is an interface. +2) The following line in NamingContextListener#addResourceLink(): +IteratorString i = resourceLink.listProperties(); +Here ContextResourceLink#listProperties() returns Iterator, not +IteratorString, but IDE does not give me a warning and I see no +@SuppressWarnings arround. It is odd. done. Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7.0.x. still CTR?
I'd prefer to stay CTR for a while. Chances are there are still much to be fixed given all the changes that have taken place. Filip On 1/18/2011 11:41 AM, Christopher Schultz wrote: All, Since Tomcat 7.0.x went stable, does that change the commit policy, or are we still doing commit-them-review? Thanks, -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: simple tomcat extension
can't you just create a directory, drop your jars in there, and in conf/catalina.properties, configure the shared.loader property? best Filip On 1/13/2011 9:05 AM, Juraj Burian wrote: Hello folks, I would like introduce new very simple extension of Tomcat. In my opinion, many people must have solved situation when some extra configurations or classes must be loaded into application that can't be part of WAR file. Applications servers (WAS for example.) has concept of configurable shared libs. In Tomcat concept like this is missing. So I think that would be very nice have possibility have some way how to do it. Mine suggestion is to create new class loader (or extend current implementation of WebappClassLoader). Simple solution can extend set of repositories in implicit manner. If context is defined, let say CONTEXT, and directory CATALINA_HOME/webappsLib/[CONTEXT]/lib or directory CATALINA/webappsLib/[CONTEXT]/classes exists, then classloader append this entries to repositories. More advanced strategy can be used for that, but as first step is this relatively good solution. Please let me know your opinion. I have code ready. It is separate implementation, so one must extends context.xml like this: Context Loader loaderClass=org.apache.catalina.loader.WebappClassLoaderExt/ ... best regards Juraj Burian - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3375 - Release Date: 01/12/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 50333] IllegalArgumentException occurs when setting maxActive to smaller than 1.
roger that Rainer, thank you! On 1/10/2011 1:43 PM, Rainer Jung wrote: Hi Filip, On 10.01.2011 17:41, bugzi...@apache.org wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=50333 Filip Hanikfha...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Filip Hanikfha...@apache.org 2011-01-10 11:41:53 EST --- svn r 1057268 if you write it as r1057268 a regexp that I think Mark added sometime to Bugzilla will detect it and provide a nice link to the viewvc revision entry in the HTML view of the ticket. It does not work when whitespace is between the r and the revision number. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3373 - Release Date: 01/11/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for 6.0.30?
+1 Filip On 1/4/2011 3:44 AM, Mark Thomas wrote: It has been a while since 6.0.29 and there have been a few requests for this on the users list. Jean-Frederic, do you have any plans for 6.0.30 at this point? Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3357 - Release Date: 01/03/11 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat JDBC Pool in Tomcat 6.0.x / 7.0.x
On 1/4/2011 9:22 AM, Henri Gomez wrote: I just see a new tag for jdbc-pool. I'll be very happy to have such advanced pool on Tomcat but we need some stable release (and of course artifact deployed to Maven central). So what's the status for it, and possible inclusion (as extra) in Tomcat 6.0.x ? I can run a vote for a release, people just need to check it out, and then we can release it. Personally I like to see it as default for Tomcat 7, as it offers much enhancements, and little disadvantages over dbcp the code base is so small, that the interest in working on it, makes it a bit harder Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1055137 - in /tomcat/trunk/modules/jdbc-pool: java/org/apache/tomcat/jdbc/pool/PooledConnection.java test/org/apache/tomcat/jdbc/test/AlternateUsernameTest.java
On 1/4/2011 12:27 PM, sebb wrote:
On 4 January 2011 18:37,fha...@apache.org wrote:
Author: fhanik
Date: Tue Jan 4 18:37:44 2011
New Revision: 1055137
URL: http://svn.apache.org/viewvc?rev=1055137view=rev
Log:
No need to instantiate a new driver instance each time, simply reuse the one we
got
Modified:
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
tomcat/trunk/modules/jdbc-pool/test/org/apache/tomcat/jdbc/test/AlternateUsernameTest.java
Modified:
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java?rev=1055137r1=1055136r2=1055137view=diff
==
---
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/java/org/apache/tomcat/jdbc/pool/PooledConnection.java
Tue Jan 4 18:37:44 2011
@@ -74,7 +74,7 @@ public class PooledConnection {
/**
* If using a XAConnection underneath.
*/
-private volatile javax.sql.XAConnection xaConnection;
+protected volatile javax.sql.XAConnection xaConnection;
/**
* When we track abandon traces, this string holds the thread dump
*/
@@ -117,6 +117,8 @@ public class PooledConnection {
private volatile boolean suspect = false;
+private java.sql.Driver driver = null;
+
/**
* Constructor
* @param prop - pool properties
@@ -229,10 +231,12 @@ public class PooledConnection {
}
}
protected void connectUsingDriver() throws SQLException {
-java.sql.Driver driver = null;
+
try {
-driver = (java.sql.Driver)
Class.forName(poolProperties.getDriverClassName(),
- true,
PooledConnection.class.getClassLoader()).newInstance();
+if (driver==null)
+driver = (java.sql.Driver)
Class.forName(poolProperties.getDriverClassName(),
+ true,
PooledConnection.class.getClassLoader()
+ ).newInstance();
This is not thread-safe.
and if you read the code, you'll see that it doesn't matter. sometimes thread safety can be ignored for the sake of performance and
simplicity since there will never be a bug.
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
