I have run into a very serious problem where I can longer deploy a war of a Grails 2.2.5 web application on Tomcat. The build (with 'grails war') proceeds without a problem, and I deploy it to Tomcat. I retsart Tomcat, and the web application simply does not run. It comes up with the deploying message, but clearly doesn't get as far as running Bootstrap.groovy, because logging from there doesn't show up in the log. No error messages are given, but the web app is simply not running.
I ran into a similar problem a few days ago on a different server which I solved by upgrading to Tomcat 7, but this one is already running Tomcat 7. I have no idea why this has started happening, unless it is something obscure to do with the recent change in Maven where only TLS 1.2 connections are allowed (a change which occurred a week or so ago).
So what could be happening? Is there some way I can log what is happening as the web app starts up, such that I might be able to see where the problem is occurring?
If it is of any relevance, it works OK when I do 'grails run-war' on my development machine.
Related
I had been using Grails 3.3.2 for about 3-4 years now and never had this issue. I just recently started migrating our apps to Grails 5 and now this started happening. Everytime I save a change to a file (gson, groovy, etc) the app redeploys and I have to wait a good 5-6 seconds before I can test it (url becomes available).
In Grails 5 my console looks like this when I make changes:
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
Each one of those Grails application running [...] lines is a 5+ second delay I have to wait through before the app comes back up
When I would work on my 3.3.2 projects my console would look like this during changes
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
I never had to wait, I could immediately refresh the page and see the changes. Needless to say, my DEV time has taken a hit having to stop and wait for a redeploy. Is there some configuration I missed while upgrading that I can set to resolve this?
This happens while running the app with gradlew bootRun as well as grailsw run-app
Grails 5.1.7
JDK: 11.0.13
I just recently started migrating our apps to Grails 5 and now this
started happening. Everytime I save a change to a file (gson, groovy,
etc) the app redeploys and I have to wait a good 5-6 seconds before I
can test it (url becomes available).
The behavior you described is expected and by design.
Older versions of Grails were configured by default with a reloading agent. Grails 5 is not. The default behavior you will get with Grails 5 is a recompile and restart. If you don't want that behavior you can remove the devtools from your build.
You didn't ask about configuring a reloading agent but if you are interested, see the Spring Boot Developer Tools and Spring Loaded section at https://docs.grails.org/5.1.7/guide/single.html#upgrading33x.
I am trying to upgrade jruby. Went to a latest version 9.1.12.0, didn't work. Tried one version up (9.1.0.0) and same issue
The issue is it takes a very long time to boot on tomcat. Once tomcat starts the application it becomes unresponsive. Browser hangs forever and then eventually times out. Tomcat log shows that the request came, was served reply and closed (everything normal). No errors show up in tomcat log.
Tomcat is sitting behind apache, connected though AJP. I tried switching to http(s) and neither worked. Going directly to tomcat yields the same results.
I worked on solving this issue for quite some time. Not sure why it hangs and doens't throw any errors. Tried changing configurations on rails/tomcat/apache and could not find why it doens't work.
Any help tracking down this issue would be greatly appreciated
Current stack:
Rails 4.1..15
Jruby 9.0.5.0
Tomcat 6
Java 1.7.0_131
Apache 2.4.7
sounds like an enthropy depletion might be going on,
export JRUBY_OPTS=-J-Djava.security.egd=file:/dev/./urandom
or in your case :
export CATALINA_OPTS=-Djava.security.egd=file:/dev/./urandom
explanation is this' questions answer: After Upgrade To JRuby 9.1.9.0, Rails CookieStore Very Slow When Handling Encrypted Cookies
... the next jruby-openssl release should hopefully handle this better
The Grails system with which we've been working fine for several months now has a problem whereby the /login/auth page appears blank.
The problem with the build only occurs on a deployed Tomcat or standalone system and not on local development machines where it works fine. There is no error appearing on the console at all.
The Network tab in Chrome shows a 404 error. We've put console debug messages in the auth() method within LoginController and these are not showing up.
In intellij Idea works fine, after generate the .war file (./gradlew assemble) the system not work.
If you get an 404 error, you should check all of the config files e.g. database settings. Somewhere must be a difference in those settings. Usually it is database connection which causes such kind of errors.
You can also check Catalina.log in the Tomcat server directory to find errors.
Issue on Websphere 6.1 I hope I'm missing something obvious: We have an application which gets deployed to a configured Websphere environment. We're trying to mimic this WebSphere configuration on a different platform (Linux vs Solaris), but maybe we're missing some obvious settings. The application deploys and starts without an error, but after logon on url localhost:port/app/index.jsp
(via j_spring_security_check) Websphere redirects to localhost:port/index.jsp. This gives an JSP processing Error (HTTPError 404), with code JSPG0036E.
The webapplication is wrapped in an ear, because those are the standards here. And that ear works well on our solaris WAS 6.1 environment but not on the linux WAS. Furthermore in development we've the wrapped war running on Tomcat without problem.
I think I missed the context root somewhere but It's not to be found in Websphere's console, I wouldn't be surprised if it is a Websphere (6.1.0.33) Bug, hopefully I'm wrong or are there workarounds?
Background
I'm running a Ruby on Rails application that has to serve a lot of static files as well.
My setup currently is:
Debian Linux Lenny 5.0
Apache 2.2.9
Passenger 2.2.10
The problem
Everything runs fine. I see apache process spinning up, passenger instances get created and everything works fast and snappy.
Then, after some time Apache does not respond to requests any more. Clients do get a connection and are "waiting for a response", but none comes.
I cannot manually reproduce this problem. Sometimes it occurs a few hours after a restart, other times it takes a few days to happen. Here's what I found:
Apache process are up; Passenger is there, but it does not have any instances spun up (probably because instances die after a period of inactivity)
No error messages or problems in /var/log/syslog, /var/log/messages, not in apache's access and errors logs, not in my Rails production log. Nothing.
When I stop and start apache everything is back to normal.
Does any one have any clues what's happening here? And how it can be resolved?
Due to an enormous load on static files we decided to host static files on separate server (later Amazon S3+CloudFront) for performance reasons.
My current guess is that Apache couldn't cope with the large number of requests on static files and also doing Passenger. The current setup is Nginx+Unicorn for the Rails application and S3+CloudFront for static files.