Using Java WebStart reduces the number of threads that can be created ??

[Alexei Betin]

Using a simple Test program which tries to create
as many threads as possible,

I found on several machines that the number of
threads you can create using Java WebStart (1.0.1_02)
is about twice as little as using command line java.exe

Any ideas why? I tried using java.exe (rather than javaw.exe)
as executable for WebStart - no difference,

Also, the max heap size was set the same (and very large)
- so it was not lack of memory issue, but limitation on
native threads, by why such difference?

We switched to using Java WebStart to launch server apps
to simplify deployment - and now unpleasant surprise :-((

--

Thanks,
~Alexei

[Alexei Betin]

>
> On Thu, 10 Oct 2002 10:42:31 -0700 "Alexei Betin"
> <abe...@futuretrade.com> wrote in comp.lang.java.programmer:

>
> > I found on several machines that the number of
> > threads you can create using Java WebStart (1.0.1_02)
> > is about twice as little as using command line java.exe
>

> First, let me mention that creating plenty of threads is always a bad
> idea. Only multi-CPU systems can gain from that, all other systems will
> soon suffer. Multi-threating programming is in general a good idea, but
> we are talking about a "reasonable" amount of threads here.
>
> I remember a benchmark test that showed that a WWW server could deliever
> twice as many webpages by not creating a new thread for every request
> (which slowed down a lot once the number of artificial created requests
> grew very high), but by running a fixed number of working threads and
> equally balance all requests into request-queues of the threads. Two
> threads that are each making a job parallely are not automatically
> faster than a single one doing the same jobs sequentially (this is only
> always true as long as you don't have more threads than CPUs in a
> machine, otherwise it depends on the type of job the threads are
> performing).
>

That I agree with, but now I am not in position to change the software,
we just need to run a series of tests to measure the scalabity of
existing system, when we know what it is capable of handling
(and how performant it is), we can then either switch to queue-based
architecture you describe or use clustering approach.

> > Any ideas why? I tried using java.exe (rather than javaw.exe)
> > as executable for WebStart - no difference,
>

> Could be a security concern. JWS applications also run in a sandbox, not
> in exactly the same ones as applets, but they also don't have the full
> applications privileges, as you can start them over the web and the user
> must be protected of evil code.
>
> My JVM crashes, because I run out of memory when I open threads in an
> endless loop. What OS are you using?
>

Win2K, yes, obviously it crashes at some point, but that point is two times
different between WS versus non-WS launch - that's the issue,

the Exception I get with WS is:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at Test.main(Test.java:29)
at java.lang.reflect.Method.invoke(Native Method)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

without WS:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at Test.main(Test.java:29)

as I say, VM has the same memory size in both cases, so
I don't think it actually runs out of memory - it just cannot
create threads any more, and uses OutOfMemoryError
exception to report that.

So there's some extra crap in WS Launcher which somehow
reduces the OS capacity to create threads

> > Also, the max heap size was set the same (and very large)
> > - so it was not lack of memory issue, but limitation on
> > native threads, by why such difference?
>

> You are aware that this may not be an heap issue at all, are you? You do
> know that every new thread gets an own STACK and that all these stacks
> together can take up quite a lot of memory and I don't think that the
> new stack memory for a new thread will be placed into the JVM heap
> memory.
>

Yes, I am aware. As I say, does not seem to be a memory issue,
You actually can reduce the limit of threads by specifying a high
-Xss argument (thread stack size) to JavaVM. In my case, however,
this value is not explicitly set, so I am assuming the same default is used
in both cases.

Thanks,
~Alexei

[Dale King]

TGOS wrote:
> On Thu, 10 Oct 2002 12:52:30 -0700 "Alexei Betin"
> <abe...@futuretrade.com> wrote in comp.lang.java.programmer:
>
>

>>That I agree with, but now I am not in position to change the software,
>>we just need to run a series of tests to measure the scalabity of
>>existing system, when we know what it is capable of handling
>>(and how performant it is), we can then either switch to queue-based
>>architecture you describe or use clustering approach.
>
>

> But if you can only create half as many threads in JWS than you can
> create normally, you can create more threads than any reasonable
> application would ever use. Or what are your numbers? Don't tell me you
> can only create 100 threads on Java and only 50 threads in JWS.

>
>
>>Win2K, yes, obviously it crashes at some point, but that point is two times
>>different between WS versus non-WS launch - that's the issue,
>
>

> No, that alone is no issue.

>
>
>>the Exception I get with WS is:
>>java.lang.OutOfMemoryError: unable to create new native thread
>> at java.lang.Thread.start(Native Method)
>> at Test.main(Test.java:29)
>> at java.lang.reflect.Method.invoke(Native Method)
>> at com.sun.javaws.Launcher.executeApplication(Unknown Source)
>> at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
>> at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
>> at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
>> at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
>> at com.sun.javaws.Launcher.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>>without WS:
>>java.lang.OutOfMemoryError: unable to create new native thread
>> at java.lang.Thread.start(Native Method)
>> at Test.main(Test.java:29)
>
>

> That is because JWS has a launcher, that is the real main process that
> launches the JWS application. Thus a launcher doesn't exist if you start
> it from command line.

>
>
>>as I say, VM has the same memory size in both cases, so
>>I don't think it actually runs out of memory - it just cannot
>>create threads any more, and uses OutOfMemoryError
>>exception to report that.
>
>

> That would be unusual for Sun. They don't throw exception A to make you
> aware of problem B. Even though the documentation doesn't always mention
> all exceptions correctly.

>
>
>>Yes, I am aware. As I say, does not seem to be a memory issue,
>>You actually can reduce the limit of threads by specifying a high
>>-Xss argument (thread stack size) to JavaVM.
>
>

> This will not limited the number of threads, it will just cause every
> thread to swallow even more memory and thus you run out of memory
> sooner.

It is most likely a difference in memory allocation. There are 2
variables that could cause this: The max heap size (-Xmx option) and the
stack size (-Xss option). It may be that WebStart gives you less memory
or reserves more room for the stack, or both.

I'm not sure if you can control these from WebStart, but you should
probably check the unofficial WebStart FAQ at www.vamphq.com.

--
Dale King