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