Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Unable to render Velocity Template

It depends a lot on how you deploy. A number of proprietary application servers have high level GUI tools that require a war and provide stable rolling upgrades across clusters with integrated load balancing. Even a single instance of Jetty can be configured to redeploy modified webapps without interrupting service with simple war deployment if you were able to avoid the permgen errors.

Most of the time though, when I'm working with Jetty, I deploy an exploded war as you do, restarting the server. I always use ant or gradle more recently to generate the war. Eclipse has options hidden all over the place and I don't trust it to reproduce a build consistently.


On Thu, 12 Feb 2015 00:12 Steve Sobol - Lobos Studios <steve@xxxxxxxxxxxxxxxx> wrote:
Which brings to mind a question.

What are the benefits of packaging a webapp as a WAR and letting Jetty automatically unzip it? I used to, and I still use Eclipse to package my webapps into WAR files to ensure that all of the dependencies get packaged with it, but now I just manually unzip it on the server and then restart Jetty.


Joakim Erdfelt wrote:
I agree with Stefan and Michael.

Its a /tmp directory cleanup issue. (quite a common problem seen when using long running, platform neutral, services on linux)

Like Michael said, set the java.io.tmpdir system property that Java uses to a directory somewhere other than /tmp.  (the system admins should have a few preferences for you, depending on your linux distribution.  (some commonly seen example: /var/cache/jetty or /var/www/jetty or /home/jetty/work)

This will influence the behavior of Jetty itself, and velocity.
Jetty will then use the new temp directory for its own unpacked webapp structure (a process that which is required in most deployment use cases).
And when velocity itself needs a temp directory for its own reasons (which it does) those files will also remain untouched.
Also if you have any other 3rd party libraries that use the Java temp file routines those will also reside in an location untouched by other processes.

Additional suggestions:
  • Upgrade Jetty - 9.1.x is part of the transitional period for Jetty 9 from Servlet 3.0 to Servlet 3.1.  Its a bit of a hybrid release.
  • Once you have upgraded, use the ${jetty.base} and ${jetty.home} separation.
  • After creation of your ${jetty.base}, make sure you have a ${jetty.base}/work/ directory created as well.


--
Joakim Erdfelt <joakim@xxxxxxxxxxx>
Expert advice, services and support from from the Jetty & CometD experts

On Mon, Feb 9, 2015 at 12:34 PM, Eduardo Fiss Beloni <ebeloni@xxxxxxxxxxxx> wrote:
Thank you for the reply Stefan,

But the people that set up the servers told me there's no tmp clean up.
Can you think of another reason?

Eduardo Fiss Beloni
ebeloni@xxxxxxxxxxxx
www.voiza.com.br
Soluções em Java
(51) 4063-8913 - Porto Alegre
(53) 4062-9183/3222-1833 - Pelotas

----- Original Message -----
From: "Stefan Magnus Landrø" <stefan.landro@xxxxxxxxx>
To: "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>
Sent: Wednesday, January 28, 2015 10:12:04 AM
Subject: Re: [jetty-users] Unable to render Velocity Template




Sounds like the linux tmp folder is cleaned up every now and then. You can make jetty use a different tmp folder in order to prevent issue. See docs.

Stefan



2015-01-28 12:26 GMT+01:00 Eduardo Fiss Beloni < ebeloni@xxxxxxxxxxxx > :


Hello,

We are having loads of "Unable to render Velocity Template" throughout the jetty logs. Then the user can't see the site anymore.

2015-01-26 10:20:38,751 [qtp399631128-23 ERROR CommonsLogger]: Unable to render Velocity Template, '/error.vm'
org.apache.velocity.exception.VelocityException: Exception rendering #parse(/_inc/footer.vm) at /error.vm[line 67, column 9]
...
...
2015-01-25 23:07:34,732 [qtp1819130381-4849 ERROR CommonsLogger]: Unable to render Velocity Template, '/super/aba_vitrine.vm'
org.apache.velocity.exception.VelocityException: VelocimacroProxy.render() : exception VM = #produto()

It happens a few times a month. When this happens the only way to bring our frontend servers back is to restart jettys.

This started to happen when we updated from jetty 7 to jetty 9.1.3. Could this be a jetty parameter or something?

Thank you,

Eduardo Fiss Beloni
ebeloni@xxxxxxxxxxxx
www.voiza.com.br
Soluções em Java
(51) 4063-8913 - Porto Alegre
(53) 4062-9183/3222-1833 - Pelotas
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users


--

BEKK Open
http://open.bekk.no


TesTcl - a unit test framework for iRules
http://testcl.com
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

--
Lobos Studios - Website and Mobile App Design & Development; IT Support; Computer Maintenance
Toll Free  877.919.4WEB - Apple Valley 760.684.8859 - Los Angeles 310.945.2410
www.LobosStudios.com * www.facebook.com/LobosStudios * @LobosStudios

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top