Re: WebSocket status
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. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
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. 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
Re: svn commit: r1295286 - in /tomcat/trunk/java/org/apache/catalina/websocket: LocalStrings.properties WsFrame.java
On 01/03/2012 03:56, Konstantin Kolinko wrote:
> 2012/3/1 :
>> Author: markt
>> Date: Wed Feb 29 21:24:59 2012
>> New Revision: 1295286
>> Modified: tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java?rev=1295286&r1=1295285&r2=1295286&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java (original)
>> +++ tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java Wed Feb 29
>> 21:24:59 2012
>> @@ -215,8 +215,8 @@ public class WsFrame {
>> } else if (read == 0) {
>> return null;
>> } else {
>> -// TODO message
>> -throw new IOException();
>> +throw new IOException(
>> +sm.getString("frame.readFailed",
>> Integer.valueOf(read)));
>
> Maybe java.io.EOFException ?
> I see that read can be -1 here.
Yes, read == -1 should really be handled as a separate case.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1295572 - in /tomcat/trunk/java/org/apache/catalina/websocket: LocalStrings.properties WsFrame.java
Author: markt
Date: Thu Mar 1 14:10:44 2012
New Revision: 1295572
URL: http://svn.apache.org/viewvc?rev=1295572&view=rev
Log:
Explicit handling for end of stream.
Based on review input from kkolinko
Modified:
tomcat/trunk/java/org/apache/catalina/websocket/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java
Modified:
tomcat/trunk/java/org/apache/catalina/websocket/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/websocket/LocalStrings.properties?rev=1295572&r1=1295571&r2=1295572&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/websocket/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/websocket/LocalStrings.properties Thu
Mar 1 14:10:44 2012
@@ -16,6 +16,7 @@
frame.eos=The end of the stream was reached before the expected number of
payload bytes could be read
frame.invalidUtf8=A sequence of bytes was received that did not represent
valid UTF-8
frame.readFailed=Failed to read the first byte of the next WebSocket frame.
The return value from the read was [{0}]
+frame.readEos=The end of the stream was reached when trying to read the first
byte of a new WebSocket frame
frame.notMasked=The client frame was not masked but all client frames must be
masked
is.notContinuation=A frame with the OpCode [{0}] was received when a
continuation frame was expected
Modified: tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java?rev=1295572&r1=1295571&r2=1295572&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java (original)
+++ tomcat/trunk/java/org/apache/catalina/websocket/WsFrame.java Thu Mar 1
14:10:44 2012
@@ -16,6 +16,7 @@
*/
package org.apache.catalina.websocket;
+import java.io.EOFException;
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
@@ -214,6 +215,8 @@ public class WsFrame {
return new WsFrame(first[0], processor);
} else if (read == 0) {
return null;
+} else if (read == -1) {
+throw new EOFException(sm.getString("frame.readEos"));
} else {
throw new IOException(
sm.getString("frame.readFailed", Integer.valueOf(read)));
-
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
Publishing taglibs mini-site
Is there any information lying around on how to update the taglibs site? Is taglibs-parent/site.xml actually used or is everything in the site module? What's the process for publishing? Where does it deploy to? Is a vote needed before push? Do we want to preview changes online or is a review based on local build enough? Thanks Jeremy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
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 is <3% 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
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 is<3% 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
DO NOT REPLY [Bug 52804] New: Make PoolProperties implement Cloneable.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52804 Bug #: 52804 Summary: Make PoolProperties implement Cloneable. Product: Tomcat Modules Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: jdbc-pool AssignedTo: dev@tomcat.apache.org ReportedBy: colin.mcfarl...@incito.co.uk Classification: Unclassified It would be very useful to have the PoolProperties class implement the java.lang.Cloneable interface. We have many databases that share the same schema, username, password, configuration etc but differ only in their URL. Implementing a routing datasource based on something like org.springframework.jdbc.datasource.AbstractDataSource can then just clone a PoolProperties object and set the one or two properties that differ in the clone. In a spring project the properties that are common across all the datasources are only supplied once. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
On 01/03/2012 17:13, Filip Hanik - Dev Lists wrote: > Mark, what buffer size are you referring to increase for the web socket > tests to all pass? Sorry, should have been clearer about that. In o.a.c.websocket.MessageInbound // 2MB - like maxPostSize private int byteBufferMaxSize = 2097152; private int charBufferMaxSize = 2097152; I normally multiple those by 16. The buffers need to be 16M plus a bit for the headers so I allow a large margin ;) Mark > > 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 is<3% 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
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 is<3% 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
DO NOT REPLY [Bug 52805] New: Update to ECJ 3.7.2
https://issues.apache.org/bugzilla/show_bug.cgi?id=52805 Bug #: 52805 Summary: Update to ECJ 3.7.2 Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: knst.koli...@gmail.com Classification: Unclassified ecj-3.7.2 is available http://download.eclipse.org/eclipse/downloads/eclipse3x.php -> Latest Release -> 3.7.2 -> JDT Core Batch Compiler It gives: http://download.eclipse.org/eclipse/downloads/drops/R-3.7.2-201202080800/index.php#JDTCORE -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 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: WebSocket status
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
UpgradeProcessor {
@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 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 01/03/2012 18:00, Filip Hanik - Dev Lists wrote: > I see, MessageInbound has hard coded receive buffers. Got it They are configurable, they just aren't currently configured. I've been meaning to apply a patch that would add some commented out configuration to the examples webapp so it can just be uncommented to run the Autobahn tests. I'll try and do that shortly. Mark > > 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 is<3% 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 > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: WebSocket status
On Thu, Mar 1, 2012 at 9:54 AM, Mark Thomas wrote: > On 01/03/2012 17:13, Filip Hanik - Dev Lists wrote: > > Mark, what buffer size are you referring to increase for the web socket > > tests to all pass? > > Sorry, should have been clearer about that. > > In o.a.c.websocket.MessageInbound > >// 2MB - like maxPostSize >private int byteBufferMaxSize = 2097152; >private int charBufferMaxSize = 2097152; > > I normally multiple those by 16. The buffers need to be 16M plus a bit > for the headers so I allow a large margin ;) > I hope neither 2M or 16M will be allocated by default - that's the limit on growth ? I'm curious, did you do any load test - and what's the max number of websocket connections that can be kept alive with APR/NIO ? Costin > > Mark > > > > > 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 is<3% 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 01/03/2012 18:22, Costin Manolache wrote: > On Thu, Mar 1, 2012 at 9:54 AM, Mark Thomas wrote: > >> On 01/03/2012 17:13, Filip Hanik - Dev Lists wrote: >>> Mark, what buffer size are you referring to increase for the web socket >>> tests to all pass? >> >> Sorry, should have been clearer about that. >> >> In o.a.c.websocket.MessageInbound >> >>// 2MB - like maxPostSize >>private int byteBufferMaxSize = 2097152; >>private int charBufferMaxSize = 2097152; >> >> I normally multiple those by 16. The buffers need to be 16M plus a bit >> for the headers so I allow a large margin ;) >> > > I hope neither 2M or 16M will be allocated by default - that's the limit on > growth ? Yes. Hence the "max" in the name which would be clear if you had looked at the code. > I'm curious, did you do any load test - and what's the max number of > websocket connections that can be kept alive with APR/NIO ? No, not yet. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1295724 - in /tomcat/trunk/webapps/examples/WEB-INF: classes/websocket/EchoMessage.java web.xml
Author: fhanik
Date: Thu Mar 1 18:27:56 2012
New Revision: 1295724
URL: http://svn.apache.org/viewvc?rev=1295724&view=rev
Log:
Allow the examples to configure the buffer on the fly
Modified:
tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
tomcat/trunk/webapps/examples/WEB-INF/web.xml
Modified:
tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java?rev=1295724&r1=1295723&r2=1295724&view=diff
==
--- tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
(original)
+++ tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
Thu Mar 1 18:27:56 2012
@@ -20,6 +20,8 @@ import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
+import javax.servlet.ServletException;
+
import org.apache.catalina.websocket.MessageInbound;
import org.apache.catalina.websocket.StreamInbound;
import org.apache.catalina.websocket.WebSocketServlet;
@@ -28,13 +30,40 @@ import org.apache.catalina.websocket.Web
public class EchoMessage extends WebSocketServlet {
private static final long serialVersionUID = 1L;
+private volatile int byteBufSize;
+private volatile int charBufSize;
+
+@Override
+public void init() throws ServletException {
+super.init();
+byteBufSize = getInitParameterIntValue("byteBufferMaxSize", 2097152);
+charBufSize = getInitParameterIntValue("charBufferMaxSize", 2097152);
+}
+
+public int getInitParameterIntValue(String name, int defaultValue) {
+String val = this.getInitParameter(name);
+int result = defaultValue;
+try {
+result = Integer.parseInt(val);
+}catch (Exception x) {
+}
+return result;
+}
+
+
@Override
protected StreamInbound createWebSocketInbound(String subProtocol) {
-return new EchoMessageInbound();
+return new EchoMessageInbound(byteBufSize,charBufSize);
}
private static final class EchoMessageInbound extends MessageInbound {
+
+public EchoMessageInbound(int byteBufferMaxSize, int
charBufferMaxSize) {
+super();
+setByteBufferMaxSize(byteBufferMaxSize);
+setCharBufferMaxSize(charBufferMaxSize);
+}
@Override
protected void onBinaryMessage(ByteBuffer message) throws IOException {
Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1295724&r1=1295723&r2=1295724&view=diff
==
--- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original)
+++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Thu Mar 1 18:27:56 2012
@@ -359,6 +359,8 @@
wsEchoMessage
websocket.EchoMessage
+
byteBufferMaxSize20971520
+
charBufferMaxSize20971520
wsEchoMessage
-
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 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=1295724&view=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. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1295734 - /tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
Author: markt
Date: Thu Mar 1 18:49:38 2012
New Revision: 1295734
URL: http://svn.apache.org/viewvc?rev=1295734&view=rev
Log:
Remove trailing whitespace
Modified:
tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
Modified:
tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java?rev=1295734&r1=1295733&r2=1295734&view=diff
==
--- tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
(original)
+++ tomcat/trunk/webapps/examples/WEB-INF/classes/websocket/EchoMessage.java
Thu Mar 1 18:49:38 2012
@@ -32,14 +32,14 @@ public class EchoMessage extends WebSock
private static final long serialVersionUID = 1L;
private volatile int byteBufSize;
private volatile int charBufSize;
-
+
@Override
public void init() throws ServletException {
super.init();
byteBufSize = getInitParameterIntValue("byteBufferMaxSize", 2097152);
charBufSize = getInitParameterIntValue("charBufferMaxSize", 2097152);
}
-
+
public int getInitParameterIntValue(String name, int defaultValue) {
String val = this.getInitParameter(name);
int result = defaultValue;
@@ -58,7 +58,7 @@ public class EchoMessage extends WebSock
}
private static final class EchoMessageInbound extends MessageInbound {
-
+
public EchoMessageInbound(int byteBufferMaxSize, int
charBufferMaxSize) {
super();
setByteBufferMaxSize(byteBufferMaxSize);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1295735 - /tomcat/trunk/webapps/examples/WEB-INF/web.xml
Author: markt Date: Thu Mar 1 18:50:13 2012 New Revision: 1295735 URL: http://svn.apache.org/viewvc?rev=1295735&view=rev Log: Comment out AutoBahn required buffer increase by default Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml Modified: tomcat/trunk/webapps/examples/WEB-INF/web.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/examples/WEB-INF/web.xml?rev=1295735&r1=1295734&r2=1295735&view=diff == --- tomcat/trunk/webapps/examples/WEB-INF/web.xml (original) +++ tomcat/trunk/webapps/examples/WEB-INF/web.xml Thu Mar 1 18:50:13 2012 @@ -359,8 +359,19 @@ wsEchoMessage websocket.EchoMessage - byteBufferMaxSize20971520 - charBufferMaxSize20971520 + + wsEchoMessage - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 --- Comment #46 from Johno Crawford 2012-03-01 19:13:34 UTC --- Created attachment 28408 --> https://issues.apache.org/bugzilla/attachment.cgi?id=28408 Overrides for connection open and close I am currently working on an example for websockets. Please consider attached attachment for notifications when connection is opened / closed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: 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=1295724&view=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
svn commit: r1295768 - /tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
Author: fhanik
Date: Thu Mar 1 20:15:24 2012
New Revision: 1295768
URL: http://svn.apache.org/viewvc?rev=1295768&view=rev
Log:
https://issues.apache.org/bugzilla/show_bug.cgi?id=52804
Implement useful interfaces for storing and copying the properties
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
Modified:
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java?rev=1295768&r1=1295767&r2=1295768&view=diff
==
---
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
(original)
+++
tomcat/trunk/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/PoolProperties.java
Thu Mar 1 20:15:24 2012
@@ -19,6 +19,7 @@ package org.apache.tomcat.jdbc.pool;
import java.io.ByteArrayInputStream;
import java.io.IOException;
+import java.io.Serializable;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Map;
@@ -33,7 +34,7 @@ import org.apache.juli.logging.LogFactor
* @author Filip Hanik
*
*/
-public class PoolProperties implements PoolConfiguration {
+public class PoolProperties implements PoolConfiguration, Cloneable,
Serializable {
private static final Log log = LogFactory.getLog(PoolProperties.class);
public static final int DEFAULT_MAX_ACTIVE = 100;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1295770 - in /tomcat/tc7.0.x/trunk: modules/ webapps/docs/changelog.xml
Author: fhanik Date: Thu Mar 1 20:20:21 2012 New Revision: 1295770 URL: http://svn.apache.org/viewvc?rev=1295770&view=rev Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=52804 Modified: tomcat/tc7.0.x/trunk/modules/ (props changed) tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/modules/ -- --- svn:externals (original) +++ svn:externals Thu Mar 1 20:20:21 2012 @@ -1 +1 @@ -^/tomcat/trunk/modules/jdbc-pool@1244927 jdbc-pool +^/tomcat/trunk/modules/jdbc-pool@1295768 jdbc-pool Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1295770&r1=1295769&r2=1295770&view=diff == --- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original) +++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Thu Mar 1 20:20:21 2012 @@ -85,6 +85,13 @@ + + + +52804: Make pool properties serializable and cloneable (fhanik) + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52804] Make PoolProperties implement Cloneable.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52804 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Filip Hanik 2012-03-01 20:20:38 UTC --- Fixed in trunk in r1295768 Fixed in 7.0.x in r1295770 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Publishing taglibs mini-site
euh as there isn't any distributionManagement-> site
this will go no where
Maybe do as I have done for the maven plugin see
http://tomcat.apache.org/maven-plugin.html
so versionned documentation is published.
http://tomcat.apache.org/maven-plugin-${project.version}
Pom content:
apache.website
${distributionSiteUrl}
with
scp://people.apache.org/www/tomcat.apache.org/maven-plugin-${project.version}
I use a property for testing purpose. Doing something like
-DdistributionSiteUrl=scp://people.apache.org/home/jboynes/public_html/taglib
As it you can see it in live http://people.apache.org/~jboynes/taglib
HTH,
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
2012/3/1 Jeremy Boynes :
> Is there any information lying around on how to update the taglibs site?
>
> Is taglibs-parent/site.xml actually used or is everything in the site module?
>
> What's the process for publishing? Where does it deploy to? Is a vote needed
> before push? Do we want to preview changes online or is a review based on
> local build enough?
>
> Thanks
> Jeremy
>
>
> -
> 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
[Tomcat Wiki] Update of "PageD'Accueil" by Roger Mbiama
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "PageD'Accueil" page has been changed by Roger Mbiama: http://wiki.apache.org/tomcat/PageD%27Accueil?action=diff&rev1=1&rev2=2 ## For more information, please see MoinMaster:MoinPagesEditorGroup. ## Merci de n'éditer les pages systèmes et d'aide QUE sur MoinMaster ! ## Pour plus d'information, consultez MoinMaster:MoinPagesEditorGroup. - ##master-page:FrontPage + ##master-page:Auth: [http://localhost:8080/host-manager/html/add?org.apache.catalina.filters.CSRF_NONCE=8E125BADDC7EF6E514C6B06138B895DF] - ##master-date:2004-12-02 00:47:10 + ##master-date:2012-03-01 00:47:10 #format wiki #language fr #pragma section-numbers off @@ -31, +31 @@ Pour en savoir plus sur ce qu'est un [:WikiWikiWebVF: WikiWikiWeb], lisez MoinMoin:WhyWikiWorks et MoinMoin:WikiNature. Vous pouvez également consulter la MoinMoin:WikiWikiWebFaq. Ce site utilise le moteur [:MoinMoinVF: MoinMoin]. + == Managing Tomcat == + For security, access to the manager webapp is restricted. Users are defined in: + $CATALINA_HOME/conf/tomcat-users + In Tomcat 7.0 access to the manager application is split between different users. + $CATALINA_HOME/RUNNING.text + http://localhost:8080/manager/status?org.apache.catalina.filters.CSRF_NONCE=7F004F6531785E6DD588EF4B8C70012C - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/2800 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1295768 Blamelist: fhanik BUILD FAILED: failed compile_1 sincerely, -The Buildbot
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(SocketWrapper socket,
Processor 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
UpgradeProcessor {
@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 commands, e-mail: dev
svn commit: r1295978 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11NioProtocol.java upgrade/UpgradeNioProcessor.java
Author: fhanik
Date: Thu Mar 1 23:05:51 2012
New Revision: 1295978
URL: http://svn.apache.org/viewvc?rev=1295978&view=rev
Log:
Fix WebSocket's non blocking call
http://tomcat.markmail.org/thread/drj7zgq2csfdnvoh#query:+page:1+mid:y4dheqpm2wx5xzba+state:results
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=1295978&r1=1295977&r2=1295978&view=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(SocketWrapper socket,
Processor 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=1295978&r1=1295977&r2=1295978&view=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
buildbot success in ASF Buildbot on tomcat-trunk
The Buildbot has detected a restored build on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/2801 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1295978 Blamelist: fhanik Build succeeded! sincerely, -The Buildbot
Re: svn commit: r1295978 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11NioProtocol.java upgrade/UpgradeNioProcessor.java
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=1295978&view=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=1295978&r1=1295977&r2=1295978&view=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(SocketWrapper socket,
Processor 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=1295978&r1=1295977&r2=1295978&view=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
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=1295978&view=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=1295978&r1=1295977&r2=1295978&view=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(SocketWrapper socket,
Processor 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=1295978&r1=1295977&r2=1295978&view=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
svn commit: r1295998 - /tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
Author: fhanik Date: Thu Mar 1 23:46:09 2012 New Revision: 1295998 URL: http://svn.apache.org/viewvc?rev=1295998&view=rev Log: Fix access to poller registration Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.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=1295998&r1=1295997&r2=1295998&view=diff == --- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java (original) +++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java Thu Mar 1 23:46:09 2012 @@ -253,11 +253,7 @@ public class Http11NioProtocol extends A // - this is comet request // - the request line/headers have not been completely //read -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()); } } - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
buildbot failure in ASF Buildbot on tomcat-trunk
The Buildbot has detected a new failure on builder tomcat-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-trunk/builds/2802 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/trunk] 1295998 Blamelist: fhanik BUILD FAILED: failed compile_1 sincerely, -The Buildbot
DO NOT REPLY [Bug 51181] Add support for Web Sockets
https://issues.apache.org/bugzilla/show_bug.cgi?id=51181 --- Comment #47 from Johno Crawford 2012-03-02 01:57:32 UTC --- (In reply to comment #46) > Created attachment 28408 [details] > Overrides for connection open and close > > I am currently working on an example for websockets. Please consider attached > attachment for notifications when connection is opened / closed. onOpen is not quite in the right place as write can be called before the sockets / streams have been set (callback happens in setUpgradeOutbound..). Can we modify the UpgradeInbound interface to include onUpgradeComplete? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-validate (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 16 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on checkstyle exists, no need to add for property checkstyle.jar. -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build) Work ended in a state of : Failed Elapsed: 32 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar -Dexecute.validate=true validate [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-02032012.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.3-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/exec/target/commons-exec-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/validator/dist/commons-validator-02032012.jar:/srv/gump/public/workspace/junit/dist/junit-02032012.jar:/srv/gump /public/workspace/junit/dist/junit-dep-02032012.jar:/srv/gump/public/workspace/google-guava/build/dist/guava-02032012/guava-02032012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-02032012.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-02032012.jar:/srv/gump/public/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/jdom/build/jdom.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-02032012.jar:/srv/gump/public/workspace/velocity-engine/bin/velocity-02032012-dep.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml download-validate: proxyflags: setproxy: testexist: [echo] Testing for /srv/gump/public/workspace/checkstyle/target/checkstyle-5.6-SNAPSHOT.jar downloadzip: validate: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle [checkstyle] Running Checkstyle 5.6-SNAPSHOT on 2225 files [checkstyle] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/coyote/http11/Http11NioProtocol.java:20:8: Unused import - java.nio.channels.SelectionKey. [checkstyle] /srv/gump/public/workspace/tomcat-trunk/java/org/apache/coyote/http11/Http11NioProtocol.java:34:8: Unused import - org.apache.tomcat.util.net.NioEndpoint.KeyAttachment. BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:444: Got 2 errors and 0 warnings. Total time: 32 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1202032012, vmgump.apache.org:vmgump:1202032012 Gump E-mail Identifier (unique within run) #19. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For addit
[GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-taglibs-standard has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-taglibs-standard : Standard Taglib - tomcat-taglibs-standard-install : JSP Taglibs Full details are available at: http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency taglibs-standard-spec failed with reason build failed -INFO- Optional dependency httpunit failed with reason build failed -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/tomcat-taglibs/standard/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/gump_work/build_tomcat-taglibs_tomcat-taglibs-standard.html Work Name: build_tomcat-taglibs_tomcat-taglibs-standard (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/tomcat-taglibs/standard/gump_mvn_settings.xml install [Working Directory: /srv/gump/public/workspace/tomcat-taglibs/standard] M2_HOME: /opt/maven2 - at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent: org.apache.taglibs:taglibs-parent for project: null:taglibs-standard:pom:1.2-SNAPSHOT for project null:taglibs-standard:pom:1.2-SNAPSHOT at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391) ... 12 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.taglibs:taglibs-parent' not found in repository: Unable to download the artifact from any repository org.apache.taglibs:taglibs-parent:pom:1-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2) for project org.apache.taglibs:taglibs-parent at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1392) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.taglibs:taglibs-parent:pom:1-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:228) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache
