Castor and VFS issue?

[trefsahl]

I'm using castor 1.2 to marshal beans running on JBoss AS 5.1.0.

Unfortunately JBoss throws this error "after a while" (i.e. having loadrunner running for 30 mins or so). This "locks" everything and jboss stops responding to my remote EJB calls (I get socket-io errors on my client).

A workaround could be to extract the castor.core.properties file and put it into the lib folder to avoid the ZipFileWrapper.

 WARN  Configuration   []: Failed to load configuration from classpath: /org/castor/core/castor.core.properties
java.lang.RuntimeException: Failed to read zip file: org.jboss.virtual.plugins.context.zip.ZipFileWrapper@121d3b44 - /opt/redhat/jboss-eap-5.0/server/sip/deploy/sip.ear
        at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:629)
        at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:774)
        at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChild(ZipEntryContext.java:818)
        at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.createChildHandler(ZipEntryHandler.java:192)
        at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:690)
        at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild(ZipEntryHandler.java:166)
        at org.jboss.virtual.plugins.context.DelegatingHandler.getChild(DelegatingHandler.java:107)
        at org.jboss.virtual.VirtualFile.findChild(VirtualFile.java:468)
        at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile(VirtualFileURLConnection.java:106)
        at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile(VirtualFileURLConnection.java:118)
        at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:93)
        at java.net.URL.openStream(URL.java:1010)
        at org.castor.core.util.Configuration.loadFromClassPath(Configuration.java:186)
        at org.castor.core.util.Configuration.loadDefaultProperties(Configuration.java:136)
        at org.castor.core.CoreConfiguration.<init>(CoreConfiguration.java:49)
        at org.castor.xml.XMLConfiguration.newInstance(XMLConfiguration.java:58)
        at org.castor.xml.AbstractInternalContext.<init>(AbstractInternalContext.java:121)
        at org.castor.xml.BackwardCompatibilityContext.<init>(BackwardCompatibilityContext.java:45)
        at org.exolab.castor.xml.MarshalFramework.<init>(MarshalFramework.java:185)
        at org.exolab.castor.xml.UnmarshalHandler.<init>(UnmarshalHandler.java:310)
        at org.exolab.castor.xml.Unmarshaller.createHandler(Unmarshaller.java:362)
        at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:708)
        ....

Any idea?

[jaikiran]

Tor,

Welcome to the forums.

This issue looks similar to http://community.jboss.org/thread/152676. See if the property mentioned in that thread, helps you too.

[trefsahl]

The property mentioned, jboss.vfs.forceCopy, is already set to true (by default). 

[trefsahl]

Workaround solution:

We just noticed the vfs temp folder was growing very fast. All the jars from within my ear are put there many times each minute. With this in mind we tried to deploy our application (ear) exploded and this seems to work. No more jars in the vfs temp folder and no more VFS errors with castor. This raises two questions:

1. Why does the VFS explode my ear file to the vfs temp folder so often?
2. Even with the exploding "bug" the vfs should still be able to read the contents of the exploded files without throwing the "IO" exception.