1 Reply Latest reply on Nov 12, 2007 12:13 PM by manik

    Serialization

    fredrikj

      Hi.

      We have been hunting hot spots in our application which relies heavily on the jboss cache. One hot spot that occurred was in the actual serialization of the objects. We got rid of the hot spot by using jboss serialization instead of the regular java serialization.

      In short we changed the ObjectOutputStreams in the JavaObjectStreamFactory class to use JBossObjectOutputStreams instead (and input of course).

      Now, we cannot be 100% sure that we gained cpu by doing this. It is possible that the hot spot just got spread out over multiple methods so the hot spot disappeared but we lost cycles over all. But the hot spot was removed from the list nevertheless.

      So my question is, is there a reason why jboss cache is not using jboss serializing for serializing objects? Since jboss serializing takes pride in being x times faster then vanilla java serializing, wouldn't this be a desirable element to include in the cache?

        • 1. Re: Serialization
          manik

          We did ship with JBoss Serialization at one point, but turned this off after a while, prompted by some reports that JBoss Serialization was hurting overall performance (and adding an extra jar to the distro).

          An explanation from an email conversation I had with Clebert Suconic, the JBoss Serialization maintainer:

          "Clebert Suconic" wrote:


          in recent Java5 (they have ported the fix to java4 as well) they have
          fixed the synchronized caching what was one of the advantages of jbser.
          (don't know if pressured by jboss-serialization or not).



          So basically the main benefit of JBoss Serialization is now in more recent patch releases of Sun's JDK. In the end though, I'm sure there are some use cases (depending on the number and type of objects being serialized) where JBoss Serialization may perform better.