The configuration file of the OpenSSH server /etc/ssh/sshd_config contains an entry for the SFTP subsystem:

Subsystem       sftp    /usr/libexec/openssh/sftp-server

Seems sftp-server allows the loglevel to be set:

# /usr/libexec/openssh/sftp-server -h
usage: sftp-server [-he] [-l log_level] [-f log_facility]

The manpage contains all the available loglevels. I tried adding the parameter “-i VERBOSE” in my sshd_config, but this fails, as my version of OpenSSH does not allow command-line arguments here. I’m using Centos 5.6 which comes with OpenSSH 4.3. Command-line parameter are available since OpenSSH 4.4 (http://www.openssh.com/txt/release-4.4)

So I created a file /usr/libexec/openssh/sftp-server-custom containing:

“/usr/libexec/openssh/sftp-server -i VERBOSE” and altered the line in sshd_config to:

Subsystem       sftp    /usr/libexec/openssh/sftp-server-custom

Restart or reload the ssh server so the configuration change gets active, and it starts logging nicely.

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.

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.

• daf59ba0dc0eadf1f
• ef4f741c36b35d548
• 2e70c16ebcfc99175
• 24569c8e647420642
• f4fd999efcdfada5f
• 78731c2bb5cebbf36
• 03b00a9db1f53b189
• e2c10bf2db2015030

Jeder Code geht natürlich nur einmal.

Was soll ich jetzt bedenklicher finden? Das der Iran vielleicht auch an einer solchen Waffe arbeitet? Oder das ein Land voller religiöser Wirrköpfe schon viele tausende davon besitzt? Ein nicht unerheblicher Teil der US Bürger lebt in dem Glauben, dass Jesus in den nächsten Jahren zurück auf die Erde kommen wird, dass das Ende der Welt nahe ist. _DAS_ finde ich bedenklich.

Zitat: “Da Daten anders als Autos oder Handys keine Sachen sind, kann man sie nicht stehlen.” (Quelle)

Was Frau Merk damit ausdrücken will ist ja klar, das es nicht schlimm ist die Daten anzukaufen, weil es ja keinen Diebstahl gab und es sich damit nicht um Hehlerware handeln soll. Einen Diebstahl gab es wohl wahrscheinlich wirklich nicht, denn wer stiehlt schon Daten physikalisch? Die Daten wurden unrechtmässig vervielfältigt, und damit handelt es sich zwar um keinen Diebstahl, aber um eine Verletzung irgendwelcher Schutzrechte, also z.B. dem Urheberrecht.

Aber schön zu sehen wie Politiker sich rhetorisch alles so drehen wie es gerade gebraucht wird. Mal schauen ob Frau Merk diese Aussage nochmal überdenkt, wenn die Schweizer ihre Drohung wahr machen, alle Konten deutscher Amtsträger in der Schweiz offen zu legen.

http://www.taz.de/1/zukunft/umwelt/artikel/1/126000-faesser-atommuell/

Das “Versuchsendlager” Asse säuft immer schneller ab

Da laufen jetzt also über 11 Kubikmeter Wasser pro Tag in das Endlager, und irgendwann läuft es auch wieder raus und nimmt das ein oder andere Bisschen Plutonium oder sonstwas mit. Super! Ob es in der Gegend noch CDU Wähler gibt?

Da sieht man mal wieder was passiert wenn die Politik nur aus Handpuppen besteht, die Lobbyistenärme im Arsch stecken haben. Die Energiekonzerne freuen sich über günstige Energie, denn die Entsorgung bezahlt natürlich der Steuerzahler: http://www.heise.de/tp/blogs/2/126666

Vielleicht sollte man solche Dinge mal mit berücksichtigen, wenn man über die Kosten der Atomkraft spricht, aber unsere Volksverräter reden ja lieber den Lobbyisten nach dem Mund, statt mal selbst das Gehirn einzuschalten.