I?ve been working for a while with an IIOP-accessible EJB on JBoss 2.3.5. This EJB is been used by a .Net client (IIOP.NET is my CORBA implementation for .Net) and the performance has been quite acceptable.
In order to try out the last version of JBoss, I downloaded and installed the version 4.0. Then, I deployed the same EJB (without any change) and suddenly the performance dramatically decreased (various orders of magnitude). Since the business logic of the EJB is the same, I guess that the problem could be the marshalling and demarshalling of the parameters involved (in my case, they are return values).
My question is whether JBoss 4.0 has performed any modifications on the IIOP protocol stack so that the performance is degraded.
Thanks in advance.
You probably mean JBoss 3.2.5 rather than JBoss 2.3.5, right? (IIOP support appeared for the first time in 3.0.0.)
Anyway, two IIOP-related changes may cause a performance decrease in 4.0:
1) jacorb.jar was updated to (a patched version of) JacORB 2.2. A performance decrease has been reported for JacORB 2.2. The degradation shows up when JacORB tries to access unset configuration properties:
2) Portable interceptors were added to deal with transaction context propagation and with security over IIOP (CSIv2). Usage of request interceptors in JacORB effectively disables the local call optimization that would otherwise happen on in-VM calls. This has a negative effect on the performance of applications that do in-VM calls to (remote interfaces of) IIOP-enabled EJBs. If you don't need transaction demarcation/propagation and security over IIOP, then you get rid of the negative effect by commenting out the tx and csiv2 interceptors in iiop-service.xml.
I've managed to disable the transaction demarcation over IIOP as stated in the file iiop-service.xml. However, i'm unable to do the same with the security attribute service interceptors. If I comment out the initializers:
Jboss throws an exception when starting up:
2005-01-03 19:06:44,419 ERROR [org.jboss.ejb.StatefulSessionContainer] Initialization failed jboss.j2ee:jndiName=Interest,service=EJB
any idea ?
By the other hand,is it possible to substitute JacORB by other CORBA implementation?. If so, could you possibly indicate the requirements that must be satisfied by the new CORBA implementation and the steps involved?
Thank you very much.
The PolicyError exception will go away if you comment out just the SASInitializer, which is the one that installs a request interceptor and thus affects performance. The CSIv2Initializer must remain enabled, as it defines a POA policy that is used at EJB deployment time. This initializer does not install a request interceptor, so it should not cause a decrease on performance.
There is another problem, though. Due to a coding oversight in releases 4.0.0 and 4.0.1 of JBoss, commenting out the just the SASInitializer will result in another exception. No exception will be thrown at EJB deployment time, but you will get an exception whenever the EJB receives a remote call. This problem has been fixed in CVS and won't be present in JBoss 4.0.2.
Right now what you can do is get Branch_4_0 from CVS and build JBoss 4.0.2beta, which works properly with no request interceptors at all (with SASInitializer and Tx interceptor initializers commented out).
the command I used is:
cvs -d :pserver:firstname.lastname@example.org/cvsroot/jboss co -r Branch_4_0 jboss-4.0
It begin to download a lot of files, but comparing these files with its its webview, there are many differences.
The file build.xml reference to a non-existen file, for example ../tools/etc/buildmagic/buildmagic.ent
Furthermore, in webview there are some folder that
they are not download with command above.
I'm running under windows 2000. When I execute build.bat nothing happend. If a try to execute build.xml with ant, an error message appears saying that buildmagic.ent file not found.
What am I doing bad?
Thanks and regards
1) Use the USER FORUMS
2) DO NOT CROSS POST - post your question on multiple topics
3) DO NOT HIJACK - post an unrelated question on somebody else's topic