Compression marshalling

[ganesh_sn]

Hi,
Can anyone kindly tell what configuration code i need to add in which jboss xml configuration file to enable compression marshalling.

Is there any alternative declarative way possible ?

Regards,
Ganesh.

[ron_sigal]

Hi Ganesh,

The answer varies from service to service. E.g., JBossMessaging, EJB2, EJB3. Which are you interested in?

[ganesh_sn]

Hi Ron,

Sorry that i didn't mention more details. Here is the details:

- We are using a swing based application
- We use deploy beans ( entity, session and message )
- we use EJB 1.1 and 2.0
- Application server is JBoss 3.2.5 and we are planning to migrate to 4.2.x

Requirement:

We want to compress the data( in the wire ) when it is transferred between the application and the server.

Kindly suggest the solution for the same.

Best Regards,
Ganesh.

[ron_sigal]

Hi Ganesh,

Application Server 3.2.5 doesn't use JBossRemoting, and I don't know if there's even a compression marshaller available for that version.

When you're ready to upgrade to AS 4.2, let me know and I'll help you with the Remoting compression marshaller.

-Ron

[ganesh_sn]

Thanks Ron. Will update you.

Best Regards,
Ganesh.

[robert.geisler]

hi, ron,

we are using JBoss 4.2.2.GA and want to use compression for EJB2.1 and EJB3.0 invocations.


i tried to activate the compression marshaller without success. replacing the InvokerLocator of ejb3 remoting connector in /server/compression/deploy/ejb3.deployer/META-INF/jboss-service.xml

<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873</attribute>

with

<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/?dataType=serializable
 &marshaller=org.jboss.remoting.marshal.compress.CompressingMarshaller
 &unmarshaller=org.jboss.remoting.marshal.compress.CompressingUnMarshaller</attribute>

doesnt reduce the amount of data transferred (measured with WireShark: http://www.wireshark.org/).


would be very nice if you could explain me in detail how to install compression.



thanks in advance.
robert

[robert.geisler]

hello again...

i did a step back: removed "dataType=serializable" and configured my EJB3 Remoting Connector like this:

<attribute name="InvokerLocator">socket://${jboss.bind.address}:3873/
 ?marshaller=org.jboss.remoting.marshal.compress.CompressingMarshaller
 &unmarshaller=org.jboss.remoting.marshal.compress.CompressingUnMarshaller</attribute>

and yes, it works (reduced amount of data being transferred) -at least for a very, very simple EJB 3.0
(just one Remote Method that returns a String like "successful").

now i got a new issue:

2008-08-25 12:54:38,755 ERROR [org.jboss.remoting.transport.socket.ServerThread] failed
java.io.IOException: Can not read data for version 154. Supported versions: 1,2,22
 at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:674)
 at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:534)
 at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387)
 at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)

first i checked the Remoting Version i am using for client and server: both JBossRemoting Version 2.2.2.SP1 (Bluto).
because the version being read differs very often (154, 77,...) i guess that someone else (maybe another Remoting Connector?) tries to read the invocation, dont expect an compressed input and finally reads a wrong version number...?

my EJB (Remote Business Interface) just talks to a second EJB (Local Business Interface) that talks to a third EJB (Local Business Interface, reads and returns an Entity). all EJBs are EJB 3.0 and in debug modus a noticed that the above exception is thrown after my first EJB already got the data form my Entity and before my client recieves the answer from my first EJB.

finally i am kind of surprised, because the answer my client recieves is good: from the client side of view everything just seem to work -on the server side there is the exception shown above :- \

any ideas and hints what i am doing wrong?

thanks in advance
robert

[robert.geisler]

and again...

i finally got it working. no more server exceptions and the data transferred gets compressed.
using JBoss Remoting 2.2.2.SP1, it was enough to edit InvokerLocator of EJB3.0 Remoting Connector as shown in my previous posts.


but my problem still exists when using JBoss Remoting 2.4.0.GA/ 2.4.0.SP1: i get an

java.io.IOException: Can not read data for version 172. Supported versions: 1,2,22

on the server side and a

org.jboss.remoting.CannotConnectException:
Can not get connection to server. Problem establishing socket connection for InvokerLocator
[socket://192.168.1.xxx:3873/?marshaller=org.jboss.remoting.marshal.compress.CompressingMarshaller
&unmarshaller=org.jboss.remoting.marshal.compress.CompressingUnMarshaller]
java.lang.reflect.InvocationTargetException
java.io.EOFException

on the client side.

for JBoss Remoting 2.4.0.SP1 it seems to be not enough to edit InvokerLocator. so my question now is:

• what do i have to change if compression with JBoss Remoting 2.2.2.SP1 worked and with JBoss Remoting 2.4.0.SP1 dont?
  
