Re: Performance & Scalability Concern

[Eric Richardson]

I see that, but that sets the policy of which libraries to use at the server level. When you have a large codebase then pieces of it and the applications may use different non-binary compatible versions and this breaks the component model of J2EE. Except for the J2EE version, each app should be self reliant.

This is what I think anyway.
Eric :-)

Tom Wnuk wrote:

Actually, there is a simple method to turn it off.

>From Magnus Stenman:
"Remove parser.jar and jaxp.jar from the Orion directory and then start
Orion
with a -Dxml.parser=xerces switch. This launches Orion using the xerces
parser only. I hope it helps."

I agree, they have stepped outside the spec on this one but maybe the spec
should be changed.  How does a container process the ejb-jar.xml file if it
can't load a parser?  Hopefully, they don't have to write another one just
to conform.  It's one of those gray areas I think.

At least I don't have to 'hack' the jar files and Orion has provided a
switch.

Tom

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 7:25 AM
To: [EMAIL PROTECTED]
Subject: Re: Performance & Scalability Concern

Tom Wnuk wrote:

> I just migrated some ejb's from a Weblogic 5.1 installation to Orion.
The
> version I'm using is whatever was available from the web site about a week
> ago -- orion.jar dated 6-5-2000, v1.xx.
>
> Some observations:
>
> 1.  XML not DOM Level 2
> My beans have used XML from the beginning and I'm using xerces & xalan.
> Orion uses parser.jar from Sun which is DOM Level 1 compliant and includes
> the org.w3.* and org.xml.* packages.  This creates a problem when my beans
> try and utilize methods that are in DOM Level 2 such as
Document.normalize()
> and Node.importNode().  My temporary solution was to remove those classes
> from the parser.jar file, they're then picked up by xerces.jar which
resides
> in the classpath.

IMHO this is a problem in Orion. As far an application is concerned, they
should only be able
to see the J2EE classes. Somehow the class loader scheme needs to insulate
the
application
from the server classes. In this case XML is not part of the current J2EE
spec
and I'm hoping they won't add it. I haven't looked at an future specs on
J2EE.

Eric :-)

>
>
> 2.  Performance significantly slower
> It's not rocket science, but I clocked the elapsed time it takes to
complete
> a round trip from a test client.  Using the same code, Orion was at least
2x
> slower than WL 5.1 and did not scale well when more clients were added.
>                         WL 5.1          Orion 1.x
>         One client      .4xx            .8xx
>         Multiple (3)    .6xx            2.xx
>
> I could live with 2x slower but when adding more clients it simply gets
> worse, much worse.   For development purposes no problem, not ready for
> production use though.
>
> Also, the only known difference between the two deployments is, the JDBC
> driver.  I'm reading/writing to an Oracle 8i database using a JDBC 2.0
Type
> 2 driver whereas with Orion I'm using JDBC Type 4 (thin driver from
Oracle).
> I'm sure this adds to the response time issue but I can't believe it's the
> cause of the scalability problem.
>
> I'm sure there's more tweaking I could do with Orion, but as I'm sure
> everyone is aware, documentation is hard to find.
>
> Also, does anyone have any benchmarks using Type 2 vs. Type 4 drivers?
>
> Please, feedback is welcome.
>
> I'm evaluating Orion, JBoss, and JRun.  I'm leaning towards Orion for many
> reasons that I won't go into here but scalability is a 'big' issue.
>
> Thanks
> Tom
>
> Tom Wnuk
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>   ------------------------------------------------------------------------
>                   Name: winmail.dat
>    winmail.dat    Type: application/ms-tnef
>               Encoding: base64