When working with the Java Hessian Webservice library (resin-hessian-4.0.7.jar) I encountered the following problem:

Calling the method:

public List<EventView> listRecent(String node, int limit);

via the webservice works fine. Another very similar method on the same service fails with an exception:

public List<EventView> listRecent(int limit);

WARN [btpool0-1] 2010-12-22 21:08:16,441 log: Nested in org.springframework.web.util.NestedServletException: Hessian skeleton invocation failed; nested exception is com.caucho.hessian.io.HessianProtocolException: listRecent: expected int at 0x7a (z):
com.caucho.hessian.io.HessianProtocolException: listRecent: expected int at 0x7a (z)
at com.caucho.hessian.io.HessianInput.error(HessianInput.java:1695)
at com.caucho.hessian.io.HessianInput.expect(HessianInput.java:1681)
at com.caucho.hessian.io.HessianInput.readInt(HessianInput.java:538)
at com.caucho.hessian.io.BasicDeserializer.readObject(BasicDeserializer.java:169)

I exported the webservice via the Spring HessianServiceExporter (org.springframework.remoting.caucho.HessianServiceExporter, Spring 3.0.5). See documentation.

Calling the webservice works very simple:

HessianProxyFactory factory = new HessianProxyFactory();
EventService eventService = (EventService) factory.create(EventService.class, urlString);

I found out, that the problem is related to the version of the Hessian Protocol thats beeing used. Telling the HessianProxyFactory to use version 2 of the protocol resolves the problem:

HessianProxyFactory factory = new HessianProxyFactory();
factory.setHessian2Request(true);
factory.setHessian2Reply(true);


Hope this information can help anyone else with the same problem, took me some time searching to find out.

Nach einigen Tests mit der Blob Unterstützung in Hibernate musste ich leider feststellen, dass sich Hibernate nicht dazu eignet Blobs aus einem InputStream einzulesen, wenn die Gesamtgrösse der einzulesenden Daten nicht bekannt ist und man die Daten nicht alle im Speicher halten will.

Auf das Problem wurde ich aufmerksam als ich feststellte, dass Blobs aus einigen InputStreams nicht korrekt eingelesen wurden. Zum Einsatz kam Hibernate 3.3.2, ein Blick in die Quellen offenbart einen Fehler in dieser Version:

public static Blob createBlob(InputStream stream) throws IOException {
return new SerializableBlob( new BlobImpl( stream, stream.available() ) );
}

Hier wird eine Methode angesprochen, die die Länge der einzulesenden Daten erwartet. Fälschlicherweise wird hier .available() des Streams verwendet. Dieser Wert gibt allerdings nur die Anzahl an Bytes zurück, die garantiert gelesen werden können, bevor der Stream das nächste Mal blockiert. Der Wert hat also keine Aussagekraft bzgl. der Gesamtgrösse der Daten des Streams.

http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#available%28%29

Der Fehler ist bekannt:

http://opensource.atlassian.com/projects/hibernate/browse/HHH-4095?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel

In den aktuellen Versionen von Hibernate wurde dieser Fehler behoben, allerdings wird jetzt der ganze Stream in einen Puffer gezogen, damit Hibernate die Gesamtgröße kennt:

public static Blob createBlob(InputStream stream) throws IOException {
ByteArrayOutputStream buffer = new ByteArrayOutputStream( stream.available() );
StreamUtils.copy( stream, buffer );
return createBlob( buffer.toByteArray() );
}

So etwas ist natürlich völlig inakzeptabel, wenn man sauber mit größeren Datenmengen arbeiten will.

Ich werde nun auf die native PostgreSQL Blob API umsteigen, das nimmt mir zwar den Hibernate Komfort, ermöglicht aber mehr Kontrolle über den Speicherverbrauch.

http://www.postgresql.org/files/documentation/books/pghandbuch/html/jdbc-binary-data.html

Eine weitere Alternative wäre es, Daten aus einem InputStream zuerst in eine temporäre Datei zu schrieben, und sie erst anschließend in die Datenbank einzulesen, da dann ja die Gesamtgröße bekannt ist.