• more basic: how do i configure compression for JBoss Remoting 2.4.0.SP1?
  by the way... i do not even know how to configure compression for EJB2.1
  -editing the Remoting Connector in /server/compress/conf/jboss-service.xml doesnt seem to be this easy...
  
  at last: i want to use JBoss Remoting 2.4.x, because i like Remoting to throw an exception instead of returning an error message,
  as described in https://jira.jboss.org/jira/browse/JBREM-813.
  if i use the servlet transport like
  
  

  <attribute name="InvokerLocator">servlet://${jboss.bind.address}:18080/servlet-invoker/ServerInvokerServlet/
   ?marshaller=org.jboss.remoting.marshal.compress.CompressingMarshaller
   &unmarshaller=org.jboss.remoting.marshal.compress.CompressingUnMarshaller</attribute>

  
  it works anyway. i dont know why it doesnt for socket transport.
  
  
  would appreciate if someone could help me out O: )
  robert[/url]

[robert.geisler]

finally... i solved it and got a solution...

i am using JBoss Remoting 2.2.2 SP8 now.
therefor a replaced the jboss-remoting.jar in my server/lib/ directory and replaced the directory jboss/remoting/ in jbossall-client.jar with the one jboss-remoting.jar (2.2.2 SP8) includes.
to throw exceptions when using http, i put "return-exception=true" as a parameter of the InvokerLocatorURL on the EJB3 Remoting Connector.

last but not least i would be interested in how to activate compression for EJB 2.1...? thanks for any advice.

kind regards
robert

[ron_sigal]

finally... i solved it and got a solution...

I like to hear that! I'm concerned, though, that the same solution didn't work for Remoting 2.4. Did you just give up on 2.4, or is there anything else you can tell me about your experiments with 2.4?

As for EJB 2.1, the situation is complicated by the fact that the Connector used by EJB 2.1, the one configured in .../server/$CONFIG/conf/jboss-service.xml, uses a special marshaller and unmarshaller: org.jboss.invocation.unified.marshall.InvocationMarshaller and org.jboss.invocation.unified.marshall.InvocationUnMarshaller. By default, org.jboss.remoting.marshal.compress.CompressingMarshaller and org.jboss.remoting.marshal.compress.CompressingUnMarshaller, which are derived from org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller respectively, will call super.write() and super.read(). But for EJB2.1, you want them to call InvocationMarshaller.write() and InvocationUnMarshaller.read() instead. The way to do that programmaticaly is

InvocationMarshaller im = new InvocationMarshaller();
CompressingMarshaller cm = new CompressingMarshaller(im);

InvocationUnMarshaller ium = new InvocationUnMarshaller();
CompressingUnMarshaller cum = new CompressingUnMarshaller(ium);

To do it declaratively, I would derive new classes from CompressingMarshaller and CompressingUnMarshaller which create instances of InvocationMarshaller and InvocationUnMarshaller. E.g.,

 public MyCompressingMarshaller()
 {
 wrappedMarshaller = new InvocationMarshaller();
 }

and

 public MyCompressingUnMarshaller()
 {
 wrappedUnMarshaller = new InvocationUnMarshaller();
 }

Then replace the "marshaller" and "unmarshaller" attributes in the definition of the "jboss.remoting:service=Connector,transport=socket" MBean in jboss-service.xml with the names of your classes.

[robert.geisler]

thank your for your reply, ron.

I'm concerned, though, that the same solution didn't work for Remoting 2.4. Did you just give up on 2.4, or is there anything else you can tell me about your experiments with 2.4?

well, as far as i can remember... i just didnt update the jbossall-client.jar with JBoss Remoting 2.4. thus my server and client didnt use the same version of Remoting which led to the exception(s) shown in my previous posts, of course.
i think the solution should work with JBoss Remoting 2.4, too (update server and(!) client libraries). but i just tried to change as less as possible... so i chose Remoting 2.2.2 SP8 O: )

thank you very much for your explanations concerning EJB 2.1. it seems to be not too complicated to me. but i will not try this out anyway, because we are going to migrate all of our EJBs from 2.1 to 3.0 in the next months. so compression is one more reason (of small importance) pro migration ; )


regards
robert

[ron_sigal]

Hi Robert,

Well, OK, I'm somewhat relieved. :)

Please let me know if you have any further problems with the compression marshaller/unmarshaller. Or even if you don't. :)

-Ron

[robert.geisler]

hello ron,

until today we didnt experience any problems with the compression.
nonetheless we didnt even evaluate the compression, we are just using it: i tested it for simple communication, but we dont know the amount of data that is reduced by compression for our application actually. well, there is no time for this these days, but if we do a review or meet any problems, i will let you know.

thanks for your attention.
regards
robert

[ron_sigal]

Thanks again, Robert.

[dmlloyd]

Suggestion for community members with free time on their hands - come up with a version of the compression marshaller that uses JZlib (http://www.jcraft.com/jzlib/). :)