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 >
