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
> > > >
> > >
> >
>
