gitblit go stops serving CSS and images to the browser after about week of uptime about gitblit HOT 9 CLOSED

You like the hard ones.  :)  I'll see if I can reproduce it.

Yes :-) The good point here is that our installation is probably used by more than 70
people, so a good benchmark for gitblit :-)

Again not a real show stopper, the problem occurs after 1 week or so, and we can workaround
the issue by restarting gitblit GO. Maybe it's an issue with the GO edition and the
WAR edition is unaffected, but unluckily at present I have no time to switch to the
WAR edition.

Problem occurred again: gitblit stopped serving CSS and images yesterday, and we restarted
it.

What are your launch parameters for Java?  Are you using the server or hotspot vm? 
Is this Oracle Java or OpenJDK?

Sorry, I did not notice comment 4. In any case, we recently moved to the WAR distribution
and the problem is still present, so it is not limited to the GO edition.

We are using Jetty 7.5.1 to run WAR 0.60. Jetty is started using its own shell script
(which imposes -server switch). The JVM is Oracle's 1.6.24 64Bit on a Centos 5.5 x64

I now asked to restart the server in debug mode. I plan to remote debug the server
the next time the issue will show up. 

Gitblit relies on its servlet container and Wicket for resource management.  In reviewing
the resource cache policy I see that I left the resource duration at its default (120
mins) which is too short for these static files.

I will adjust that for the next release and performance, all-around, should improve
- if only slightly.  That may or may not change anything related to your problem. 
It's a strange one.  When you manage to get Gitblit back into this state of not sending
resource files, can you try fetching an image or css file with wget or curl?  I'd be
interested to know if it fails that way too.

Are you still experiencing this issue?  I have never experienced it myself.

Problem solved! Apparently our Linux installation automatically performs a scheduled
clean-up of the /tmp folder and deletes any resource that is both very old and has
not been modified for a long time. 

Now, it turns out that gitblit-go extracts the images and the CSS in a subfolder of
/tmp. The same happens with gitblit.war deployed in Jetty, unless you tell Jetty to
use a custom temporary folder. Those resources remained unchanged and after the initial
WAR deploy and after some time were subject to the clean up process described above.
Restarting gitblit-go or Jetty solved the issue because in both cases the resources
were extracted again.

Don't know whether this is standard behaviour for Centos 5.5 or just a configuration
of our installation, but at least we finally spotted the issue.

Thanks for your help.

Ah...  I can't control what the servlet container does with a WAR file, but GO has a
setting to specify the temp folder (server.tempFolder) to which the resources are extracted.

Maybe I'll add that as a FAQ entry.