Wicket object out/in doesn't have class headers at all.
It just saves the fields. It is not meant for long time persistence also
class changes are not supported
But for cloning pages or saving it for the back button all that doesn't
matter.
if you do this in your example:
B b = new B();
writeObject(b)
this is written:
first a byte that it is a ClassDef
then a short which class it is
then field a
first a byte that it is a ClassDef
then a short which class it is
then field aprime
first a byte that it is a ClassDef
then a short which class it is
and if we would write the classname this would happen
first a byte that it is a ClassDef
then th String "B", through writeObject()
then field a
first a byte that it is a ClassDef
then String "A" through writeObject()
then field aprime
first a byte that it is a ClassDef
then String "A" through writeObject(), But write object sees that it
already have written "A" and writes only a handle (short)
So tell me where really to save something?
Remember that the normal object output stream is also meant for longer
persistence.
We just don't support that at all.
johan
On 2/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
hmmm
so if you have something like this
class A {}
class B { private A a; private A aprime; }
when you serialize B does it write the class header for A once or twice?
because i think that header has the classname so it would be output twice
no? last time i checked the header was a bit over 100bytes. so if it does
write it twice and you keep a local toc then you save yourself that second
100+ byte class header
-igor
On 2/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> So you want to add a registry of classnames->id and also save that?
> (as a TOC prepended to the beginning of the the stream is very hard
> because
> you write as you go further)
>
> But why do that? then you still write the classnames and if we write a
> classname
> it is a string. So that classname will be written only once in the
stream!
> Because the same class after that is just an handle (short i think 65K
> objects should be enough i think?)
>
> So i guess having a build in map of the first 254 mostly used classes
and
> only write a byte
> and let the rest be just as the classname (only once, the second time it
> is
> a handle)
>
> johan
>
>
>
> On 2/13/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > well you know, im just playing a devils advocate :)
> >
> > i guess you are kinda using the codec ideas we discussed - cutting out
> the
> > long class header
> >
> > here is what i would try
> >
> > i guess right now you are keeping an application map:classname->byte
> >
> > but what if we do this:
> >
> > keep an application map:classname->byte for often used classes but
only
> > use
> > lower 7 bits
> >
> > then you do what you do now - build a toc map:classname->byte if its a
> > classname that is not in the registry yet
> >
> > so if a class is in a registry you represent it as 0xxxxxxx and if its
> not
> > and is in the toc you represent it as 10000000xxxxxxxx the last 8 bits
> > being
> > the byte in the serialization-local toc map
> >
> > so then you can represent the serialization as [local toc][data]
> >
> > that way we get great compression by avoiding a lot of class headers
and
> > it
> > is stable across jvms
> >
> > -igor
> >
> >
> > On 2/12/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> > >
> > > I tried jboss didn't get me anything no speed and size improvement.
> > > when i used JBossOut en In instead of the normal out en in.
> > >
> > > I can make it work for clusterings but the bytes will be much
greater
> > then
> > > i
> > > guess
> > > because i need to write a class name instead of a short.
> > >
> > > Of course we could do that or have some method where we type all our
> > > classes
> > > and most used classes (ArrayList or something)
> > > Then it can be stable.
> > >
> > > But even clustering works fine what doesn't work. If 1 server drops
> out
> > > and all the sessions transfer to another. then it still works fine.
> > > Except when they directly use the back button at that time same time
> > >
> > > So if i set it up. Then i don't think i would use a NAS server
anyway.
> > > Because that overhead you have with that for only catching a
failover
> > and
> > > then
> > > directly a backbutton. I don't think i would use that.
> > >
> > > johan
> > >
> > >
> > > On 2/12/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > >
> > > > before we start doing all this have you guys tried the jboss
> > > serialization
> > > > thing yet?
> > > >
> > > > the problem, like johan mentioned, is that this wont work across
> jvms
> > > > because he keeps some kind of cache? but then this makes it
useless
> > for
> > > > clustering. i think whatever solution we come up with needs to
work
> > > across
> > > > jvms because i can see the page store saving pages to a nas for
fail
> > > over
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 2/12/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > for eelco: you had to disable both methods! (objectToByte and
> > > > > byteToObject)
> > > > > > For now i enabled both so that it gets tested as much as
> possible
> > > the
> > > > > coming
> > > > > > few days
> > > > >
> > > > > Ok, we can keep it in for a few days, but it has to improve
quite
> a
> > > > > bit before it's ready for real world use.
> > > > >
> > > > > * Does your code anonymous and local class instances and
traverse
> > > > > parents? Not from what I can see as you're basically doing
normal
> > > > > introspection, right?
> > > > > * Externalizable is not supported yet?
> > > > > * Whenever you put objects in a hashSet/Map you'll need to be
> ready
> > to
> > > > > catch exceptions. Wicket was trying to serializale some
Hibernate
> > > > > objects in my app (which it shouldn't, but that's exactly what
I'm
> > > > > trying to diagnose) and they throw exceptions in some occasions
> when
> > > > > they are trying e.g. to use a lazy connection. If fact, we (me
for
> > the
> > > > > diagnostics thinghy as well) probably should just use identity
> > > > > directly.
> > > > > * The code depends on SUN code directly. I'm wondering if we can
> > even
> > > > > do that considering our license, but I'm also wondering how
quick
> > > > > that'll fail. The diagnostics class depends on some quasi
> internals
> > -
> > > > > quasi because they are package private but at least they are
part
> of
> > > > > the normal JDK and seem unlikely to chance - and has a fall back
> > when
> > > > > it recognizes it is not available. It also seems that if for
> > whatever
> > > > > reason our custom serialization wouldn't be available, that's
> > > > > currently bad luck for the client as it just won't work then.
> > > > > * It needs a lot of improvement for error reporting
> > > > > * Document soon please. Or it doesn't get done at all.
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>
