Created attachment 516932 [details]
server.log

Can you attached the modeshape configuration file: modeshape-config.xml

Created attachment 517127 [details]
modeshape-config.xml

I believe that bug 724542 comment 6 was actually intended to land in this bug. :-) Am I right, Van?

You are absolutely right.

Now that BRMS ER2 is out, can you retest this?   After talking with rhauch, I
used the latest modeshape code in SOA and publish 16k and 22k size files, which
one was a jar, with no issue.   And because the same engine and connectors in
BRMS are also in SOA, we should have seen the problem, but I didn't.

Nothing new with BRMS 5.2.0.ER2. The exception can be easily reproduced using brms-standalone package, installing MS according to BRMS Administration Guide. Default HSQL database was used, modeshape-config.xml is identical to attachment 517127 [details].

Kurt, we need someone from the brims group to create a test case outside of using the client tool to validate this issue.     Our test cases  are not seeing this issue, nor is it an issue in SOA.

Jirka, would you please take a look at this when you are back from your PTO? We need a better test case that would reproduce it for Van and his team. 

The current test case doesn't seem to do the trick.

This is for ModeShape.Candidate only.

Van, Kurt, if you find it difficult to reproduce this bug, please follow this step-by-step 5 minutes procedure. Someone has to decide if it is a bug in ModeShape or Guvnor, or if it's just a misconfiguration. Don't hesitate to contact me with any questions regarding the bug reproducing.


For more details on steps 2-5, see http://documentation-stage.bne.redhat.com/docs/en-US/JBoss_Enterprise_BRMS_Platform/5/html-single/BRMS_Administrator_Guide/index.html#sect-install-modeshape


1. install BRMS 5.2.0.ER2 standalone package
============================================
$ wget --no-check-certificate https://hudson.qa.jboss.com/hudson/view/BRMS/job/brms-5.2/lastSuccessfulBuild/artifact/signed/jboss-brms-standalone.zip
$ unzip jboss-brms-standalone.zip


2. install ModeShape into default profile
=========================================
$ cd brms-standalone-5.2.0/modeshape/ && ant


3. setup users
==============
$ cd ../jboss-as-web/server/default/
$ vi conf/props/brms-users.properties # just uncomment the two users


4. switch to ModeShape repository
=================================
$ cd deploy/jboss-brms.war/WEB-INF/
$ vi components.xml # just delete the Jackrabbit properties and uncomment ModeShape properties


5. remove unused JARs
=====================
$ cd lib/
$ rm jackrabbit-* hibernate-* lucene-core-2.4.1.jar jcr-2.0.jar


6. start the server
===================
$ cd ../../../../../..
$ ./bin/run.sh -c default


7. reproduce the bug
====================
- log into Guvnor by opening http://localhost:8080/jboss-brms/ and providing admin:admin credentials
- do not import the sample repository when asked (click 'No thanks')
- expand the Knowledge Bases section on the left-hand panel
- issue Create New > Create a file.
  enter file name
  type 'properties' as the file extension
  click 'OK'
  a new asset opens
- try uploading the reproducer file from attachment 516929 [details]
  the attempt should end with an error box saying 'Unable to upload the file.'
  an exception can be found on the console output and server.log:

10:30:51,865 ERROR [[AssetFileServlet]] Servlet.service() for servlet AssetFileServlet threw exception
java.nio.channels.ClosedChannelException
	at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:109)
	at sun.nio.ch.FileChannelImpl.size(FileChannelImpl.java:320)
	at org.modeshape.graph.property.basic.FileInputStreamBinary.getSize(FileInputStreamBinary.java:81)
	...

Created attachment 518482 [details]
Simple Test to load nt:file node

Attached I've added a jsp that performs adding a text file that is larger than the 10240 that is used by the Gov. test.     This is a simple test that add, finds and deletes the nt:file node.   I was unable to recreate the issue.    So that we can get to the details of how the Gov. logic is actually performing its task, how can I change this logic to replicate what Gov. is doing?

Created attachment 518634 [details]
modified JSP test

Attaching a slightly modified JSP test case. I've added a parameter 'file' to specify a file from which to read data for the node. Most important change is that I'm using ValueFactory.createBinary(java.io.InputStream stream) to create the value for the jcr:data property of the sample node.

To invoke the exception, try a request similar to

> http://localhost:8080/test.jsp?repo=brms&file=/tmp/test.txt

where /tmp/test.txt can have an arbitrary content (e.g. "test").

Van, do you have any idea how to avoid having the Binary's InputStream closed at this point:

> org.modeshape.connector.store.jpa.util.Serializer.serializeProperty(Serializer.java:315)

Or is this way of using the API not intended and so Guvnor needs change the client code?

With your changes I've been able to reproduce the issue in a junit test, and the solution is being worked on.

Thanks,  Jiri.

Marked as not needing a release as this issue appears to be between internal builds.

If it should have a release note, please set the technical_not flag to '?'

thanks
- Lee

The fix has been committed to modeshape 2.5.x branch:  COMMIT ID:  b33eadc2047e18247938

There was an issue in which the binary file was getting serialized twice, but the second try would fail because the stream was closed after the first serialization.

Transferring this to MODIFIED state so that it can be pick up by the QA contact for verification.

Although Modeshape is downgraded to TP, this is not an acceptable issue to have in the product.

As stated in COMMENT 16, this issue has been fixed and committed to ModeShape.  It should be picked up in the next build.

Fix verified in BRMS 5.2.0 ER3.