Goobi.Production

Error reading in TIFF images (in metadata editor)

Bug #788160 reported by Jennie Fletcher
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Goobi.Production
Fix Released
High
Unassigned
Goobi.Production 1.7.3
1.7
Fix Released
High
Unassigned
Goobi.Production 1.7.3

Bug Description

I am getting the following error when opening the metadata editor, and placing some TIFF images in the expected format/folder. NOTE: jpeg format images load without error.

ERROR 2011-05-25 15:24:29,857 de.sub.goobi.Metadaten.Metadaten.BildPruefen(?:?)
        java.lang.NullPointerException
ERROR 2011-05-25 15:24:29,857 de.sub.goobi.Metadaten.Metadaten.BildPruefen(?:?)
        java.lang.NullPointerException
ERROR 2011-05-25 15:24:46,145 de.unigoettingen.sub.commons.contentlib.imagelib.TiffInterpreter.read(TiffInterpreter.java:135)
        Imagereader for TIFF couldn't be found
ERROR 2011-05-25 15:24:46,146 de.unigoettingen.sub.commons.contentlib.imagelib.ImageManager.init(ImageManager.java:123)
        Error while getting ImageInterpreter
de.unigoettingen.sub.commons.contentlib.exceptions.ImageInterpreterException: Imagereader for TIFF format couldn't be found!
 at de.unigoettingen.sub.commons.contentlib.imagelib.TiffInterpreter.read(TiffInterpreter.java:136)
 at de.unigoettingen.sub.commons.contentlib.imagelib.TiffInterpreter.<init>(TiffInterpreter.java:99)
 at de.unigoettingen.sub.commons.contentlib.imagelib.ImageFileFormat.getInterpreter(ImageFileFormat.java:136)
 at de.unigoettingen.sub.commons.contentlib.imagelib.ImageFileFormat.getInterpreter(ImageFileFormat.java:120)
 at de.unigoettingen.sub.commons.contentlib.imagelib.ImageManager.init(ImageManager.java:120)
 at de.unigoettingen.sub.commons.contentlib.imagelib.ImageManager.<init>(ImageManager.java:93)
 at de.sub.goobi.Metadaten.MetadatenImagesHelper.scaleFile(Unknown Source)
 at de.sub.goobi.Metadaten.Metadaten.BildErmitteln(Unknown Source)
 at de.sub.goobi.Metadaten.Metadaten.XMLlesenStart(Unknown Source)
 at de.sub.goobi.Metadaten.Metadaten.XMLlesen(Unknown Source)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:132)
 at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:61)
 at javax.faces.component.UICommand.broadcast(UICommand.java:109)
 at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:184)
 at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:162)
 at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:350)
 at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
 at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
 at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
 at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at de.sub.goobi.helper.servletfilter.SessionCounterFilter.doFilter(Unknown Source)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at de.sub.goobi.helper.servletfilter.HibernateSessionFilter2.doFilter(Unknown Source)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at de.sub.goobi.helper.servletfilter.SecurityCheckFilter.doFilter(Unknown Source)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at de.sub.goobi.helper.servletfilter.RequestControlFilter.doFilter(Unknown Source)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
 at java.lang.Thread.run(Thread.java:662)
ERROR 2011-05-25 15:24:46,148 de.sub.goobi.Metadaten.Metadaten.BildErmitteln(?:?)
        java.lang.NullPointerException
ERROR 2011-05-25 15:24:46,148 de.sub.goobi.Metadaten.Metadaten.BildErmitteln(?:?)
        java.lang.NullPointerException

Related branches

lp:~ralf-claussnitzer-deactivatedaccount/goobi-production/bug-788160
Henning Gerhardt: Approve
Diff: 92 lines (+61/-2)
2 files modified
WEB-INF/web.xml (+8/-2)
src/org/goobi/production/ImageIOInitializer.java (+53/-0)
Revision history for this message
Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount) wrote :

Goobi converts raw TIFF images to PNG as browsers are not able to display TIFF-Files. If the conversion succeeds, it tries to save the PNG files under <webroot>/pages/imagesTemp. The exception might be thrown because of insufficient access privileges. Can you confirm that?

Changed in goobi-production:
status: New → Incomplete
Revision history for this message
Jennie Fletcher (jennie-l-fletcher) wrote :

That's right, the problem is that the conversion from TIFF to PNG for display is failing, so the temp image is never created. The application has the privileges to write to the directory where the temp images are being put.

