JBoss: Windows vs Linux and a Solaris boot issue

Bryan Sant bryan.sant at gmail.com
Tue Mar 7 17:46:30 MST 2006


On 3/7/06, Ryan Bowman <ryanlbowman at gmail.com> wrote:
> No, I wasn't doing anything with the client when I ran any of theses
> commands, except for top, so you could see that it was barely doing
> anything.  And therein is part of the problem, there doesn't appear to
> be anything causing the delays, but there are very noticeable delays
> when on linux.

The delays you're experiencing are a fact.  However, in my experience
I've always found server-side java to run at least as fast and
typically faster on Linux than Windows Server.  So something doesn't
add up.  Linux has faster/superior memory management.  The Linux 2.6
kernel has better threading.  Linux has MUCH faster filesystems and a
much more aggressive file buffer mechanism.  Yada, yada, yada.  In
short, Linux is a swell server platform and there is going to be a
logical explaination for your issues.  Maybe there is a glaring bug
with your Linux distro, but I doubt it.  Something is different
between the Linux and Windows systems.  Are you dual-booting on the
Windows hardware, or is this a seperate system?

> I can't remember why we're running it as root.  It seems like there
> were issues getting it to start up correctly, possible related to some
> of the ports it listens on.

A process running as a user other than root can't bind to ports below
1024 for security reasons.  Your JBoss process is probably trying to
bind to port 80 (for web which you're not using anyway right?).  You
should configure JBoss to listen on ports higher than 1024 (switch
port 80 to be on port 8080 for example).  You're primarily using RMI
so you really only care about port 1099 (which is ok for a non-root
user).

Running as root isn't the end of the world, but consider that any
security issue exploited by a user/hacker against JBoss will
potentially lead to root-level, catastrophic, damage -- you might as
well be running Windows :-).  On the other hand if you run as a
non-privilaged user, the wosrt some hacker could do is mess up that
jboss account -- not drop an atomic bomb on the entire system.

> Go ahead, what's wrong with jboss?  I'm not averse to trying it on
> Geronimo, but it probably won't actually happen, because of time
> constraints, and people who have given up fighting MS, so they feel
> that as long as it doesn't crash while people are using it we're
> better off using windows.

I've ranted about JBoss before on PLUG.  I hate it.  JBoss on a whole
is much slower that other Java app servers.  In addition, JBoss has
its own classloader design that is TOTALLY screwed and
non-defacto-standard.  Even Norman Richards, a JBoss Group employee,
has railed on how bad the JBoss classloader sucks.  I think JBoss does
it on purpose.  They make money selling books (even the manual isn't
free) and support.  I think they purposely make JBoss confusing so
that you are obliged to pay for support and/or instructional material.
 They could get away with this when they were the only good OSS app
server in town.  Now they are screwed.  Apache Geronimo (backed by
IBM) is going to roll over them.  Also, JBoss Group is partnering with
Microsoft in a big way -- for all I know, they are purposely making
JBoss suck on Linux and sing on Windows (any takers on this conspiracy
theory :-)).  Honestly, I don't know why JBoss is so popular -- most
likely because it was first.

When we moved our web code from JBoss to straight Tomcat (we only
needed a web server) our performance nearly doubled without doing
anything else.  JBoss is a slow pig...  But it should be equally slow
on Windows too...  So your problem is still valid.

Read this:
http://jroller.com/page/julien.dubois?entry=the_jboss_classloader_from_hell

Then google for "JBoss classloader sucks" or something and wade
through the muck.

> Yeah, that's what we want to do, but there are only two of us working
> on this problem, we have lots to do, and I don't know much about this
> section of the code, so it's probably going to be a few days before we
> get to it. Since windows performs so much better, we're probably going
> to end up putting windows on a different server to see if it was
> crashing because of hardware problems (part of the long story of our
> outsourced IT guy that screwed us over with a bunch of crappy
> servers), until such time as we have to really dig into this.

I can appreciate your situation.  Windows is working faster for some
reason, so you stick with Windows for now.  If you're going to support
this system long-term then I would recommend a continued effort to get
it on Linux.  I'm an MCSE, and have worked with Windows for years (in
a professional capacity), but you couldn't pay me enough to waste my
time running a server solution on Windows "Server".  MS has a great
desktop product, and they are throwing a lot of money at Windows
Server to get it to compete with UNIX/Linux, but until it morphs into
Microsoft UNIX, I'd keep my distance :-).

> Thanks for your help and advice.  Hopefully we'll get more time to
> look into this.

No problem.  I hope you get it working.

-Bryan



More information about the PLUG mailing list