Gerard, > Hello Markus, > Thanks for your answers. > Below some additiional infos or questions.. > > I made good experience with the JOnAS team and do believe that it was a good >choice for us to use this software. > Can you say us a word on what is your software (of course if this is not still >confidential)? Computer Aided Quality Assurance (CAQ) and Failure Measurement (FMS) This software is a scalable client-/server system that you can use from 1 user on a single laptop, to N users with M dedicated servers in O locations (automatic replication between servers). > > I will look for the detailed error messages next time, maybe you can give me a >hint what the problem is (I think the > Network > > Adapter Driver is some kind of buggy or something like that). > I am afraid we will not be able to help you on that. > Have you tried on several machines, or is it always on the same one? It's quite strange. We had it on one machine only, then I downloaded 1.3.1 Beta from Sun and now I have it on that 1.3.1 machine, too. > > We are using RMI, but the problem is, that almost 99% of our customers need to run >a dedicated server (in a LAN), so I > think > > switching over to Jeremie is not the big help. > You mean you have one server per client? No, there is one server per customer and every customer has many clients in a LAN. There are some small customers that have single machines only (one client with one server on the same machine) and there are some huge customers that have three locations that they need to keep synchronized online (at the moment they are using one server on each location, synchronized with Two Phase Commit). > In any case the Jeremie optimisation is not related to that, but to local call (i.e. >within the same JVM). > If for a request you call a session bean, which then call other beans (i.e entity >beans) in the same JVM you will get a lot > of > performance improvements (until hundred times faster for local calls) using Jeremie >instead of RMI, because local call are > optimized. If you have this king of thing, it is worth to have a try... For we are planning to do this in future (we now have clients talking to entity beans, but we want to have clients to talk to session beans talking to entity beans), this might be a breakthrough. I did not think over the transfer on the server, so I though that Jeremie is no help. But now I think you are right, sure! We will try out Jeremie soon. > > I read an article over performance and they measured RMI, CORBA, DCOM etc. > > against each other. Nice: RMI and CORBA where 300% faster than HTTP (and with >this, EJB is 300% faster than Microsoft's > > SOAP, which is build on top of HTTP). But I saw that IIOP is only about 0.1% >faster than RMI, so even waiting for an > > IIOP_jonas.jar would not help. > I agree with you. I don't expect so much of RMI(IIOP) versus RMI(JRMP). > In any case Jeremie is already using IIOP except for object by values. > Which JDK are you using (because there are significative improvments from JDK 1.2 to >1.3)? > Can you give me the pointer to this article? Thanks. The artice was not online but printed in a german computer science magazine: "COMPUTERWOCHE focus" ISSN 0935-1329 Issue 4, 1999-08-20, Headline "Verteilte Systeme in den Griff bekommen / Blickpunkt: System-Management" (engl.: "Managing Distributed Systems / focus on: System-Management") Article: "internet: die Last mit dem (Performance-Frust) (engl.: "The burden of (performance) frustration") Page: 32. > > I checked out some thing in JOnAS code and there is some performance impact if >this would be changed. But it is not very > > much: With my tries (findAll with some 1000 rows) I need 42 seconds with JOnAS >2.2.4 and 40 seconds with my patches. This > > patches where mostly Jdbc-Statement-Caching and so on (It was an idea of Sun: Let >the entity bean prepare all Statements > at > > the time of creation, so you can enjoy from prepared queries in all following >actions). So even this is not the big bang. > With JOnAS we can also use the new (Enhydra ) JDBC service instead of the old >(JOnAS) one. The old one is implicitely used, > but > you can esasily switch to this new one with the current version of JOnAS. Because of >a bug in this new jdbc service, the > caching > of prepare statement was desactivated. This bug is now corrected and we have to >import the new version in the next version > of > JOnAS. You can then have a try with it. I don't think this will bring something to >try now. Ok, so I will try out if it is imported into JOnAS. > > Maybe you are so kind to forward this mail to the architect crew so they know what >I mean and we can discuss it in a > forum? > Yes, I have passed it to François, and he will discuss all that with you. Thank you, we had an inspiring disussion (with some desillusionated results). > > What do you think of this: If I manage GenIC to produce good caching code, would >you include it in your distribution of > > JOnAS? > Yes, why not, at least as an option. Well, Francois told me that this is not possible, but in last consequence, I did not understand why not. > OK, please contact me to set up something. I'll do.
