--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2588f0d7-358d-4fda-a7ce-fb6f4eec7763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ab946851-7d85-4bb6-84c7-ef17cc783d6e%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/ab946851-7d85-4bb6-84c7-ef17cc783d6e%40googlegroups.com.
More questions… are you connecting via AJP or HTTP? and how are you doing it? What’s your apache config? is it just apache AJP connector or using mod_cfml?RegardsMD
Hi TimFirstly I would remove -XX:MaxPermSize=512m as this is no longer valid in Java 1.8 and not required, don't think this will help but it's good to tidy up.Also I would change the -Xms and -Xmx to be the same value, so -Xms2048m -Xmx2048m, this saves it from doing too much garbage collection, which might be the problem once you are under load.I would then install FusionReactor and see what that shows you when you are under load, as it will probably help point you in the direction of the issue.Also see Mark's questions.Kind regards,Andrew
If you're using a default install of Lucee done via the installer, then you're connecting Apache to Tomcat over HTTP using mod_proxy_http. This is further evident due to the fact that you're hitting an error on Tomcat's 8888 port - which is the default HTTP port in an installer build.
In your stack trace, no Lucee classes are being hit, so the problem is directly related to something Tomcat itself is doing.
I did a couple quick reads on the "IllegalMonitorStateException" error, and it looks like you're hitting some kind of runtime error with relation to threading:
http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-illegalmonitorstateexception-how-to-solve-illegalmonitorstateexception/
Does your server limit threading in any way? For example, are you on a Virtual Machine or some other kind of service that can impact threading? There may also be connector settings that can be adjusted to correct for this error, but we won't know what settings to adjust until we know why this error is being thrown in the first place.
If I were you, I'd start my search there.
Kind regards,
Jordan Michaels
> directly on a new Centos 6.7 install, not a VM
So, this is dedicated hardware?
The only reason I mention it is because kernel virtualization software
can restrict the threading of the host OS. I was simply shooting for
ideas of what might be causing issues with threading. It's quite
possible that it's not relevant to your situation. I wouldn't know
without doing more research.
Warm Regards,
Jordan Michaels
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c94ca271-b87a-4e41-b5c2-915f7556b9dc%40googlegroups.com.
I would second the use of FusionReactor in this instance by the way. You will be able to monitor what is going on a lot better and see what requests are making the server inactive. It could be buffer overflow tests that the PCI company is running for example.Without this you are just taking stabs I the dark.If not. Try Newrelic, although the FR is much better.I am not at my desk (but will be later to copy the setting) but you also want to do heap dump on out of memory errors (google it) setting in your setenv.sh to see what was in memory. It might help if you are actually crashing the server.
Mark Drew
The proxy server received an invalid
response from an upstream server.
The proxy server could not handle the request GET /.
Reason: Error reading from remote server
fusionreactor installed, server restarted and a new PCI scan initiated.
Picture "Screenshot from 2015-11-10 18-13-50.png" was caught as the freeze started, the server in fact did respond, just very slowly. A page of our application without CSS could be loaded to a browser. "Screenshot from 2015-11-10 18-14-06.png" contains the detailed lower stats from the page. Now I hope I'm dumping something informative here lol
After about 10 minutes only this can be loaded:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.Reason: Error reading from remote server
Apache/2.2.15 (CentOS) Server at myserver.com Port 443
fusionreactor still continues to update, however, and I can see memory usage (top right graph) slowly increasing then dropping, presumably as garbage collection is performed. The PCI scan fails still but only on one item: "CGI Generic Cross-Site Scripting" (grrr why can't I turn off italics?)
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/c08e9dc9-c9b5-4dbe-825b-439cc7e755d0%40googlegroups.com.
Those that have chimed in already are much better with the JVM, Tomcat and Lucee server than I am, but the screenshots that I’m seeing (and what’s described in the rest of this thread) suggest that it’s not a JVM or Tomcat issue, but is rather something in the application, itself, that’s causing a race condition. Are there any writes to the application scope or locks which take place every request or I/O actions such as logging that fire on errors which might have permissions issues which trigger additional errors, additional loging attempts, etc? Those can produce these kinds of lock-ups, in my experience. If you have a high request timeout setting, conditions causing the race will not resolve themselves and the server will eventually stop responding.In many early CFML libraries, before OOP practices were widely implemented in CFML, locks were used quite a bit, so it’s possible that, if this has a legacy code base, there’s a old third party library that’s the culprit.Jon
Ty for the thought, Jon, but since the application begins with a login page, the PCI scan is unable to access anything of our code except that. I've scanned the errors caused by the scan in our application log and you can see attempt-by-attempt these categories:
page not found...has no remote function with name....
The parameter returnTo to function logIn is required but was not passed in
invalid url [empty string] for attribute url
component [controllers.LocalizationController] has no remote function with name
I'm sure that's not exhaustive but it certainly covers that last 200+ error lines. Looks like they can't get in to our app?
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGC6_%2BoC2vsGkZY19iA0G0stsUrhdV9%3DiUyBhJqRPOxT%2BahhOw%40mail.gmail.com.
Tim,That’s a start,then. First off, I would set a default value for “returnTo”, so that login redirects don’t throw 500’s. Secondly, a lot of those PCI URLS being passed are for other language file extensions. Do you have those being handled by the web server, or is Lucee forced to handle those as well? You can very easily handle those in your rewrite rules, if you have them.
Since your exception log i/o actions are firing on 500’s, rather than the web server’s log appender, it’s best to deal with those 404’s at the web server level and save yourself the expense on the app server. With 18,000 404’s in a short period of time, that will take an instant load off of your application server.Jon
Hey Tim,
Any update on this? Did it work now?
Sincerely
Gert Franz
RASIA GmbH
Spittelgasse 7
5103 Moeriken-Wildegg
Email: ge...@rasia.ch
Skype: gert.franz
Phone Switzerland: +41 76 5680 231
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5c674160-87ad-40b0-9834-a8d5096050d0%40googlegroups.com.
Hey Tim,
Any update on this? Did it work now?
Sincerely
Gert Franz
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CFA0E2D0-B68D-4C47-9624-4E17C3BAD4C9%40gmail.com.
+1 to what Sean said... De-scope from PCI, it's not worth it.On 12 November 2015 at 16:51, Sean Daniels <daniel...@gmail.com> wrote:Tim, I'll just throw this out there as someone who was also quite annoyed with the burden of PCI...
Not sure if it's feasible in your situation or application, but there are tons of payment gateways now that offer account number vaulting and hosted payment pages - these two combined services can relieve your organization sometimes entirely of it's PCI compliance burden (the gateway processor becomes the responsible organization).
Something to think about. I am fortunate to be able to utilize these services and it's been a nice relief to not have to deal with that stuff anymore (logistically and emotionally!).
Yesyes! The service now stays up under the PCI test loading.
Sincerest props to Jon Clausen. On to the PCI test results. Oo-er.... :/
--
Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1b562ac8-b581-43be-8024-d00c63588d30%40googlegroups.com.