Misleading text in Inspector

[Lauri Liinat <La...@microlink.ee>]

Hi all,

my concern is as follows: on the "Engine" tab of Inspector,
there is the following text:

    "The serialized state of the application engine
     (the size of this is relevant for application servers
     which support clustering)."

This explanation as well as the size of the serialized Engine alone
is incomplete information since it's not the only serialized object
graph
that affects cluster state replication (as well as memory requirements
with most servlet containers) via size - an app developer also needs
to consider and therefore easily monitor the total size of all
Persistent
Properties per Session as recorded by SessionPageRecorder. In large
apps, the total size of Persistent Properties may easily exceed the size
of Visit (which is serialized with the Engine) tenfold and more.

So it would be _extremely_ useful if the Inspector was able to not only
list all Persistent Properties as name / value pairs but also show their
total serialized size. This feature would also instantly uncover bugs
where app developer is recording a change on an object that is not
serializable, at the very moment the Engine tab of Inspector is viewed.

Such feature would be simple to implement yet an invaluable tool to
assess Memory Requirements for single-node servers and Replication
Overhead for clustered servers.

Comments anyone?

regards,
lauri

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

RE: Misleading text in Inspector

["Howard M. Lewis Ship" <hl...@comcast.net>]

The Inspector is due to a serious overall.  Perhaps you could start a page on the Wiki to describe
the current implementation's many shortcomings, and fixes.

The text is misleading; however the engine and the Visit represent the lion's share of mutable
server-side state. Persistent page properties do not change often, and are (usually) simple,
immutable wrapper objects: String, Integer, Date, etc.  The engine, and with it the Visit, are
stored into the HttpSession after the majority of requests, which (in a cluster) will trigger
serialization and propogation, so they are the area of greatest concern (where concern is meritted)
in this area.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com


> -----Original Message-----
> From: Lauri Liinat [mailto:Lauri.Liinat@microlink.ee] 
> Sent: Wednesday, June 16, 2004 11:05 AM
> To: tapestry-dev@jakarta.apache.org
> Subject: Misleading text in Inspector
> 
> 
> 
> Hi all,
> 
> my concern is as follows: on the "Engine" tab of Inspector,
> there is the following text:
> 
>     "The serialized state of the application engine
>      (the size of this is relevant for application servers
>      which support clustering)."
> 
> This explanation as well as the size of the serialized Engine alone
> is incomplete information since it's not the only serialized object
> graph
> that affects cluster state replication (as well as memory requirements
> with most servlet containers) via size - an app developer also needs
> to consider and therefore easily monitor the total size of all
> Persistent
> Properties per Session as recorded by SessionPageRecorder. In large
> apps, the total size of Persistent Properties may easily 
> exceed the size
> of Visit (which is serialized with the Engine) tenfold and more.
> 
> So it would be _extremely_ useful if the Inspector was able 
> to not only
> list all Persistent Properties as name / value pairs but also 
> show their
> total serialized size. This feature would also instantly uncover bugs
> where app developer is recording a change on an object that is not
> serializable, at the very moment the Engine tab of Inspector 
> is viewed.
> 
> Such feature would be simple to implement yet an invaluable tool to
> assess Memory Requirements for single-node servers and Replication
> Overhead for clustered servers.
> 
> Comments anyone?
> 
> regards,
> lauri
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org