Re: Single error page for multiple web applications
On Dec 31, 2013 3:15 AM, "Maarten van Hulsentop" wrote: > > Hello, > > We are using Tomcat to host a number of web applications as a uniform > solution. We trying to implement something that seems to be an odd > requirement, evh it is really a use case for us. > > We would like to define a single [default] error page for all web > applications residing on this Tomcat instance. After some experimentation > and googling around, it seems that there is no clear-cut solution for this. > I see a few options; > > - Let the global conf/web.xml define error pages for all web applications > at once. However these are always relative to the web application context, > and require every web application to pack the error pages again, which is a > duplicate of resources and defeats the DRY principle. I asked a question similar to this a while back regarding JSF templates. If you pick a location to share this resource among all web apps, then your web apps aren't self contained. The solution is in your build / deploy process. If you want to ignore that advice, Tomcat 8 now has webAppMount, if want to go there. I still haven't had a chance to explore that option. Leo
max_packet_size for data in mod_jk
Due to large payloads, we wanted to increase the max_packet size of the
mod_jk/ajp layer in order to see if it will help with performance. However,
it appears the max_packet_size for non- header requests is capped at 8192
bytes despite the documentation stating that it should be 65536. I am using
mod_jk version 1.2.31
[Tue Dec 31 11:54:09 2013][12492:12640] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1145): sending to ajp13
pos=4 len=8192 max=16384
Here is some code from jk_ajp_common.c that sets the max size but appears to
ignore the max_packet_size...
Line 1708: if (ae->left_bytes_to_send > 0) {
int len = AJP13_MAX_SEND_BODY_SZ;
if (ae->left_bytes_to_send <
(jk_uint64_t)AJP13_MAX_SEND_BODY_SZ) {
len = (int)ae->left_bytes_to_send;
}
Any help would be much appreciated.
--
View this message in context:
http://tomcat.10.x6.nabble.com/max-packet-size-for-data-in-mod-jk-tp5009929.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Chris, there's nothing to debate: the standard says svgz's need Content-Encoding: gzip so thats what we have to do. At this rate, we'll never get the Internet finished by Easter... Happy New Year, DaveLaw On 31/12/2013 15:23, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 12/31/13, 2:52 AM, David Law wrote: these are 2 completely different issues. svgz's should be served with the correct encoding (gzip) as required by the W3C SVG standard. ALWAYS. http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers That means, files with the extension .svgz will be served, as they are, with the Content-Encoding header gzip. This is performance-neutral. The "correct" encoding is debatable: one can argue that web servers shouldn't be adding the Content-Encoding:gzip to resources that the server itself did not gzip. If web servers were to take .gz files from the disk and set Content-Encoding:gzip, then the client would decompress the data upon receipt instead of storing the compressed bytes sent by the server originally. That has the effect of mutating the original resource form the perspective of the client. In this case, the SVG standard is asking "SVG servers" (presumably distinct from "web servers") to behave differently than originally expected. I think there's some wiggle-room here and its not as black-and-white as you propose. "The Patch" is something completely different: it serves a file with a particular extension, say *.XXX, from *.XXX.gz, if present. SOMETIMES (depending on the Servlet gzip-parameter). This will add a certain overhead, server-side, for EVERY FILE served. (because "if present" implies a resources lookup) True, but irrelevant. This is no different from serving any file from a web server. svgz's have the extension .svgz, not .svg.gz or .svgz.gz or anything else for that matter, so "The Patch" will not have any effect, and should not, for that matter. The extension is not terribly relevant, other than its what you chose to check for. In order to serve .svgz files in the way you want, a simple Filter can be used -- and markt already gave you the code to do so. Your original message said "Any chance of getting this [feature] at long last?" You make it seem like Tomcat is refusing to implement some crucial capability hat only the container can provide. This is not true for two reasons: first, it is not necessary for Tomcat to implement this - it can be done trivially by the web application; second, there is already a component in Tomcat that can be used to do this (bug 54095) with a bit of a tweak -- looking for filenames other than "*.gz". In your case, it probably makes sense to simply use Mark's Filter until the Tomcat committers decide what to do about this case. Perhaps an "example Filter" is the best thing to do here since it's a fairly specific use case and definitely would result in surprising behavior to many people if used by default. It's also clear there is room for improvement to Philippe's initial patch. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF 6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02 oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6 WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS FGKrbQ7zojR3wVHhGGlH =WjKV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the acceptCount attribute not work like it's configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/12/2013 14:43, Christopher Schultz wrote: > Mark, > > On 12/31/13, 6:11 AM, Mark Thomas wrote: >> On 31/12/2013 09:42, 侯树成 wrote: >>> Oh, everything is default in server.xml except Connector >>> configuration. > >> Yes, I can read thanks. > >>> "I have already explained how maxConnections is enforced by >>> Tomcat." Where? When? I'm sorry, I havn't know it. > >> You replied to my explanation so I suggest you go back and >> re-read the thread for your previous question. > >>> "the configuration of the client (number of threads, timeouts, >>> etc.) " --> just need a simple web app, in the servlet you >>> can sleep 60s. > >> None of which answers my questions about the client >> configuration. > > You might want to take a look at 侯树成's previous message under a > different thread where he gives some details about server behavior > which sounds odd to me: > > http://markmail.org/message/zvmxuagop7xiqinm I have looked at it and, again, the expected behaviour depends on the client configuration which has yet to be provided. I do not intend wasting my time reverse engineering possible client configurations (threads, requests per thread, timeouts, etc) that could lead to the stated results. The OP needs to provide the requested information. I'll add that the longer they drag their feet that the more likely my response is going to be "working as designed" rather than a full explanation. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSwtz2AAoJEBDAHFovYFnnSYkP/iWsuQ3PpjGaeV39aZIsbVJH HipTHfXU2dplPS5mag4Pp+m/HBnSK8LBAnERng54QEzJO28P7S3Ma7umZCvP0fWf 4usGDBs9fYauRXUNMUijMMY+9vaTc04e06tIUNPrR1dJnFwMnR2c8MBZn1APbD1d P4QNBultCUBoLy2B/wB4eahlqWkCc6ferdE75jBlNdux8IOnEYA6kW0NnEWg9UbD 1mkh9do4PBXcqza50RRg5xa8P8EmlBcrlnWQvqz9Q+pouWNYaZkqiQ1mzP7r1gpI qtlngswkl8O1fu2vpa7sgmNaE1RIR/7F6Lg5LmR+bFAvkV0FEvEM/kLn7TIbY+zd 3qfVj8HvnEO8LVSITTPJlSBpEJRLY7LFPu6mR95lMDoEOAFQZHVz8pbSrydtSXYH 0A5ejpPgFdlJS5Rs4Fd0ZwSZd0Xd0DZHFhCIl3e1rzEGf3L+gtm7klAZvDODRD0z 8uz+dDrMiYA9YJ0bKmO2J2NBXeWcJZ4DYuiXMrmSUpOaLjJInPc0DgIKRBM+D/4I UjuvEaYpf9GBKmiGL2qjhDxj9nXsl6JnPO6LBBDeUVXE8HD3q3ECUq7S09tTIgSx 4eVinWsjUIz0O/2JEBRVx+mOitNkbxcmMUdxTCoMVK9Bfv1xDmGPp9T651sihU0I e9fxdbbDb70SjsvI4qq+ =H0hG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSVC error
vicky wrote: Even after defining the $CATALINA_PID & $JAVA_HOME variable , i'm still the getting segmentation error(detailed error mentioned below) In my experience, a "segmentation fault" often occurs when the *binary* that you are trying to run, is not made for the platform on which you are trying to run it. For example, you try to use under Solaris a binary made for Linux; or trying to run a 64-bit binary on a 32-bit platform. Stuff of that kind. So, are you sure that the "jsvc" that you're using matches your platform ? What about "file (path_to)/jsvc" ? what does it say ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
David Law wrote: André, regarding the "Content-Transfer-Encoding" header mentioned in: http://www.w3.org/TR/SVGTiny12/mimereg.html Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME): http://tools.ietf.org/html/rfc2045 RFC 2616 (HTTP/1.1) states, here "19.4.5 No Content-Transfer-Encoding": "HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045." http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Also, under RFC 2616 (HTTP/1.1) 19.4.4 & 19.4.6 respectively, Content-Encoding & Transfer-Encoding are introduced. Transfer-Encoding & Content-Transfer-Encoding are intended for use in transmission only, so the data will arrive intact. An example of such would be Base64: http://en.wikipedia.org/wiki/Base64 I think we were right to choose Content-Encoding. I agree. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the acceptCount attribute not work like it's configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 12/31/13, 6:11 AM, Mark Thomas wrote: > On 31/12/2013 09:42, 侯树成 wrote: >> Oh, everything is default in server.xml except Connector >> configuration. > > Yes, I can read thanks. > >> "I have already explained how maxConnections is enforced by >> Tomcat." Where? When? I'm sorry, I havn't know it. > > You replied to my explanation so I suggest you go back and re-read > the thread for your previous question. > >> "the configuration of the client (number of threads, timeouts, >> etc.) " --> just need a simple web app, in the servlet you can >> sleep 60s. > > None of which answers my questions about the client configuration. You might want to take a look at 侯树成's previous message under a different thread where he gives some details about server behavior which sounds odd to me: http://markmail.org/message/zvmxuagop7xiqinm - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSwtgoAAoJEBzwKT+lPKRYhhcQAKDHm3x+tQoK5D23J0jL+C5g KPI66/vIUZc+B6ilplZpVU8Zp9p4Rd8e+0uaaofC1LXq2048sbnxGah8rpoTR7EK vPeucO5XsjEE5UjxouZt+qreFI08oaQN278m6dGRp37Q+KkV7Z/oU5TJUxA1CtR6 NaCXFfDG9mpu1qQZrGFKBrXVYkljxQF0q3TZn++MLeqHmmdoIkoDxbVgZSewHAwc KPE+V23ZLYkyZ3liphOT36gDdC6YQR0P4tLxPUoKEZ1jWs3YoZP0IgJaEjd0ptmz yIxQkOnmEsxPSbRzUHJaC+6PE3iQ2U3p5KHGR2AGFAuTnPCMItU5DatMnxgOzqaz e4lYMkPwqY6hcksEY3nf9489GN2LYlrsFy0s5YtR7WsXZ9GcloIM1YnJOKoMPIvo j8gztl6lEchTx5P5z+1eMJHvo2HMhkqtQGWjsF0r/rgduY17pccV5B85JSzH0mcq er6btMNWMyMTAQqoP2u4Xbq0EoNp2LM9rmbKBAO0G8wdf9k3tQ5Mb9AsGv9ig11k izmQkLSsw2hcOJpriyceIn2H320rzsKPxZ88MYaNebNyCeaYmjjOzBO+KxFIW6w5 b6oW+O8Pf3SloGxRmLqsNbPvDLs3/X1iBF3yJu5xLSGnUTjvjZZB87UlLd6H6xbQ o2IeICyu0Bxa+Kkl7lBN =oRbc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 12/31/13, 2:52 AM, David Law wrote: > these are 2 completely different issues. > > svgz's should be served with the correct encoding (gzip) as > required by the W3C SVG standard. ALWAYS. > http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers That > means, files with the extension .svgz will be served, as they are, > with the Content-Encoding header gzip. This is > performance-neutral. The "correct" encoding is debatable: one can argue that web servers shouldn't be adding the Content-Encoding:gzip to resources that the server itself did not gzip. If web servers were to take .gz files from the disk and set Content-Encoding:gzip, then the client would decompress the data upon receipt instead of storing the compressed bytes sent by the server originally. That has the effect of mutating the original resource form the perspective of the client. In this case, the SVG standard is asking "SVG servers" (presumably distinct from "web servers") to behave differently than originally expected. I think there's some wiggle-room here and its not as black-and-white as you propose. > "The Patch" is something completely different: it serves a file > with a particular extension, say *.XXX, from *.XXX.gz, if present. > SOMETIMES (depending on the Servlet gzip-parameter). This will add > a certain overhead, server-side, for EVERY FILE served. (because > "if present" implies a resources lookup) True, but irrelevant. This is no different from serving any file from a web server. > svgz's have the extension .svgz, not .svg.gz or .svgz.gz or > anything else for that matter, so "The Patch" will not have any > effect, and should not, for that matter. The extension is not terribly relevant, other than its what you chose to check for. In order to serve .svgz files in the way you want, a simple Filter can be used -- and markt already gave you the code to do so. Your original message said "Any chance of getting this [feature] at long last?" You make it seem like Tomcat is refusing to implement some crucial capability hat only the container can provide. This is not true for two reasons: first, it is not necessary for Tomcat to implement this - it can be done trivially by the web application; second, there is already a component in Tomcat that can be used to do this (bug 54095) with a bit of a tweak -- looking for filenames other than "*.gz". In your case, it probably makes sense to simply use Mark's Filter until the Tomcat committers decide what to do about this case. Perhaps an "example Filter" is the best thing to do here since it's a fairly specific use case and definitely would result in surprising behavior to many people if used by default. It's also clear there is room for improvement to Philippe's initial patch. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF 6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02 oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6 WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS FGKrbQ7zojR3wVHhGGlH =WjKV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single error page for multiple web applications
Hello Serge, Thank you for your reply. This option seems to be similar to the first thing i tried, editing conf/web.xml. As is suggested in http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcat But contrary to what's stated in the stackoverlow message, this does not work if the error occours in the context of another web application. The following issue description is similar to mine; http://anthonyjdev.blogspot.nl/2012/09/custom-error-page-for-all-apps-in-tomcat.html In this case, even if the location is defined in conf/web.xml (global), the error pages are being searched for in the context of the web application that issued the error. In strict J2EE sense, i do understand that reasoning. That's not what i want though ;) If i am wrong about the understanding of all of this, please correct me. But i just tried that stackoverlow approach again and still it seems to be tied to the webapp that issues the error. Thank you, Regards, Maarten . 2013/12/31 Serge Fonville > Hello Maarten, > > When I was in the same boat, I found > > http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand > http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful. > > I found these by googling > > https://www.google.nl/?gws_rd=cr&ei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+page&safe=off > > HTH > > Kind regards/met vriendelijke groet, > > Serge Fonville > > http://www.sergefonville.nl > > > 2013/12/31 Maarten van Hulsentop > > > Hello, > > > > We are using Tomcat to host a number of web applications as a uniform > > solution. We trying to implement something that seems to be an odd > > requirement, even though it is really a use case for us. > > > > We would like to define a single [default] error page for all web > > applications residing on this Tomcat instance. After some experimentation > > and googling around, it seems that there is no clear-cut solution for > this. > > I see a few options; > > > > - Let the global conf/web.xml define error pages for all web applications > > at once. However these are always relative to the web application > context, > > and require every web application to pack the error pages again, which > is a > > duplicate of resources and defeats the DRY principle. > > - An Error reporting valve can be implemented to handle error pages. > Simply > > extend ErrorReportValve delivered from Tomcat and implement the report() > > method. But then how should this report method behave? > > 1- It could build up a HTML page from java code directly (as is being > done > > in the Tomcat default implementation of the ErrorReportValve). The > downside > > of this would be that it is not possible to style the page afterwards. > > 2- It could fetch the HTML page from a location specified in > configuration > > (system property or otherwise) and stream it to the client. But is it > > possible to have dynamic behavior in that case (jsp behavior). I think we > > would need a RequestDispatcher for that and that is supposed to be in > > context i presume. > > 3- It could fetch the ROOT context (which has to be crossContext=true > then > > i assume) and delegate the handling of errors to a page in the root > > context. This one would have my preference, as it allows the > configuration > > of a single error page, while trying to stick (mimic) as much of the > normal > > J2EE behavior as possible. But it also seems to be the most tricky one. > > Also, i am not sure on the crossContext setting. Documentation points out > > that it should not be set on security conscious environments. My > experience > > is that security is always important, so does this make it a no-no or is > > this a theoretical security risk? > > > > Please share your opinions about this, things i missed, or (even better!) > > your solution :) > > > > Thank you in advance! > > Regards, > > > > Maarten van Hulsentop > > >
Re: Java to JavaScript RMI framework available.
Hello Igor, this looks really promising, I will take a deeper look in next year ;-) Btw, Happy New Year to Everyone ;-) Leon On Tue, Dec 31, 2013 at 1:55 AM, Igor Urisman wrote: > Folks, > > I needed to write this for something I am working on and thought there > might be a wider audience for it. > Tomcat 8 supports standard compliant Websockets, which provide convenient > asynchronous full-duplex > server to client data transport. The framework I am offering builds on top > of that a feature rich remote > method invocation paradigm. Please check it out. > > https://github.com/iurisman/FERMI > Apache 2.0 license. > > Happy coding. > Igor. >
Re: the acceptCount attribute not work like it's configuration
On 31/12/2013 09:42, 侯树成 wrote: > Oh, everything is default in server.xml except Connector configuration. Yes, I can read thanks. > "I have already explained how maxConnections is enforced by Tomcat." Where? > When? I'm sorry, I havn't know it. You replied to my explanation so I suggest you go back and re-read the thread for your previous question. > "the configuration of the client (number of threads, timeouts, etc.) " --> > just need a simple web app, in the servlet you can sleep 60s. None of which answers my questions about the client configuration. > Thank you for your reply. Mark > > > > 2013/12/31 Mark Thomas > >> On 31/12/2013 02:01, 侯树成 wrote: >>> Hi, >>> Today, I find the acceptCount of connector is not work like it's config. >>> You can try it like this: >>> >>connectionTimeout="2" >>>redirectPort="8443" acceptCount="2" maxThreads="1" >>> minSpareThreads="1"/> >>> >>> use LR or JMeter make more requests( >10) . You will find that 5 >> requests >>> will served correctly, others will be refused. >>> >>> When the acceptCount=3 >>>>>connectionTimeout="2" >>>redirectPort="8443" acceptCount="3" maxThreads="1" >>> minSpareThreads="1"/> >>> >>> You will find that 7 requests will served correctly, others will be >>> refused. >>> >>> >>> When the acceptCount=4 >>>>>connectionTimeout="2" >>>redirectPort="8443" acceptCount="4" maxThreads="1" >>> minSpareThreads="1"/> >>> >>> You will find that 9 requests will served correctly, others will be >>> refused. >>> >>> Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right? >>> >>> why the acceptCount is not work like it's configuration? >>> >>> Could you help me? Thank you. >> >> With the information provided above, no. >> >> I have already explained how maxConnections is enforced by Tomcat. >> >> The behaviour you observe in your test will depend on the configuration >> of the client (number of threads, timeouts, etc.) which you have failed >> to provide. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSVC error
Even after defining the $CATALINA_PID & $JAVA_HOME variable , i'm still the getting segmentation error(detailed error mentioned below) ++ bin/startdaemon.sh: line 13: 4402 Segmentation fault (core dumped) ./bin/jsvc -cp $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err -Dcatalina.home=$CATALINA_HOME -pidfile "/root/test/tomcattest" -Dcatalina.base=$CATALINA_BASE -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties org.apache.catalina.startup.Bootstrap start Thanks Vicky From: Konstantin Kolinko To: Tomcat Users List Sent: Tuesday, 31 December 2013 4:03 PM Subject: Re: JSVC error 2013/12/31 vicky : > Hi, > > I have configured the below in my tomcat 7.0.39 startup script & when > executing this script I 'm getting segmentation error(detailed error > mentioned below) > > Please suggest how to fix this. > > + start up script ++ > CATALINA_BASE=/root/test/tomcattest > CATALINA_HOME=/root/home/apache-tomcat-7.0.39 > cd $CATALINA_BASE > ./bin/jsvc \ > -cp >$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \ > -outfile $CATALINA_BASE/logs/catalina.out \ > -errfile $CATALINA_BASE/logs/catalina.err \ > -Dcatalina.home=$CATALINA_HOME \ > -pidfile "$CATALINA_PID" \ > -Dcatalina.base=$CATALINA_BASE \ > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ > -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties >\ > org.apache.catalina.startup.Bootstrap start > ++ > > ERROR > ++= > ./startdaemon.sh: line 13: 7429 Segmentation fault (core dumped) > ./bin/jsvc -cp > $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile > $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err > -Dcatalina.home=$CATALINA_HOME -pidfile "$CATALINA_PID" > -Dcatalina.base=$CATALINA_BASE > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties > org.apache.catalina.startup.Bootstrap start > > +++ 1. Did you tell jsvc where your Java is? You can use either "-home" argument or JAVA_HOME environment variable. http://commons.apache.org/proper/commons-daemon/jsvc.html 2. You have not defined the value of CATALINA_PID variable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSVC error
2013/12/31 vicky : > Hi, > > I have configured the below in my tomcat 7.0.39 startup script & when > executing this script I 'm getting segmentation error(detailed error > mentioned below) > > Please suggest how to fix this. > > + start up script ++ > CATALINA_BASE=/root/test/tomcattest > CATALINA_HOME=/root/home/apache-tomcat-7.0.39 > cd $CATALINA_BASE > ./bin/jsvc \ > -cp > $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \ > -outfile $CATALINA_BASE/logs/catalina.out \ > -errfile $CATALINA_BASE/logs/catalina.err \ > -Dcatalina.home=$CATALINA_HOME \ > -pidfile "$CATALINA_PID" \ > -Dcatalina.base=$CATALINA_BASE \ > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ > > -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \ > org.apache.catalina.startup.Bootstrap start > ++ > > ERROR > ++= > ./startdaemon.sh: line 13: 7429 Segmentation fault (core dumped) > ./bin/jsvc -cp > $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile > $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err > -Dcatalina.home=$CATALINA_HOME -pidfile "$CATALINA_PID" > -Dcatalina.base=$CATALINA_BASE > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties > org.apache.catalina.startup.Bootstrap start > > +++ 1. Did you tell jsvc where your Java is? You can use either "-home" argument or JAVA_HOME environment variable. http://commons.apache.org/proper/commons-daemon/jsvc.html 2. You have not defined the value of CATALINA_PID variable. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Single error page for multiple web applications
Hello Maarten, When I was in the same boat, I found http://stackoverflow.com/questions/13914575/how-to-build-server-level-custom-error-page-in-tomcatand http://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6 both very helpful. I found these by googling https://www.google.nl/?gws_rd=cr&ei=ALNzUtHWPKKN4wTVv4DgAw#q=tomcat+webapp+error+page&safe=off HTH Kind regards/met vriendelijke groet, Serge Fonville http://www.sergefonville.nl 2013/12/31 Maarten van Hulsentop > Hello, > > We are using Tomcat to host a number of web applications as a uniform > solution. We trying to implement something that seems to be an odd > requirement, even though it is really a use case for us. > > We would like to define a single [default] error page for all web > applications residing on this Tomcat instance. After some experimentation > and googling around, it seems that there is no clear-cut solution for this. > I see a few options; > > - Let the global conf/web.xml define error pages for all web applications > at once. However these are always relative to the web application context, > and require every web application to pack the error pages again, which is a > duplicate of resources and defeats the DRY principle. > - An Error reporting valve can be implemented to handle error pages. Simply > extend ErrorReportValve delivered from Tomcat and implement the report() > method. But then how should this report method behave? > 1- It could build up a HTML page from java code directly (as is being done > in the Tomcat default implementation of the ErrorReportValve). The downside > of this would be that it is not possible to style the page afterwards. > 2- It could fetch the HTML page from a location specified in configuration > (system property or otherwise) and stream it to the client. But is it > possible to have dynamic behavior in that case (jsp behavior). I think we > would need a RequestDispatcher for that and that is supposed to be in > context i presume. > 3- It could fetch the ROOT context (which has to be crossContext=true then > i assume) and delegate the handling of errors to a page in the root > context. This one would have my preference, as it allows the configuration > of a single error page, while trying to stick (mimic) as much of the normal > J2EE behavior as possible. But it also seems to be the most tricky one. > Also, i am not sure on the crossContext setting. Documentation points out > that it should not be set on security conscious environments. My experience > is that security is always important, so does this make it a no-no or is > this a theoretical security risk? > > Please share your opinions about this, things i missed, or (even better!) > your solution :) > > Thank you in advance! > Regards, > > Maarten van Hulsentop >
JSVC error
Hi, I have configured the below in my tomcat 7.0.39 startup script & when executing this script I 'm getting segmentation error(detailed error mentioned below) Please suggest how to fix this. + start up script ++ CATALINA_BASE=/root/test/tomcattest CATALINA_HOME=/root/home/apache-tomcat-7.0.39 cd $CATALINA_BASE ./bin/jsvc \ -cp $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar \ -outfile $CATALINA_BASE/logs/catalina.out \ -errfile $CATALINA_BASE/logs/catalina.err \ -Dcatalina.home=$CATALINA_HOME \ -pidfile "$CATALINA_PID" \ -Dcatalina.base=$CATALINA_BASE \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \ org.apache.catalina.startup.Bootstrap start ++ ERROR ++= ./startdaemon.sh: line 13: 7429 Segmentation fault (core dumped) ./bin/jsvc -cp $CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/tomcat-juli.jar -outfile $CATALINA_BASE/logs/catalina.out -errfile $CATALINA_BASE/logs/catalina.err -Dcatalina.home=$CATALINA_HOME -pidfile "$CATALINA_PID" -Dcatalina.base=$CATALINA_BASE -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties org.apache.catalina.startup.Bootstrap start +++ Thanks Vickyy
Single error page for multiple web applications
Hello, We are using Tomcat to host a number of web applications as a uniform solution. We trying to implement something that seems to be an odd requirement, even though it is really a use case for us. We would like to define a single [default] error page for all web applications residing on this Tomcat instance. After some experimentation and googling around, it seems that there is no clear-cut solution for this. I see a few options; - Let the global conf/web.xml define error pages for all web applications at once. However these are always relative to the web application context, and require every web application to pack the error pages again, which is a duplicate of resources and defeats the DRY principle. - An Error reporting valve can be implemented to handle error pages. Simply extend ErrorReportValve delivered from Tomcat and implement the report() method. But then how should this report method behave? 1- It could build up a HTML page from java code directly (as is being done in the Tomcat default implementation of the ErrorReportValve). The downside of this would be that it is not possible to style the page afterwards. 2- It could fetch the HTML page from a location specified in configuration (system property or otherwise) and stream it to the client. But is it possible to have dynamic behavior in that case (jsp behavior). I think we would need a RequestDispatcher for that and that is supposed to be in context i presume. 3- It could fetch the ROOT context (which has to be crossContext=true then i assume) and delegate the handling of errors to a page in the root context. This one would have my preference, as it allows the configuration of a single error page, while trying to stick (mimic) as much of the normal J2EE behavior as possible. But it also seems to be the most tricky one. Also, i am not sure on the crossContext setting. Documentation points out that it should not be set on security conscious environments. My experience is that security is always important, so does this make it a no-no or is this a theoretical security risk? Please share your opinions about this, things i missed, or (even better!) your solution :) Thank you in advance! Regards, Maarten van Hulsentop
Re: the acceptCount attribute not work like it's configuration
Oh, everything is default in server.xml except Connector configuration. "I have already explained how maxConnections is enforced by Tomcat." Where? When? I'm sorry, I havn't know it. "the configuration of the client (number of threads, timeouts, etc.) " --> just need a simple web app, in the servlet you can sleep 60s. Thank you for your reply. 2013/12/31 Mark Thomas > On 31/12/2013 02:01, 侯树成 wrote: > > Hi, > > Today, I find the acceptCount of connector is not work like it's config. > > You can try it like this: > > >connectionTimeout="2" > >redirectPort="8443" acceptCount="2" maxThreads="1" > > minSpareThreads="1"/> > > > > use LR or JMeter make more requests( >10) . You will find that 5 > requests > > will served correctly, others will be refused. > > > > When the acceptCount=3 > > >connectionTimeout="2" > >redirectPort="8443" acceptCount="3" maxThreads="1" > > minSpareThreads="1"/> > > > > You will find that 7 requests will served correctly, others will be > > refused. > > > > > > When the acceptCount=4 > > >connectionTimeout="2" > >redirectPort="8443" acceptCount="4" maxThreads="1" > > minSpareThreads="1"/> > > > > You will find that 9 requests will served correctly, others will be > > refused. > > > > Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right? > > > > why the acceptCount is not work like it's configuration? > > > > Could you help me? Thank you. > > With the information provided above, no. > > I have already explained how maxConnections is enforced by Tomcat. > > The behaviour you observe in your test will depend on the configuration > of the client (number of threads, timeouts, etc.) which you have failed > to provide. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: doe response auto commit when browser abort or close?
On 31/12/2013 07:53, 侯树成 wrote:
> Hi, I got an Exception like this:
>
> java.lang.IllegalStateException: Cannot call sendError() after the response
> has been committed
>
>
> I got it in following steps:
> 1. Deploy a web app.
> 2. request the app in browser, refresh the page when it not response
> fully(or close it when the page not response correctly)
> 3. get the exception
>
>
> the exception was throw in blow code:
>
> class OutputBuffer
> public void realWriteBytes(byte buf[], int off, int cnt) {
> .
> coyoteResponse.doWrte(outputChunk); //it will throw
> "java.io.IOException: An established connection was aborted
> //by the software in your host
> machine"
> } catch (IOException e) {
> // An IOException on a write is almost always due to
> // the remote client aborting the request. Wrap this
> // so that it can be handled better by the error dispatcher.
> throw new ClientAbortException(e); // it will handled by
> outter code.But now the commit equals true when sendError method execute,
> so
>//IllegalStateException will throw.
> }
> }
>
> Does the response will set commit = true when the client close or abort?
No.
Mark
> In source code, I just find the flush method or close method will set
> commit = true, others was correct request/response lifecycle.
>
> Thanks in advance.
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: the acceptCount attribute not work like it's configuration
On 31/12/2013 02:01, 侯树成 wrote: > Hi, > Today, I find the acceptCount of connector is not work like it's config. > You can try it like this: > connectionTimeout="2" >redirectPort="8443" acceptCount="2" maxThreads="1" > minSpareThreads="1"/> > > use LR or JMeter make more requests( >10) . You will find that 5 requests > will served correctly, others will be refused. > > When the acceptCount=3 >connectionTimeout="2" >redirectPort="8443" acceptCount="3" maxThreads="1" > minSpareThreads="1"/> > > You will find that 7 requests will served correctly, others will be > refused. > > > When the acceptCount=4 >connectionTimeout="2" >redirectPort="8443" acceptCount="4" maxThreads="1" > minSpareThreads="1"/> > > You will find that 9 requests will served correctly, others will be > refused. > > Yes, the SUCCESS requests = 2 * acceptCount + maxthead , is it right? > > why the acceptCount is not work like it's configuration? > > Could you help me? Thank you. With the information provided above, no. I have already explained how maxConnections is enforced by Tomcat. The behaviour you observe in your test will depend on the configuration of the client (number of threads, timeouts, etc.) which you have failed to provide. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
André,
regarding the "Content-Transfer-Encoding" header mentioned in:
http://www.w3.org/TR/SVGTiny12/mimereg.html
Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME):
http://tools.ietf.org/html/rfc2045
RFC 2616 (HTTP/1.1) states, here "19.4.5 No Content-Transfer-Encoding":
"HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Also, under RFC 2616 (HTTP/1.1) 19.4.4 & 19.4.6 respectively,
Content-Encoding & Transfer-Encoding are introduced.
Transfer-Encoding & Content-Transfer-Encoding are intended
for use in transmission only, so the data will arrive intact.
An example of such would be Base64:
http://en.wikipedia.org/wiki/Base64
I think we were right to choose Content-Encoding.
All the best,
DaveLaw
On 30/12/2013 01:28, David Law wrote:
Hi André,
thats exactly what the JIRA Request is about:
https://java.net/jira/browse/SERVLET_SPEC-86
We want a generic solution & not just something specific to *.svgz
Regarding the "Content-Transfer-Encoding header",
I'm afraid that's beyond me.
Maybe Mark has an opinion on that?
Regards,
DaveLaw
On 30/12/2013 00:18, André Warnier wrote:
Mark Thomas wrote:
On 28/12/2013 21:36, David Law wrote:
I just tried this in DefaultServlet:
if (contentType.equals("image/svg+xml")
&& path.toLowerCase().endsWith(".svgz")) {
response.addHeader("Content-Encoding", "gzip");
}
"Quick & dirty", but Works fine as proof-of-concept.
We just need a DefaultServlet expert to do the "slow & clean" stuff.
I'd suggest simply using a filter mapped to *.svgz for now.
I believe a generic solution to be best though, long-term.
Something like:
That would be my preference but would require a change from the Servlet
EG. I'm not sure if adding a element to or adding a new
element is the best solution. I created
https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add
comments.
As a comment, I would like to add that the adding of a
"Content-Encoding" header for certain data files served by Tomcat may
be interesting for more types than just *.svgz files.
For example, in document-management or archive applications, it is
interesting to store various types of documents on the server in an
already-compressed format and serve them that way, yet have the
client receive the information necessary to automatically uncompress
the response content to handle the original format correctly, without
having to use a specific servlet filter or document-retrieval servlet
to do so.
The discussion about .svgz is equally applicable to all kinds of
*.xxx.gz files for instance, where xxx may be PDF, MS-Office, plain
text or whatever could be stored pre-compressed on the server.
(Applications of the "store once, retrieve many times" model).
As another side-comment, there seems to exist an ambiguity/error in
the following document : http://www.w3.org/TR/SVGTiny12/mimereg.html
In section "Security considerations", it says :
quote
SVG documents may be transmitted in compressed form using gzip
compression. For systems which employ MIME-like mechanisms, such as
HTTP, this is indicated by the *Content-Transfer-Encoding header*;
for systems which do not, ...
unquote
(emphasis mine)
but the HTTP specification in RFC 2616 does not have a
"Content-Transfer-Encoding" header.
It has "Content-Encoding" and "Transfer-Encoding", as two distinct
headers with distinct meanings.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
