3 Replies Latest reply on Apr 23, 2007 11:29 AM by Hasan Ceylan

    Compression in Remoting

    Hasan Ceylan Newbie


      I am in a very bad position. I have an application that two jboss'es makes EJB3 calls to each other. I see that the data going forth and back takes up a lot of bandwidth causing a bottleneck that my system suffers.

      I saw a previous post of about CompressingMarshaller and CompressingUnMarshaller and wanted to give it a try. I was so happy with the result in the beginning. But my happiness turned into sadness after some time.

      Because, I see in the logs errors like "not in GZIP format" on the server side and "254/0/62 (random number), wrong version, version 1,2 supported" like messages on the client side.

      This might be just a small issue in the way related (Un)Marshallers work. We would really appreciate any help on the issue.

      I had dived into the source before and did indeed submited couple of fixes to EJB3 and remoting project.

      If I am given any directions, I might help solve the problem for all.

      Thank you and once again, I request your immediate help on the issue.

      Hasan Ceylan

        • 1. Re: Compression in Remoting
          Ron Sigal Master

          Hi Hasan,

          Based on the previous thread that you mentioned, I'm afraid that the CompressingMarshaller/UnMarshaller must be broken, and I haven't had the opportunity to find out why.

          The socket transport prefixes each request and response with a version byte, and if you see a message complaining about an incorrect version, it probably means that that the CompressingUnMarshaller is returning in incorrect byte.

          If you can figure out why the CompressingMarshaller/UnMarshaller isn't working, that would be great.


          • 2. Re: Compression in Remoting
            Hasan Ceylan Newbie

            Hello Ron,

            Thanks for the reply. My environment is, an external tomcat web app making EJB3 calls to JBoss server.

            With my limited knowledge, I have a couple of guesses. Tomcat by nature has multi user environment. That means multiple coversations happen at the same time. I think remoting tries to reuse open connections. Could there be an issue with multiple conversations serialized into the same socket connection and this causes an unsynchronized status between the client and server socket that is only exposed when compression (or may be any other hooks) attached on both ends?


            • 3. Re: Compression in Remoting
              Hasan Ceylan Newbie

              One more thing to add...

              I also see not in GZIP format on the server side...

              Hasan Ceylan