If you were surprised that your serialization code out performs Java's then
you shouldn't be. Object serialization is a well known performance
bottleneck in java systems and is to be avoided like the plague if possible.
It is so slow simply because it is so generic, the ability to simply
serialize an object and then deserialize it again so simply is amazing, and
unfortunately so tempting that it gets used in many places where it maybe
shouldn't.
For performance reasons then ObjectMessage should be avoided and
BytesMessage or TextMessage be used in its stead. Unfortunately you always
pay a performance cost for convenience.
Cheers,
David.
> -----Original Message-----
> From: Matt Cleveland [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 21, 2001 3:09 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] JBossMQ ObjectMessage performance
>
>
> I'm a little suprised that our XML serialization and parsing
> code beats the performance of Java
> serialization. Any thoughts on that?
>
> What about the RMI case where the object has already been
> serialized and deserialized once to
> communicate it through RMI? If getObject() is only called
> once is it necessary to serialize and
> deserialize the object again to make a copy since RMI has
> already made a copy of the original
> object?
>
> Just thinking out loud here, but what if the object
> implements Cloneable? I guess it would be
> invalid to clone the object because the Cloneable interface
> does not specify a deep-clone and so
> it
> wouldn't satisfy the JMS spec.
>
> Thanks for the feedback. We'll stick with TextMessage for now.
>
> Matt Cleveland
>
> --- David Maplesden <[EMAIL PROTECTED]> wrote:
> > Hi Guys, been away for the weekend (sorry).
> >
> > SpyObjectMessage is implemented the way it is because the
> spec says...
> >
> > "The JMS message interfaces provide read/get methods for
> accessing objects
> > in a message body and message properties. All of these
> methods must be
> > implemented to return a copy of the accessed message objects."
> >
> > This coupled with the fact the spec specifies only
> serializable objects may
> > be stored in an object message and you get a pretty strong
> pointer as to how
> > it is intended to be implemented.
> >
> > So there is really no way around the serializing and
> deserializing of the
> > object every time it is requested, a new copy must be
> generated. The object
> > message code can certainly be made quicker for situations
> where the object
> > from the same message is being accessed multiple times by
> storing the Object
> > and ByteArray streams instead of creating them each time.
> I didn't get
> > round to doing this because generally the object is only
> retrieved from the
> > message once by each client.
> >
> > TextMessage is so much quicker because java Strings are
> immutable you can
> > simply return the same string all the time.
> >
> > I am sure using a MarshalledObject will not help. The way
> I read the code
> > for MarshalledObject it does almost exactly the same thing
> (deserialising
> > the object from a byte array on every get) but has
> additional overhead for
> > dealing with RMI specific problems.
> >
> > Cheers,
> > David
> >
> > > -----Original Message-----
> > > From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, August 18, 2001 9:58 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [JBoss-dev] JBossMQ ObjectMessage performance
> > >
> > >
> > >
> > > I think I can fix this... But I may have to use a
> > > MarshalledObject to wrap
> > > the object to support moving the message to the consumer
> > > thread that may
> > > have a different Classloader that the publisher thread.
> > >
> > > Am I wrong here??? If the the publisher is in the same vm as
> > > the receiver,
> > > but the publisher is for example a servlet. And the consumer
> > > is a MDB. If
> > > they do not share the same classloader, I would need to use a
> > > MarshalledObject to move the object accross right?
> > >
> > > So what does a MarshalledObject acually do?? Does it
> > > serialize the object.
> > > Or does it do this only if there is need??
> > >
> > > Regards,
> > > Hiram
> > >
> > > >From: Matt Cleveland <[EMAIL PROTECTED]>
> > > >Reply-To: [EMAIL PROTECTED]
> > > >To: [EMAIL PROTECTED]
> > > >Subject: [JBoss-dev] JBossMQ ObjectMessage performance
> > > >Date: Fri, 17 Aug 2001 09:59:38 -0700 (PDT)
> > > >
> > > >Here goes with my first posting to this list.
> > > >
> > > >I've been working on performance for an application that
> > > uses Tomcat,
> > > >JBoss, JBossMQ, a couple of
> > > >queues and 1 message driven bean. Response times were fine
> > > until I started
> > > >loading the server
> > > >with multiple concurrent connections. Until I did some work
> > > with it, the
> > > >application slowed down
> > > >dramatically under reasonable loads (10 to 50 concurrent
> > > clients). One of
> > > >the problems I found
> > > >along the way looks to be a problem with the implementation of
> > > >SpyObjectMessage.
> > > >
> > > >I found that calls to ObjectMessage.getObject() and
> > > >ObjectMessage.setObjet() were increasing
> > > >significantly in execution time under reasonable loads.
> > > With a single
> > > >client the times were
> > > >around 1/10th of a second but with 10 to 50 concurrent
> > > clients they went up
> > > >to over a second. I
> > > >found that it is faster to convert the data to XML, send it as a
> > > >TextMessage and parse it on the
> > > >other side.
> > > >
> > > >I can't explain this completely because the code for
> > > SpyObjectMessage in
> > > >the version of JBossMQ
> > > >I'm using (JBoss-2.2.2_Tomcat-3.2.2) is not in the
> > > distribution (why is
> > > >this?). However, looking
> > > >at the current code of SpyObjectMessage I see some code that
> > > definitely
> > > >won't perform well. The
> > > >problem is that setObject() serializes the object and
> getObject()
> > > >deserializes it every time it is
> > > >invoked. I realize that you need a serialized version for
> > > writeExternal(),
> > > >but why must the
> > > >memory representation be serialized? In my case it was not
> > > a persistant
> > > >message anyway so
> > > >writeExternal() should never get called. Is there something
> > > in the spec
> > > >that says that each
> > > >client of an object message must get a different instance of
> > > the object?
> > > >That's the only reason I
> > > >can think of for this behavior. If it's not required by the
> > > spec (which I
> > > >don't think it is),
> > > >then the only affect of this serialization/deserialization
> > > is to slow
> > > >things down, especially for
> > > >CPU bound apps.
> > > >
> > > >The fix is trivial. Store the Object as an Object and
> serialize or
> > > >deserialize it only when
> > > >necessary in writeExternal() and readExternal().
> > > >
> > > >Am I missing something here or is this a real problem?
> > > >
> > > >Matt Cleveland
> > > >
> > > >
> > > >
> > > >
> > > >__________________________________________________
> > > >Do You Yahoo!?
> > > >Make international calls for as low as $.04/minute with
> > > Yahoo! Messenger
> > > >http://phonecard.yahoo.com/
> > > >
> > > >_______________________________________________
> > > >Jboss-development mailing list
> > > >[EMAIL PROTECTED]
> > > >http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com/intl.asp
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with
> Yahoo! Messenger
> http://phonecard.yahoo.com/
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
