|A problem with with the MarshalledObject solution is that it generates a |much larger byte array. As this array in embedded into the bean's CORBA |reference, the result is a very large IOR. (I don't know what goes into |a MarshalledObject, but it appears that the codebases for a whole hierarchy |of class loaders are all there.)
Interesting, I will have to look at the stuff that gets serialized there. We do have the deserializing classloaders right here, so I guess that the code I gave you (the rickard code) will work just fine. |I still have to assess the impact of these bloated IORs in the (currently |bad) performance of my IIOP container invoker in the bank test. Right now Obviously the more bloated the byte array the more work and time is spent in the deserialization stacks. Just fyi, the optimized contaienr (no invocation stack) runs at 0.05ms on standard machines when you add the container you can go up to 0.5ms which means that 90% of the time is spent on the invocation stacks. Optimize that stack and you are gaining a lot of performance. Can we get solid data on the byte[] versus MO times? |there is no optimized path for local IIOP invocations. Doing all IIOP |invocations "remote style" is probably the worse time-eater. After I add |an optimized path for in-VM invocations (hopefully today) it should be |easier to tell how bad bloated IOR are. See the times above, a factor of 10, the point you made that MO tends to be a pig is interesting, I need to know whether it is real. marcf | |Regards, | |Francisco | |> |> marcf |> |> |-----Original Message----- |> |From: marc fleury [mailto:[EMAIL PROTECTED]] |> |Sent: Wednesday, November 21, 2001 11:05 PM |> |To: David Jencks; [EMAIL PROTECTED] |> |Subject: RE: [JBoss-dev] Classloader puzzle |> | |> | |> |> |> ||> This code is in |org.jboss.ejb.plugins.iiop.server.IIOPContainerInvoker, |> ||> under contrib/iiop. Insertion/extraction of the PK is done |through the |> ||> methods toByteArray() and toObject(). Each of these methods has two |> | |> |professor, |> | |> |rereading this, if you set the context classloader correctly then |> |the MarshalledObject works from these guys hence no problem. the |> |toByteArray() and toObject() needs to work with the context |class loader. |> | |> |So |> |1- make sure the context cl is set properly (system.out its hash |> |when you enter the method), make sure it is the hash of the cl |> |that created the container (compare to the cl printouts) |> | |> |2- make sure your code uses the context cl when deserializing, it |> |seems that the cl that is asked for the application is the system |> |cl and that indicates that the io deserialization is asking the cl |> |that loaded the system class (the container invoker in this case). |> | |> |marcf |> | |> ||> implementations, one of them commented out. The commented out |> ||> implementation "solves" the problem in the way described above. |> ||> |> ||> Suggestions are very welcome! |> ||> |> ||> Cheers, |> ||> |> ||> Francisco |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> _______________________________________________ |> ||> Jboss-development mailing list |> ||> [EMAIL PROTECTED] |> ||> https://lists.sourceforge.net/lists/listinfo/jboss-development |> ||> |> ||> |> || |> ||_______________________________________________ |> ||Jboss-development mailing list |> ||[EMAIL PROTECTED] |> ||https://lists.sourceforge.net/lists/listinfo/jboss-development |> |> |> _______________________________________________ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
