Re: WebSocket progress report
On 29/01/2012 01:20, Costin Manolache wrote: > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas wrote: > > Not complaining - it's great to add this feature, please commit it - but > I'm wondering > if a lighter interface wouldn't be better. From looking at the > implementation, it seems > after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole > Request / Processor / etc tree ). I agree there is certainly scope to do that. My initial focus has been on functionality and minimal changes to existing code - hence the current approach. I'm not overly keen on the additional overhead myself and can see several ways to reduce it. Output is easier than input since we know the output buffers are clear on upgrade. Input is a little trickier since there may be some data in the input buffer and that would need to be drained before switching to the lighter weight approach. I think this is something to look at once the implementation is more feature complete. Whatever we do, I'd like to keep the following aims in mind: - minimal endpoint specific code - minimal changes to what we have now - keep the generic upgrade and the protocol specific parts separate > Would it be possible for example to release the Request, like it's done > after request, > in keep-alive, and use a lighter parser/callback on the socket ? I think > one of the use cases > for websockets is to support a _lot_ of open connections. That is certainly one approach. It will be easier to explore options when we have a wider range of examples to work / test with. > Also the interface may be simpler without InputStreams. I thought long and hard about that. Looking around, some implementations are message based, some are stream based. There are good arguments for both. Unfortunately the WebSocket protocol is a messages based protocol with no maximum message length. A message is one or more frames and a frame is up to 2^63 bytes. While most usages will be small(ish) messages that can be buffered without undue overhead, any application that wants larger messages needs to use a stream based interface to be able to scale. That is why I went for both. Thanks for the feedback. Much appreciated. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52235] Please do a bit of SEO tuning for the web site
https://issues.apache.org/bugzilla/show_bug.cgi?id=52235 --- Comment #11 from Pid 2012-01-29 11:15:42 UTC --- I've never seen this work immediately, it may take Google some time to resort the results. The Google Webmaster Tools site will allow an authorised user to monitor sitemap processing. http://www.google.com/webmasters/tools/ -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] New: scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549
Bug #: 52549
Summary: scanning HandlesTypes causes aggressive classloading
Product: Tomcat 7
Version: 7.0.25
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: costin.l...@gmail.com
Classification: Unclassified
I've ran into, what I would consider a bug, in Tomcat 7 when the web.xml
is 3.0 (or higher).
I assume based on the Servlet 3.0 spec, the WEB-INF/classes need to be
scanned but rather than doing bytecode parsing, Tomcat 7 does actual
class loading during the webapp initialization.
This change in semantics breaks applications that rely on bytecode enhancements
or processing (such as Spring's LoadTimeWeaver). Also any statics that are in
place get initialized way too early even if class itself might not get used.
Webapps that work on Tomcat 5.x-7.x (with web.xml 2.5) suddenly break on Tomcat
7 web.xml 3.0 due to the eager class loading.
I'd assume every app that does instrumentation (such as JPA providers) will
face
the same issue unless the whole VM is being instrumented which is quite
unfortunate and avoidable.
I'm using Tomcat 7.0.25.
The culprit seems to be ContextConfg#checkHandlesTypes(JavaClass) which could
postpone class loading:
// No choice but to load the class
String className = javaClass.getClassName();
...
clazz = context.getLoader().getClassLoader().loadClass(className);
...
// CL: no need to load the class for this
if (clazz.isAnnotation()) {
// Skip
return;
}
for (Map.Entry, Set> entry ...
There are a number of improvements to be applied here all just by looking at
the bytecode such as:
a. if the class is an annotation, skip it
b. if the class doesn't extend/implement any interface skip it
c. Look at the class hierarchy - this is actually quite easy (since
there's only one parent) and don't load it unless it implements
ServletContextListener
d. if there are no Servlet initializers, don't load any classes
e. if the class needs to be loaded use a throwaway classloader - that is
a clone CL of the real one which you can discard after scanning. Thus
you can do all the checks against a class but you can get rid of it at
the end. If the class is a match you can load it using the "proper"
class loader.
The problem with e) is that it's not really efficient especially in
terms of memory.
Loading all the classes (which can be quite a lot (10K+) in several
applications) to find one or two initializers seems like a bad trade-off
which unfortunately, also breaks compatibility.
I realize that the solutions above (especially e) seem complicated but
they aren't. I see you guys have used BCEL - if you were using ASM I
would have offered help.
Basically what I'm suggesting is to be a lot more careful in doing
loading and enforcing some basic rules which can go a long way. Also using a
cache (reusing data) for the entire scanning should speed things up
pretty well. Further more since you are already loading the bytecode,
doing additional checks will actually speed things up as it will avoid
class loading.
Case in point is traversing the class hierarchy: if the parent is in the
classpath, it will be scanned anyway and checking the interfaces
implemented is trivial. If this result is cached, all direct children
will be skipped right away.
Thanks,
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52326] Lower log level for failed class loading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52326 --- Comment #8 from Costin Leau 2012-01-29 11:33:15 UTC --- Another +1 regarding skipping class loading - it simply has too many bad side effects (including initializing static blocks way too early). See bug 52549 for more info. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549 Costin Leau changed: What|Removed |Added OS/Version||All --- Comment #1 from Costin Leau 2012-01-29 11:40:18 UTC --- Example bug report caused by the side effect of eager classloading in Tomcat 7: https://jira.springsource.org/browse/SPR-7440 Bug 52326 and bug 52444 touch on the same issue as well. P.S. I'm aware that metadata-complete="true" fixes the issue but it's actually a work-around not a fix. First it is false by default and not many users know about it, and second, it disables the use of annotations which means one can't use annotated ServletContainerInitializer. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Mark Thomas 2012-01-29 12:15:57 UTC --- *** This bug has been marked as a duplicate of bug 52444 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 Mark Thomas changed: What|Removed |Added CC||costin.l...@gmail.com --- Comment #2 from Mark Thomas 2012-01-29 12:15:57 UTC --- *** Bug 52549 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549 --- Comment #3 from Costin Leau 2012-01-29 14:26:45 UTC --- I'm not sure why this issue has been marked as a duplicate. This is not about long startup times or memory consumption, but rather unneeded class loading that simply breaks existing apps. Thus it's not about performance but semantics. -- 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 progress report
On 29 January 2012 10:19, Mark Thomas wrote: > On 29/01/2012 01:20, Costin Manolache wrote: >> On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas wrote: >> >> Not complaining - it's great to add this feature, please commit it - but >> I'm wondering >> if a lighter interface wouldn't be better. From looking at the >> implementation, it seems >> after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole >> Request / Processor / etc tree ). > > I agree there is certainly scope to do that. My initial focus has been > on functionality and minimal changes to existing code - hence the > current approach. > > I'm not overly keen on the additional overhead myself and can see > several ways to reduce it. Output is easier than input since we know the > output buffers are clear on upgrade. Input is a little trickier since > there may be some data in the input buffer and that would need to be > drained before switching to the lighter weight approach. > > I think this is something to look at once the implementation is more > feature complete. Whatever we do, I'd like to keep the following aims in > mind: > - minimal endpoint specific code > - minimal changes to what we have now > - keep the generic upgrade and the protocol specific parts separate > >> Would it be possible for example to release the Request, like it's done >> after request, >> in keep-alive, and use a lighter parser/callback on the socket ? I think >> one of the use cases >> for websockets is to support a _lot_ of open connections. > > That is certainly one approach. It will be easier to explore options > when we have a wider range of examples to work / test with. > >> Also the interface may be simpler without InputStreams. > > I thought long and hard about that. Looking around, some implementations > are message based, some are stream based. There are good arguments for > both. Unfortunately the WebSocket protocol is a messages based protocol > with no maximum message length. A message is one or more frames and a > frame is up to 2^63 bytes. While most usages will be small(ish) messages > that can be buffered without undue overhead, any application that wants > larger messages needs to use a stream based interface to be able to > scale. That is why I went for both. May I suggest that such design decisions are documented in the code and/or package Javadoc? > Thanks for the feedback. Much appreciated. > > 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: r1237332 - in /tomcat/trunk/java/org/apache/tomcat/util/bcel: Constants.java classfile/AccessFlags.java
Author: markt
Date: Sun Jan 29 16:38:45 2012
New Revision: 1237332
URL: http://svn.apache.org/viewvc?rev=1237332&view=rev
Log:
Restore some previously removed code that is required for fixing
BZ52444. Need to be able to determine if a class is an annotation
without loading the class.
Modified:
tomcat/trunk/java/org/apache/tomcat/util/bcel/Constants.java
tomcat/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/bcel/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/bcel/Constants.java?rev=1237332&r1=1237331&r2=1237332&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/bcel/Constants.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/bcel/Constants.java Sun Jan 29
16:38:45 2012
@@ -39,6 +39,10 @@ public interface Constants {
/** One of the access flags for fields, methods, or classes.
*/
+ public static final short ACC_ANNOTATION = 0x2000;
+
+ /** One of the access flags for fields, methods, or classes.
+ */
public static final short ACC_ENUM = 0x4000;
// Applies to classes compiled by new compilers only
Modified:
tomcat/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java?rev=1237332&r1=1237331&r2=1237332&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java
Sun Jan 29 16:38:45 2012
@@ -33,4 +33,10 @@ public abstract class AccessFlags implem
public AccessFlags() {
}
+/**
+ * @return Access flags of the object aka. "modifiers".
+*/
+public final int getAccessFlags() {
+return access_flags;
+}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237334 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Sun Jan 29 16:39:26 2012
New Revision: 1237334
URL: http://svn.apache.org/viewvc?rev=1237334&view=rev
Log:
No need to load class to determine if it is an annotation.
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1237334&r1=1237333&r2=1237334&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29
16:39:26 2012
@@ -2016,6 +2016,12 @@ public class ContextConfig implements Li
return;
}
+if ((javaClass.getAccessFlags() &
+org.apache.tomcat.util.bcel.Constants.ACC_ANNOTATION) > 0) {
+// Skip annotations.
+return;
+}
+
// No choice but to load the class
String className = javaClass.getClassName();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237336 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java java/org/apache/tomcat/util/bcel/Constants.java java/org/apache/tomcat/util/bcel/classfile/Acces
Author: markt Date: Sun Jan 29 16:43:45 2012 New Revision: 1237336 URL: http://svn.apache.org/viewvc?rev=1237336&view=rev Log: Restore some previously removed BCEL code that is required for fixing BZ52444. Use it to determine if a class is an annotation without loading the class. Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/bcel/Constants.java tomcat/tc7.0.x/trunk/java/org/apache/tomcat/util/bcel/classfile/AccessFlags.java tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Sun Jan 29 16:43:45 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129 0,1231308,1231310,1231337,1231460-1231461,1231542-1231543,1231546-1231547,1231620-1231621,1231624-1231625,1231630,1231654-1231655,1231738,1231740,1231762-1231763,1231856,1231886,1231923,1231947,1232345,1232
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 --- Comment #3 from Mark Thomas 2012-01-29 17:36:02 UTC --- Bringing across the list of suggestions from the duplicate... > a. if the class is an annotation, skip it Fixed in trunk and 7.0.x and will be included in 7.0.26 onwards. > b. if the class doesn't extend/implement any interface skip it Interesting. Thinking about this some more, the current isAssignableFrom() test is actually broader than it needs to be since it will return true for X.class.isAssignableFrom(X.class) and there is no need to add X to the initializerClassMap in this case. Apart from that however, isAssignableFrom() is the right test and that makes things a little more complicated to implement solely using byte code due to how the code currently iterates over the JARs (traversing the class hierarchy is the tricky part). Should be doable but likely to require a fair amount of re-factoring. > c. Look at the class hierarchy - this is actually quite easy (since > there's only one parent) and don't load it unless it implements > ServletContextListener This is not correct. HandlesType specify any class or interface. > d. if there are no Servlet initializers, don't load any classes The code already does this. > e. if the class needs to be loaded use a throwaway classloader If the class must be loaded to examine it yes, but hopefully it will be possible to avoid doing this. In summary, b) is the only remaining problem to solve. The solution looks like requiring caching all the javaClass instances and then doing the HandlesTypes processing (and then throwing away the cache). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549 --- Comment #4 from Mark Thomas 2012-01-29 17:45:17 UTC --- Just for the record, you appear to have missed the point of this code. The list of ServletContainerInitializer is obtained from META-INF/services/javax.servlet.ServletContainerInitializer within each JAR, not from scanning the classes and looking for classes that implement it. The scanning is only done if there is at least one ServletContainerInitializer that defines HandlesTypes and the scanning is looking for classes that extend or implement the classes/interfaces defined by HandlesTypes. Loading the class was a quick and dirty solution (that has survived longer than I thought it might) to determining if the class meets the extends or implements test. See the duplicate for my comments on your suggestions. Short version this is doable with some refactoring and next on my todo list. Feel free to change the duplicate to a bug if you wish. I'm not that bothered since it is getting fixed anyway. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52547] incorrect byeswritten log after completed async request under http1.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=52547 --- Comment #2 from David 2012-01-29 18:56:37 UTC --- Thank you Mark. Additionally, I think there is a "bug" in that the recycle() happens immediatley after the nextRequest() even when keepalive is true (I can see from an iptables log that the socket is not closed for another default 20 seconds). See the event(...), asyncDispatch(...) and service(...) methods in http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Basically response.recycle() (when called because not dealing with async part of the request) calls outputBuffer.recycle() immediatley response processing is finished rather than just before the socket is actually closed. So in an http/1.1 multi request-response (without a socket close) you still get both outputBuffer.nextRequest() and outputBuffer.recycle() called consecutvely at the end of each completed response process. I can see that nextRequest(), recycle() should both exist, but only if recycle() really only happens at socket close as it's descriptive comment says. Otherwise it would be a (very minor) optimization to remove the (nearlly always present) duplicate calls. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52545] Annotations are processed for servlet 2.4 applications
https://issues.apache.org/bugzilla/show_bug.cgi?id=52545 Eugene Petrenko changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Eugene Petrenko 2012-01-29 19:10:23 UTC --- I saw the code. Default value of the flag to ignore attributes is false. As parse code is never called, the value is false at the end (i.e. setter code was not called). What I did was to check with debugger that the option to scan annotation was not disabled for 2.4 application. To workaround the bug I had to upgrade to 2.5 and explicitly specify metadata-complete attribute with value="true" PS. Annotation scanning mechanism uses too much synchronizations and thus slows down the application. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52545] Annotations are processed for servlet 2.4 applications
https://issues.apache.org/bugzilla/show_bug.cgi?id=52545 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #3 from Mark Thomas 2012-01-29 19:12:28 UTC --- I tested this with a 2.4 app and no scanning was performed. If you can provide a webapp that triggers scanning on a clean 7.0.25 installation feel free to rte-open this. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52517] Server affecting URLConnector's defaultUseCache settings
https://issues.apache.org/bugzilla/show_bug.cgi?id=52517 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX OS/Version||All --- Comment #1 from Mark Thomas 2012-01-29 19:14:46 UTC --- This is by design to avoid memory leaks. The behaviour is configurable. See the docs for org.apache.catalina.core.JreMemoryLeakPreventionListener You are also able to change this per connection. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237424 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt Date: Sun Jan 29 19:29:11 2012 New Revision: 1237424 URL: http://svn.apache.org/viewvc?rev=1237424&view=rev Log: UCDetector. Add finals where appropriate Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java 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=1237424&r1=1237423&r2=1237424&view=diff == --- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original) +++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29 19:29:11 2012 @@ -188,14 +188,14 @@ public class ContextConfig implements Li /** * Map of ServletContainerInitializer to classes they expressed interest in. */ -protected Map>> initializerClassMap = +protected final Map>> initializerClassMap = new LinkedHashMap>>(); /** * Map of Types to ServletContainerInitializer that are interested in those * types. */ -protected Map, Set> typeInitializerMap = +protected final Map, Set> typeInitializerMap = new HashMap, Set>(); /** - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237425 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Sun Jan 29 19:29:50 2012
New Revision: 1237425
URL: http://svn.apache.org/viewvc?rev=1237425&view=rev
Log:
Deprecate unused/unnecessary code
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1237425&r1=1237424&r2=1237425&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29
19:29:50 2012
@@ -241,7 +241,9 @@ public class ContextConfig implements Li
/**
* Return the location of the default context file
+ * @deprecated Never changed from default
*/
+@Deprecated
public String getDefaultContextXml() {
if( defaultContextXml == null ) {
defaultContextXml=Constants.DefaultContextXml;
@@ -256,7 +258,9 @@ public class ContextConfig implements Li
* Set the location of the default context file
*
* @param path Absolute/relative path to the default context.xml
+ * @deprecated Unused
*/
+@Deprecated
public void setDefaultContextXml(String path) {
this.defaultContextXml = path;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237426 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Sun Jan 29 19:30:27 2012
New Revision: 1237426
URL: http://svn.apache.org/viewvc?rev=1237426&view=rev
Log:
Remove deprecated code
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1237426&r1=1237425&r2=1237426&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29
19:30:27 2012
@@ -240,35 +240,6 @@ public class ContextConfig implements Li
/**
- * Return the location of the default context file
- * @deprecated Never changed from default
- */
-@Deprecated
-public String getDefaultContextXml() {
-if( defaultContextXml == null ) {
-defaultContextXml=Constants.DefaultContextXml;
-}
-
-return (this.defaultContextXml);
-
-}
-
-
-/**
- * Set the location of the default context file
- *
- * @param path Absolute/relative path to the default context.xml
- * @deprecated Unused
- */
-@Deprecated
-public void setDefaultContextXml(String path) {
-
-this.defaultContextXml = path;
-
-}
-
-
-/**
* Sets custom mappings of login methods to authenticators.
*
* @param customAuthenticators Custom mappings of login methods to
@@ -519,7 +490,7 @@ public class ContextConfig implements Li
}
// set the default if we don't have any overrides
if( defaultContextXml==null ) {
-getDefaultContextXml();
+defaultContextXml = Constants.DefaultContextXml;
}
if (!context.getOverride()) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237427 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt Date: Sun Jan 29 19:31:05 2012 New Revision: 1237427 URL: http://svn.apache.org/viewvc?rev=1237427&view=rev Log: Deprecate code that is going to be removed Modified: tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java 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=1237427&r1=1237426&r2=1237427&view=diff == --- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original) +++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29 19:31:05 2012 @@ -163,7 +163,9 @@ public class ContextConfig implements Li /** * The default web application's context file location. + * @deprecated Unnecessary */ +@Deprecated protected String defaultContextXml = null; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237428 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
Author: markt
Date: Sun Jan 29 19:31:42 2012
New Revision: 1237428
URL: http://svn.apache.org/viewvc?rev=1237428&view=rev
Log:
Remove deprecated code
Modified:
tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
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=1237428&r1=1237427&r2=1237428&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java (original)
+++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan 29
19:31:42 2012
@@ -162,14 +162,6 @@ public class ContextConfig implements Li
/**
- * The default web application's context file location.
- * @deprecated Unnecessary
- */
-@Deprecated
-protected String defaultContextXml = null;
-
-
-/**
* The default web application's deployment descriptor location.
*/
protected String defaultWebXml = null;
@@ -486,12 +478,14 @@ public class ContextConfig implements Li
*/
protected void contextConfig(Digester digester) {
+String defaultContextXml = null;
+
// Open the default context.xml file, if it exists
-if( defaultContextXml==null && context instanceof StandardContext ) {
+if (context instanceof StandardContext) {
defaultContextXml =
((StandardContext)context).getDefaultContextXml();
}
// set the default if we don't have any overrides
-if( defaultContextXml==null ) {
+if (defaultContextXml == null) {
defaultContextXml = Constants.DefaultContextXml;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1237431 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/startup/ContextConfig.java
Author: markt Date: Sun Jan 29 19:34:45 2012 New Revision: 1237431 URL: http://svn.apache.org/viewvc?rev=1237431&view=rev Log: Deprecate code that has been removed in 8.0.x Modified: tomcat/tc7.0.x/trunk/ (props changed) tomcat/tc7.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java Propchange: tomcat/tc7.0.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Sun Jan 29 19:34:45 2012 @@ -1 +1 @@ -/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,1157908,1157939,1158155,1158160,1158176,1158195,1158198-1158199,1158227,1158331,1158334-1158335,1158426,1160347,1160592,1160611,1160619,1160626,1160639,1160652,1160720-1160721,1160772,1160774,1160776,1161303,1161310,1161322,1161339,1161486,1161540,1161549,1161584,1162082,1162149,1162169,1162721,1162769,1162836,1162932,1163630,1164419,1164438,1164469,1164480,1164567,1165234,1165247-1165248,1165253,1165273,1165282,1165309,1165331,1165338,1165347,1165360-1165361,1165367-1165368,1165602,1165608,1165677,1165693,1165721,1165723,1165728,1165730,1165738,1165746,1165765,1165777,1165918,1165921,1166077,1166150-1166151,1166290,1166366,1166620,1166686,1166693,1166752,1166757,1167368,1167394,1169447,1170647,1171692,1172233-1172234,1172236,1172269,1172278,1172282,1172556,1172610,1172664,1172689,1172711,1173020-1173021,1173082,1173088,1173090,1173096 ,1173241,1173256,1173288,117,1173342,1173461,1173614,1173630,1173659,1173722,1174061,1174239,1174322,1174325,1174329-1174330,1174337-1174339,1174343,1174353,1174799,1174882,1174884,1174975,1174983,1175155,1175158,1175167,1175182,1175190,1175201,1175272,1175275,1175283,1175582,1175589-1175590,1175594,1175602,1175613,1175633,1175690,1175713,1175798,1175889,1175896,1175907,1176584,1176590,1176799,1177050,1177060,1177125,1177152,1177160,1177245,1177850,1177862,1177978,1178209,1178228,1178233,1178449,1178542,1178681,1178684,1178721,1179268,1179274,1180261,1180865,1180891,1180894,1180907,1181028,1181123,1181125,1181136,1181291,1181743,1182796,1183078,1183105,1183142,1183328,1183339-1183340,1183492-1183494,1183605,1184917,1184919,1185018,1185020,1185200,1185588,1185626,1185756,1185758,1186011,1186042-1186045,1186104,1186123,1186137,1186153,1186254,1186257,1186377-1186379,1186479-1186480,1186712,1186743,1186750,1186763,1186890-1186892,1186894,1186949,1187018,1187027-1187028,1187 381,1187753,1187755,1187775,1187801,1187806,1187809,1187827,1188301,1188303-1188305,1188399,1188822,1188930-1188931,1189116,1189129,1189183,1189240,1189256,1189386,1189413-1189414,1189477,1189685,1189805,1189857,1189864,1189882,1190034,1190185,1190279,1190339,1190371,1190388-1190389,1190474,1190481,1194915,1195222-1195223,1195531,1195899,1195905,1195943,1195949,1195953,1195955,1195965,1195968,1196175,1196212,1196223,1196304-1196305,1196735,1196825,1196827,1197158,1197261,1197263,1197299-1197300,1197305,1197339-1197340,1197343,1197382,1197386-1197387,1197480,1197578,1198497,1198528,1198552,1198602,1198604,1198607,1198622,1198640,1198696,1198707,1199418,1199432,1199436,1199513,1199529,1199980,116,1200056,1200089,1200106-1200107,1200263,1200316,1200320,1200398-1200399,1200445-1200446,1200555,1200627,1200696,1200725,1200937,1200941,1201069,1201087,1201180,1201235-1201237,1201508,1201521,1201542,1201545-1201546,1201548,1201555-1201556,1201568,1201576,1201608,1201921-1201922,1 201931,1202035,1202039,1202271,1202565,1202578,1202705,1202828,1202860,1203047-1203052,1203078,1203091,1203253,1203278,1204182,1204856,1204867,1204936,1204938,1204982,1205033,1205065,1205082,1205097,1205112,1206200,1207692,1208046,1208073,1208096,1208114,1208145,1208772,1209194,1209277-1209278,1209686-1209731,1210894,1212091,1212095,1212099,1212118,1213469,1213906,1214853,1214855,1214864,1215115,1215118-1215119,1215121,1220293,1220295,1221038,1221842,1222189,101,176,1222300,1222690,1222850,1222852,1222855,1224607,1224617,1224648-1224652,1224657,1224662-1224663,1224682,1224801,1224910,1225000,1225219,1225343,1225465,1225627,1225629,1225634,1226069,1226158-1226159,1226177,1226196,1226214-1226215,1226385,1226394,1226500,1226537-1226538,1226546,1226551,1226975,1228196,1228360,1228376,1228724,1228908,1228918,1228920,1228922,1228929,1228969,1229307,1229536,1229549,1229724,1229726-1229731,1229997,1230539,1230711,1230729,1230762-1230763,1230765,1230955,1230957,1231285,123129 0,1231308,1231310,1231337,1231460-1231461,1231542-1231543,1231546-1231547,1231620-1231621,1231624-1231625,1231630,1231654-1231655,1231738,1231740,1231762-1231763,1231856,1231886,1231923,1231947,1232345,1232368,1232380,1232447,1232760,1232813,1232842-1232843,1232869,1233413,1233423,1233426,1234143,1234567,1235207,1236906-1236907,1236914,1237146,1237154-1237156,1237332,1237334 +/tomcat/trunk:1156115,1156171,1156276,1156304,1156519,1156530,1156602,1157015,1157018,1157151,1157198,1157204,1157810,1157832,1157834,1157847,11579
Re: svn commit: r1237428 - /tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
2012/1/29 :
> Author: markt
> Date: Sun Jan 29 19:31:42 2012
> New Revision: 1237428
>
> URL: http://svn.apache.org/viewvc?rev=1237428&view=rev
> Log:
> Remove deprecated code
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
>
1. The mbeans-descriptors.xml file there still lists the
"defaultContextXml" property that you removed. [1]
2. Overall this feels like removing a feature.
I woudn't veto as I never used it and I do not have strong evidence,
but I am -0.
I think it might have the same use as ContextConfig#defaultWebXml
(used by tests and by embedding code). Something like specifying
different defaults file for embedded use.
Neither "defaultContextXml" nor "defaultWebXml" are documented in
config/context.html.
[1]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/startup/mbeans-descriptors.xml?view=markup
Best regards,
Konstantin Kolinko
>
> 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=1237428&r1=1237427&r2=1237428&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/startup/ContextConfig.java Sun Jan
> 29 19:31:42 2012
> @@ -162,14 +162,6 @@ public class ContextConfig implements Li
>
>
> /**
> - * The default web application's context file location.
> - * @deprecated Unnecessary
> - */
> - @Deprecated
> - protected String defaultContextXml = null;
> -
> -
> - /**
> * The default web application's deployment descriptor location.
> */
> protected String defaultWebXml = null;
> @@ -486,12 +478,14 @@ public class ContextConfig implements Li
> */
> protected void contextConfig(Digester digester) {
>
> + String defaultContextXml = null;
> +
> // Open the default context.xml file, if it exists
> - if( defaultContextXml==null && context instanceof StandardContext ) {
> + if (context instanceof StandardContext) {
> defaultContextXml =
> ((StandardContext)context).getDefaultContextXml();
> }
> // set the default if we don't have any overrides
> - if( defaultContextXml==null ) {
> + if (defaultContextXml == null) {
> defaultContextXml = Constants.DefaultContextXml;
> }
>
>
>
>
> -
> 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: DO NOT REPLY [Bug 52543] Exception
On 27/01/2012 17:37, Pid wrote: > On 27/01/2012 15:18, sebb wrote: >> On 27 January 2012 13:38, wrote: >>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52543 >>> >>> Pid changed: >>> >>> What|Removed |Added >>> >>> Status|NEW |RESOLVED >>> Resolution||INVALID >>> >>> --- Comment #1 from Pid 2012-01-27 13:38:11 UTC --- >>> Bugzilla is not a support forum. Please join the Tomcat Users mailing list >>> and >>> ask your question there. >> >> In this case, AFAICT the Exception is deep in Tomcat code. >> >> It looks to be an error that should not happen, regardless of what the >> application is doing. >> >> Or at least, if the application is doing something wrong, the >> exception is not helpful. >> >> IMO, not (directly) a user error - seems unfair to close as such. > > I would happily assist on users list & reopen if so. I stand corrected. :) p -- [key:62590808] signature.asc Description: OpenPGP digital signature
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 --- Comment #4 from Costin Leau 2012-01-29 21:37:58 UTC --- Thanks for looking at this Mark. The more classes can be eliminated from loading, the better. Cheers! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52549] scanning HandlesTypes causes aggressive classloading
https://issues.apache.org/bugzilla/show_bug.cgi?id=52549 --- Comment #5 from Costin Leau 2012-01-29 21:47:04 UTC --- You're right, I mixed the various types that trigger/are part of the scanning process but hopefully my suggestions (to try to eliminate loading by looking at the class content/dependencies inferred from the configuration) were understood. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 --- Comment #5 from Pid 2012-01-29 21:51:17 UTC --- > In summary, b) is the only remaining problem to solve. The solution looks like > requiring caching all the javaClass instances and then doing the HandlesTypes > processing (and then throwing away the cache). I was looking at using the bcel.util.SyntheticRepository when you fixed the annotations... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 --- Comment #6 from Mark Thomas 2012-01-29 22:05:05 UTC --- (In reply to comment #5) > I was looking at using the bcel.util.SyntheticRepository when you fixed the > annotations... That would work but you'd need an additional cache to save you parsing the interface hierarchy every time. I'm currently working on a custom cache. Should have something for tomorrow. -- 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 progress report
On Sun, Jan 29, 2012 at 2:19 AM, Mark Thomas wrote: > On 29/01/2012 01:20, Costin Manolache wrote: > > On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas wrote: > > > > Not complaining - it's great to add this feature, please commit it - but > > I'm wondering > > if a lighter interface wouldn't be better. From looking at the > > implementation, it seems > > after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole > > Request / Processor / etc tree ). > > I agree there is certainly scope to do that. My initial focus has been > on functionality and minimal changes to existing code - hence the > current approach. > > I'm not overly keen on the additional overhead myself and can see > several ways to reduce it. Output is easier than input since we know the > output buffers are clear on upgrade. Input is a little trickier since > there may be some data in the input buffer and that would need to be > drained before switching to the lighter weight approach. > I don't think the upgrade protocol allows clients to send payload before receiving the response headers / handshaking, so I think it wouldn't be a problem. In terms of actual code changes - I think the main problem is that nio/apr/oio input/output are implemented in Internal[Input/Output][Nio/Apr]Buffer which are quite heavy- it would be a huge change to modify that. However it may be possible to have some lighter buffers - just the socket and methods to read/write. At least that's what I've been trying with spdy - which also involves some protocol switching. The change is also minimal in endpoint-specific code ( it's just adding few hooks and some new code ). I think this is something to look at once the implementation is more > feature complete. Whatever we do, I'd like to keep the following aims in > mind: > - minimal endpoint specific code > - minimal changes to what we have now > - keep the generic upgrade and the protocol specific parts separate > I agree. > > > Would it be possible for example to release the Request, like it's done > > after request, > > in keep-alive, and use a lighter parser/callback on the socket ? I think > > one of the use cases > > for websockets is to support a _lot_ of open connections. > > That is certainly one approach. It will be easier to explore options > when we have a wider range of examples to work / test with. > > > Also the interface may be simpler without InputStreams. > > I thought long and hard about that. Looking around, some implementations > are message based, some are stream based. There are good arguments for > both. Unfortunately the WebSocket protocol is a messages based protocol > with no maximum message length. A message is one or more frames and a > frame is up to 2^63 bytes. While most usages will be small(ish) messages > that can be buffered without undue overhead, any application that wants > larger messages needs to use a stream based interface to be able to > scale. That is why I went for both. > Well, the message is sent from javascript - I don't think 2^63 frames are likely, and even if they are, I don't think a blocking InputStream interface is best choice. Why not copy some of the javascript interface ( onopen / onmessage / etc ) ? Or onMessage(byte[] initialData) + onMessageData(byte[] moreBytes) ? In other words - make it 'async' from start. I wouldn't even worry about the string conversions for text frames in a low-level interface. Costin > > Thanks for the feedback. Much appreciated. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: WebSocket progress report
On 29/01/2012 22:49, Costin Manolache wrote: > On Sun, Jan 29, 2012 at 2:19 AM, Mark Thomas wrote: > >> On 29/01/2012 01:20, Costin Manolache wrote: >>> On Fri, Jan 27, 2012 at 3:09 PM, Mark Thomas wrote: >>> >>> Not complaining - it's great to add this feature, please commit it - but >>> I'm wondering >>> if a lighter interface wouldn't be better. From looking at the >>> implementation, it seems >>> after the upgrade it keeps the InputBuffer/OutputBuffer ( and the whole >>> Request / Processor / etc tree ). >> >> I agree there is certainly scope to do that. My initial focus has been >> on functionality and minimal changes to existing code - hence the >> current approach. >> >> I'm not overly keen on the additional overhead myself and can see >> several ways to reduce it. Output is easier than input since we know the >> output buffers are clear on upgrade. Input is a little trickier since >> there may be some data in the input buffer and that would need to be >> drained before switching to the lighter weight approach. >> > > I don't think the upgrade protocol allows clients to send payload before > receiving the response > headers / handshaking, so I think it wouldn't be a problem. Good point. I thought I was seeing data arriving earlier than that but what you says makes sense. I'll need to go back and double check exactly what I was seeing. > In terms of actual code changes - I think the main problem is that > nio/apr/oio > input/output are implemented in Internal[Input/Output][Nio/Apr]Buffer which > are > quite heavy- it would be a huge change to modify that. However it may be > possible > to have some lighter buffers - just the socket and methods to read/write. > At least that's what I've been trying with spdy - which also involves some > protocol switching. > The change is also minimal in endpoint-specific code ( it's just adding few > hooks and some new code ). Agree the lightweight buffers are the way to go. >>> Also the interface may be simpler without InputStreams. >> >> I thought long and hard about that. Looking around, some implementations >> are message based, some are stream based. There are good arguments for >> both. Unfortunately the WebSocket protocol is a messages based protocol >> with no maximum message length. A message is one or more frames and a >> frame is up to 2^63 bytes. While most usages will be small(ish) messages >> that can be buffered without undue overhead, any application that wants >> larger messages needs to use a stream based interface to be able to >> scale. That is why I went for both. >> > > Well, the message is sent from javascript - I don't think 2^63 frames are > likely, > and even if they are, I don't think a blocking InputStream interface is > best choice. Blocking was simpler to implement. As I think I said earlier in this thread, non-blocking is a possible enhancement - if there is interest - but it isn't my focus right now. Also at the back of my mind is a preference that this works with BIO as it isn't clear to me at this point what the Servlet spec is going to end up saying about web socket support and I'd rather not end up in the position where using BIO meant non-spec compliance. There are a lot of unknowns there so this may end up being an unnecessary restriction. Overall, it is early days for WebSocket so I may end up being completely wrong about a lot of this. We'll see how things evolve. > Why not copy some of the javascript interface ( onopen / onmessage / etc ) > ? The interface isn't complete yet. What you describe is not a million miles from what I expect the Message based interface will end up looking like. That said, it appears from reading the protocol and various blogs around it that the folks that wrote it had all sorts of weird and wonderful clients in mind for this and that has certainly influenced the protocol design. If all clients were JavaScript the protocol would look very different (and the server side would be a whole lot easier to implement). I am trying to keep the options open rather than impose arbitrary limits on things to make a particular interface viable. > Or onMessage(byte[] initialData) + onMessageData(byte[] moreBytes) ? > In other words - make it 'async' from start. I wouldn't even worry about > the > string conversions for text frames in a low-level interface. What I have so far is also influenced by what other containers are doing with a view to getting some form of convergence. I think all the containers are taking the view that their current API is a starting point and things are likely to change a lot. How they change will (hopefully) be driven by user demand. We'll see where we end up. Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 52444] Classloading-based ServletContainerInitializer @HandlesTypes processing can result in long startup times
https://issues.apache.org/bugzilla/show_bug.cgi?id=52444 --- Comment #7 from Mark Thomas 2012-01-29 23:23:15 UTC --- I think I have a patch for this. The unit tests pass but I want to run the TCK as well before I commit anything. That'll be tomorrow at the earliest now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Apache Tomcat Maven plugin 2.0-beta-1
Hello, After the usual 72H vote time, it's still missing 2 binding votes. As this release has new awaited features, I wonder if some PMCs could have a look and push a +1. IMHO a lot of users will be happy with a releasing containing the tomcat7 support and the other feature (executable jar/war). Thanks! -- Olivier 2012/1/27 Russ Tremain : > +1 > > thanks for your work! > -Russ > > At 7:05 PM +0100 1/26/12, Olivier Lamy wrote: >>Hi, >> >>I'd like to release the Apache Tomcat Maven plugin 2.0-beta-1. >> >>The staging repository is available here: >>https://repository.apache.org/content/repositories/orgapachetomcat-142/ >>The documentation site is available here: >>http://tomcat.apache.org/maven-plugin-2.0-beta-1/ >> >>Changelog: http://tomcat.apache.org/maven-plugin-2.0-beta-1/jira-report.html >> >>Guide to test a staged release maven plugin: >>http://maven.apache.org/guides/development/guide-testing-releases.html >>. >> >>[+1] >>[ 0] >>[-1] >> >>Here my +1 >> >>Thanks >>-- >>Olivier Lamy >>Talend: http://coders.talend.com >>http://twitter.com/olamy | http://linkedin.com/in/olamy >> >>- >>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