To clarify I have also have the following jars in my tomcat lib (though I am aware they are also in the WEB-INF/lib so this shouldn't make any difference). This problem is also happening with the Intranda edition.

jai_codec-1.1.2_01.jar
jai_core-1.1.2_01.jar
jai_imageio-1.0_01.jar

I am using:
java version "1.6.0_25"
tomcat version 6.0.32

It does seem to indicate that it's failing to find one of the jai image converters, so it looks like something that may be related to the system configuration required (possibly a missing dependency?).

Revision history for this message
Frank-Ulrich Weber (fuw) wrote :

I have the same problem running Goobi on a Windows machine.

Can you confirm that?

I never ever had this problem running Goobi on various linux machines.

Revision history for this message
Jennie Fletcher (jennie-l-fletcher) wrote :

I'm running ubuntu version 11.04

Revision history for this message
Frank-Ulrich Weber (fuw) wrote :

x86 or x64

Revision history for this message
Jennie Fletcher (jennie-l-fletcher) wrote :

Having talked to Steffen and Jan at Intranda, they thought it might be related to the tomcat version I am using.

I have tested the exact same code on tomcat version 6.0.24 and Tiffs are now being converted and displayed correctly.

It looks like this bug is caused by updates made to tomcat between versions 6.0.24 and 6.0.32.

Revision history for this message
Frank-Ulrich Weber (fuw) wrote :

Adding the attribute appContextProtection="false" to
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" appContextProtection="false"/>
in the server.xml solves the problem with tomcat 6.0.32,
but at the moment I don't know if it creates a memory leak.

Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount)
Changed in goobi-production:
importance: Undecided → High
status: Incomplete → Confirmed
Revision history for this message
Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount) wrote :

This looks like a bug in the code used to scale images:
http://bazaar.launchpad.net/~slub.team/goobi-production/1.6/view/head:/src/de/sub/goobi/Metadaten/MetadatenImagesHelper.java#L208

Maybe the call to ContentServer Servlet fails or delivers an unexpected result.
On my test server this bug also seems to crash Tomcat.

One has to ensure ContentServer Servlet is configured accordingly.
From GoobiConfig.properties:
# -----------------------------------
# GoobiContentServer for pdf generation
# sample: http://localhost:8080/Goobi/gcs/gcs?action=pdf\&metsFile=
# if empty, internal GoobiContentServer will be used, make sure
# to configure it in goobiContentServerConfig.xml
# -----------------------------------

The default configuration in goobiContentServerConfig.xml states a Windows based path for temporary files:
 <contentCache useShortFileNames="true" useCache="false" path="C:/Goobi/cache" size="30"/>

Can somebody please check if this may be the cause?

Revision history for this message
Frank-Ulrich Weber (fuw) wrote :

I think the configuration in GoobiConfig.properies only affects the PDF-Export not the images in the metadate editor.

In your example for the contentServerConfig.xml the cache is disabled (useCache="false") an therefore the wrong path doesn't matter.

In newer tomcat versions > 6.0.24 there is a new default entry in the server.xml
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
that causes (if attribute appContextProtection="true", that's it by default) the error.

Look here:
http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

Revision history for this message
Steffen Hankiewicz (steffen.hankiewicz) wrote :

Thanks Frank-Ulrich for providing this link. I didn't know that.
It seems to be a server-wide configuration. Is there an application specific configuration possible too, or do I miss something here? If not, this issue can be closed IMHO.

Revision history for this message
Jennie Fletcher (jennie-l-fletcher) wrote :

If the application doesn't run under the latest tomcat without application specific modification surely that's a bug? Also the fact that this error is thrown on a JreMemoryLeakPreventionListener indicates it's because there may be a memory leak somewhere, which should be investigated. Thoughts?

Revision history for this message
Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount) wrote :

Newer versions of Tomcat are generally more strict with the specification. However, the JRE Memory Leak Prevention Listener makes use of some SUN JVM specifics when setting the gcDaemonProtection option.

Quote from http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html

gcDaemonProtection "Enables protection so that calls to sun.misc.GC.requestLatency(long) triggered by a web application do not result in a memory leak. Use of RMI is likely to trigger a call to this method. A side effect of enabling this protection is the creation of a thread named "GC Daemon". The protection uses reflection to access internal Sun classes and may generate errors on startup on non-Sun JVMs. The default is true."

Revision history for this message
Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount) wrote :

I suspect the special Tomcat class loader hierarchy as a root cause here. The JREMemoryLeakPreventionListener triggers calls and class loading prior to web application context start. It issues, in particular, java class loading for javax.imageio.ImageIO while starting the Server component.

Standard Java class loading mechanism use delegation along a class loader hierarchy. Servlet container loading, which support context per web application, differs slightly from this delegation rule: http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html This, however, raises some memory leak issues because of class loader pinpointing: https://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java JREMemoryLeakPreventionListener gets run on Server component initialization as a workaround for some of these issues.

This Goobi bug possibly is triggered by special image library class loading within the Content Server library (lib/ics_0.0.4.jar). The source code of this library is not available by now.

As a workaround, appContextProtection has to be disabled in JREMemoryLeakPreventionListener (server.xml) as described by comment no. 9:
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" appContextProtection="false"/>

Changed in goobi-production:
status: Confirmed → Invalid
Revision history for this message
Ralf Claussnitzer (ralf-claussnitzer-deactivatedaccount) wrote :

ImageIO library makes for a special condition here. It's global registry interferes with JREMemoryLeakPreventionListener. According to http://tomcat.10.n6.nabble.com/Problems-with-ImageIO-td2073212.html implementing a custom listener for start-up can solve the problem, without having to alter Tomcat default measures.

Changed in goobi-production:
status: Invalid → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.