I'm having some issues with Slide and doing PUTs of large files. Environment: Windows 2000 SP 4; Sun 1.4.2_02 JDK; Postgres 7.4.1 as Cygwin service; Tomcat 4.1.30; Jetty 5.0RC0; Jetty 4.2.17; Slide CVS HEAD from 2 May 04; Cadaver 0.17.0 as WebDAV client.
When testing PUTs of 9.5 Mb files to the Postgres repository, I receive the following: 04 May 2004 13:34:18 - org.apache.slide.util.event.EventLogger - INFO - Recieved vetoable event with name 'content:create': org.apache.slide.event.ContentEvent[content uri=/files/petsoar-app.zip contentType=application/zip] java.lang.OutOfMemoryError org.apache.slide.common.ServiceAccessException: Service [EMAIL PROTECTED] access error : java.lang.OutOfMemoryError at org.apache.slide.store.AbstractStore.createRevisionContent(AbstractStore.jav a:1311) at org.apache.slide.store.ExtendedStore.createRevisionContent(ExtendedStore.jav a:393) at org.apache.slide.content.ContentImpl.create(ContentImpl.java:552) This happens with any web container/version listed above. Using -Xmx512m allows the upload, but it seems a lot of memory for a 9.5 Mb file. As expected, memory requirements increase if you need a 20 Mb file etc. We will routinely upload even larger files, so using high -Xmx values isn't really a solution. Additionally, a 9.5 Mb upload under Tomcat does not cause the error when using an older (circa Jan 04 CVS) Postgres JAR version. More recent JAR versions fail with much smaller uploads. Interestingly, there seems to be some other fragility with Postgres JAR versions. Using an older (circa Jan 04 CVS) Postgres JAR I was able to upload 100 Kb files under Tomcat. With either Jetty version, Slide would fail with a content empty error as soon as the file size exceeded 8,191 bytes. Upgrading to a newer version (pg74.213.jdbc3.jar or pgdev.301.jdbc3.jar) of the Postgres JAR fixed this on Jetty. Two Slide-specific reasons we'd like to use Postgres include its tsearch2-based free-text search facility and its inherent support for a cluster of servers running Slide with the same backend. The tsearch2 module provides automated index updating when the database is updated, which is very appealing. The nice thing is that all containers work VERY WELL with any sized files when using the file system repository. As this may be a necessary fallback for our project, could anyone advise if the Slide file system repository has issues in an NFS environment? What approach to people take to Lucene/search in such an environment? Any advice greatly appreciated. Thanks Ben PS: Further to my earlier email, I had good success integrating with Slide's security and also using EmbeddedDomain to expose Slide's server API as a Spring-managed bean. Thanks to the Slide developers for making it so easy to integrate! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
