SSI - Regular expression parsing
Hi,
I'm trying to use some SSI in 7.0.39 using SSIFilter. The file is parsed, in
principle, but whenever an IF expression with a certain regular expression is
encountered, Tomcat seems to stop processing the file and will not return any
contents after that (for the request).
Example:
My request is:
http://...:8080/amt/file.html?year=234234
The relevant portion of the file is:
QS:
year:
not
The response to the request is the beginning of the file, and then
QS:year=2012
After the "#if", nothing is encountered.
Other IF statements work as expected - this seems to have to do with the
regular expression.
I have tried a number of variants, including $QUERY_STRING instead of ${...}.
I find no error about this in the logs (I have set debug to 1 for the
SSIFilter, but I'm not sure if I need to change anything else in logging
properties.
I tried simpler regular expressions. The following
Leads to the error below:
java.lang.ClassCastException:
org.apache.catalina.ssi.ExpressionParseTree$EqualNode cannot be cast to
org.apache.catalina.ssi.ExpressionParseTree$StringNode
org.apache.catalina.ssi.ExpressionParseTree$CompareNode.compareBranches(ExpressionParseTree.java:353)
org.apache.catalina.ssi.ExpressionParseTree$EqualNode.evaluate(ExpressionParseTree.java:381)
org.apache.catalina.ssi.ExpressionParseTree.evaluateTree(ExpressionParseTree.java:67)
org.apache.catalina.ssi.SSIConditional.evaluateArguments(SSIConditional.java:124)
org.apache.catalina.ssi.SSIConditional.process(SSIConditional.java:50)
org.apache.catalina.ssi.SSIProcessor.process(SSIProcessor.java:160)
org.apache.catalina.ssi.SSIFilter.doFilter(SSIFilter.java:144)
This occurs whenever the regular expression does not contain any parenthesis.
Is it even recognized/parsed as a regexp?
Is this a bug, or is my syntax off? I follow
http://tomcat.apache.org/tomcat-6.0-doc/ssi-howto.html
Any help is appreciated.
- DR
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: BackupManager start fails under heavy load
Hi Patrick,
A similar problem has been reported before:
http://tomcat.10.n6.nabble.com/org-apache-catalina-tribes-ChannelException-Operation-has-timed-out-3000-ms-Faulty-members-tcp-64-88-td4656393.html
The important error message from your log output is:
> Caused by: org.apache.catalina.tribes.ChannelException: Operation has
> timed out(3000 ms.).; Faulty members:tcp://{10, 230, 20, 86}:4001;
> tcp://{10, 230, 20, 87}:4001; tcp://{10, 230, 20, 94}:4001; tcp://{10, 230,
> 20, 95}:4001; tcp://{10, 230, 20, 70}:4001; tcp://{10, 230, 20, 89}:4001;
>
> at
>
> org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(Paral
> lelNioSender.java:109)
> ...
>
I am familiar with the code that generates this message; the problem is
that the sending operation is abandoned for any sender object which has not
been drained of data within timeout milliseconds. The "timeout" parameter
is declared in AbstractSender class as (long) 3000. By my reckoning a small
change to the timeout value could result a large reduction in messaging
failures.
According to information from this page:
http://tomcat.apache.org/tomcat-7.0-doc/config/cluster-sender.html
you should be able to increase the timeout parameter by setting a transport
attribute thus:
However, I can not find the code where the system reads the configuration
to override the default value; if you make the alteration and find the
error message still reports "3000ms", this would indicate an oversight in
the coding which could be reported.
BTW, your configuration for receiver has
selectorTimeout="100"
The code suggests that this should be the same value as sender/transport
timeout (ie 3000). The documentation says the default is 5000. My
examination of the code suggests that the PooledParallelSender class does
not read the configuration but always uses 5000. Nevertheless, you could
try setting that value to 5000 and seeing what happens.
BTW my own interest was to implement tribes at Internet connection speed;
by manipulating the parameter in question, my system copes with data
transfers that take multiple seconds.
http://tomcat.10.x6.nabble.com/overcoming-a-message-size-limitation-in-tribes-parallel-messaging-with-NioSender-tt4995446.html
Thomas MC-GOWAN est absent.
Je serai absent(e) du 28/06/2013 au 08/07/2013.
RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
> >>> I ran the openssl utility on the same system as Tomcat, and Process > >>> Explorer shows that its copy of libeay32.dll stays at the correct > >>> address. Additionally, I tested the FIPS-compatible libeay32.dll on > >>> a different server with Tomcat, and had the same problem. This seems > >>> to indicate that the memory address issue is specific to Tomcat, not > >>> the server. > >> > >> Or running within a JVM which has a significant amount of native code > >> that gets loaded first, which may cause the loader to re-locate the > >> library when it finally gets loaded. > >> > >> Any interest in trying some Java-based testing using libtcnative? > > > > I'm game, if you let me know what you'd like me to do. : ) > > All you should have to do is write a small Java program that calls > AprLifecycleListener.lifecycleEvent with an event of type > BEFORE_INIT_EVENT. > > You'll of course have to call things like setFIPSMode(true), etc. > > I wonder if you did that without the rest of Tomcat loaded if anything would > change. I would bet that it's more likely that the bulk of the JVM is causing > the re-location of the library than anything else. You are right. Even with that simple program the OpenSSL library gets rebased. > >> I'm curious: what base address did you use when you changed it? > > > > The one that worked for me was 0x6FB0. > > Did you just choose one randomly? Most of the other memory addresses in the process seemed to be at the 0x6xxx range, so I just tried adding 6 to the beginning of the default memory address, and it worked. > I wonder if you follow the suggestions from the aforementioned thread for > re-building everything with the /FIXED switch. That seems to have fixed > everyone's issues, but you have to be sure to build everything very carefully > or one component can still be relocatable. tcnative of course does not care. I may still be doing something wrong, but I still haven't been able to get this switch to work. I added it to the LFLAGS set in the OpenSSL build, but libeay32.dll still gets rebased when running through tcnative. --Steve Nickels Ipswitch, Inc.
Re: Accessing HREF Target from Servlet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 6/27/13 8:56 PM, George S. wrote: > OK, I'm thinking that was a dumb question. If I'm understanding > things, the browser is making the request for the page, and then > looking for the HREF target in the generated page. So, the reality > is that tomcat never sees the part after the # sign. Rats. Correct. I suppose there's nothing stopping a browser from sending you the "anchor" part of the URL, but it's not really supposed to be part of the resource identifier (the resource is the "page", not the particular place on the page where the user is scrolled-to) so it's pretty much never sent to the server. Javascript, on the other hand, will likely have access to this information, so you could always make an AJAX request to the server to provide/get more information. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRzZXbAAoJEBzwKT+lPKRYo34QAKyrNzDyvbKEXrSf3hVWZzuj hp6gKJn/hLqu1fsqx9ewBq/Zi7PHuTf3/e6VGc76EKXmKqiAmMSnJnFPUkbm6hqp b8z+7PENeWFYlIJfUTqzYtquWz5oqLcX8Qi2vRTEYGwmQ3EalYzULWL4Qf4FcLu5 5ofrP7Gps45x1vqgZleBofTis7y4Es6ccIBWwDZXnqbAsa3PYBivP02kQ8z3UpMP rDvyu/mUyR+DU8IQEUNEbdFmk7kYN9n4Nvqw0Co3uE2vfDQfua/gKfJ0RdhFK0D5 wrNcANX19neffF6sCEURBZcKQ9vMBnxXSIO93X+BGSaD44FGBdXaEUzeC6lq6iAu XmZyb2y9AT0sgyIPdlZaag3VI+qsgRRvPMb0sns/T1qf5DWxqn6Ts9Gz6dhfBShX Btlxr6fFm0ATWkAZZ3bnrMiSyyCUPcAlLRLoZ/Qatp5pf8YIQHPV5nwqsI/rLv1w drw4sMXayUD1O6OFzjpdO85wT3k9yS0XGSYR4mwPkSxuPyl2rsh/JwUgBN8KlIhW Im4ltb2sguDQdOTir4lNqwMZ/V/nmVs2/97NIvH5bOk1gc7cIReZEmx/El8yR38v XgLzDnMU96VHNZ9bzc+gknNE99q1nXJjKTzLQus3lQC3wEHh212xx0PAB5Gjgyd2 E++XuogeAdoaFMmQNfsj =pydj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Local VisualVM connection to Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jan, On 6/27/13 5:17 PM, honyk wrote: > On 2013-06-27 Christopher Schultz wrote: >> On 6/27/13 4:31 PM, honyk wrote: >>> I am constantly encountering PermGen errors despite quite high >>> PermGen limit (even 512m) and many options set - approx once a >>> week under not heavy load. >> >> Like what kinds of options? What kind of load? What does the >> error look like? Are you re-deploying your webapp without >> restarting Tomcat, or do you bust PermGen even with a single >> deployment? > > Tomcat runs as service using these Java opts (tomcat7w.exe) - > single line > > -Duser.language=en -XX:MaxPermSize=512m -XX:+DisableExplicitGC > -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled > > Originally I used Apache JkMount/Worker to hide that port number. > In that case there were listed these errors in the tomcat err log: > Exception in thread "ajp-bio-8009-exec-7" > java.lang.OutOfMemoryError: PermGen space I recommend that you run with -XX:+HeapDumpOnOutOfMemoryError and possibly also with -XX:HeapDumpPath=[path to where you want your heap dumps to go]. If/when your service busts PermGen, you should be able to inspect the dump and see what all the java.lang.Class objects are. I suppose it's possible that you have a lot of intern'd String objects as well (if you are on Java 1.6 or lower... you didn't say), but it's usually java.lang.Class objects. > Now I use proxypass like this (hoping this is preffered way): > ProxyPass /my-app ajp://localhost:8009/my-app > > and in this case I can see just Exception in thread > "ajp-bio-8009-exec-4" without any details (but I suppose it is the > same PermGen one) Your choice of connector should not be relevant. Neither mod_jk not mod_proxy_ajp are "preferred"... they each have their own advantages. > I do not hot deploy my apps. They are JSF2.0/Mojarra powered, some > of them access database a generate various reports. Do you use RMI or a lot of proxies? How about JSF and/or Mojarra? Both RIM and Proxy classes end up generating lots of junk Class objects and can fill your PermGen. Given that you already have 512MiB of PermGen, you have obviously changed this from the default. Have you tried raising it up to say 1GiB just to see what happen. It is entirely possible that, for your application, you really just need a whole bunch of PermGen. It's not likely, but it's possible. >>> I am trying to investigate what the app causes this, but I >>> haven't succeeded in reproducing it locally yet. >>> >>> I found several articles about VisualVM (I hope it could help >>> me to determine some PermGen issues) and connecting it to the >>> Tomcat. Remotely. But I have no clue how can I conect the local >>> VisualVM to tomcat that runs on localhost. >>> >>> Even here it is written: >>> http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html >>> >>> Enabling JMX Remote Note: This configuration is needed only if >>> you are going to monitor Tomcat remotely. It is not needed if >>> you are going to monitor it locally, using the same user that >>> Tomcat runs with. >>> >>> But there is no further description for that simpler (local) >>> method. If it is obvious, sorry, but I am lost here ;-) >> >> Connecting to a Tomcat running on localhost is dead simple: >> >> 1. Launch VisualVM 2. Once the main screen loads, double-click on >> "Tomcat" from the "Local" cluster of applications 3. Profit > > Now I've found this interesting article: > https://blogs.oracle.com/nbprofiler/entry/monitoring_java_processes_running_as > > I realized that my tomcat runs as a service but I am logged as an > user and in this case the tomcat is not visible to me. I'll test it > differently tomorrow. Try running VisualVM as an administrator. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRzZVaAAoJEBzwKT+lPKRYvYYQAMB3XYAmxbOawBA22foHRrDZ UROJRujWEPsOrPOrjq6UiMidK7F73hhDsejx1YTBUUyXM6NtCmt8yAP1TWdc0VcT 7qI1Q0HsyHeYpbjd5gHTsJYkoVK2abD8cQAnxgbns8PxlDaaUvdqnRcA4wLJVCzK Cw7ghoH9z5Yltbww5Mqne/pb9drXJoq02XUdbrEV4gejqK7t8Ow8OsSo4/izlG2k 08qu+PZ9UNYRt0Dihpx8QflLqv9Xu5HfpUwVWTRE5+uQgc0AaAExxR60xqAoYRL8 +YIi72JWiXWrQkceHDvSnP4w+SM8DfhI/SQtqMzJNoBIbbAgIMckqqm4LI+ngY+w eJa/wc/d6R186PTzT2Sd1TmiWDWLdw/CqSTOoXE7fryMthJiovxtvmhTrLsrwoKL WkbOTtXTPQduk8A1FHh/Y08ByGKNfwEapkQCsVidQyDmq2Y7Yrsb5cYYF5JiHFc6 tsqU6H+h5EAMPr0Nslt2WHyDIjFtZoIsn0hCNJ3CUAX9BUSyTQapP9TLxGxqN/Vo Ihykp2jtufQ2pEZkFZb3mE08CvX6ihdAmC4losvLXGCc5rzulBGr2BhuSTs3IXaF SakWdoj+cvXXtQBtUPTAHxML8inMn3qDit6BB5oBW5VeMQ0FOeemYlDyCjNVf0SA wBddCxlm7mUS0p2dTXCF =0rQS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
