Re: [vfs] does vfs webdav support https

[Ralph Goers]

Well darn. I keep thinking this should be as simple as using webdavs as the 
protocol but we never implemented a WebdavsFileProvider.

Ralph

On May 31, 2012, at 8:53 PM, Dan Tran wrote:

> Can somehone shows me an example on how to configure webdav:// url to use 
> https?
> 
> Thanks
> 
> -D
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[vfs] does vfs webdav support https

[Dan Tran]

Can somehone shows me an example on how to configure webdav:// url to use https?

Thanks

-D

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Kurt Pernstich]

Hi, thanks for your quick response !!

My guess is that it will throw an exception if you wait long enough. ;-)
>
Well, not within 90 min ...


This looks like a bug. Could you please open a ticket on the bug tracking
> system[1]? Once the issue is created, you should also upload a fully
> contained
> unit test demonstrating the problem.
>

Done: https://issues.apache.org/jira/browse/MATH-798

Thanks a lot,
Kurt

Re: Commons daemon - stop the service

[Mladen Turk]

On 05/31/2012 07:53 PM, James Wang wrote:

Thanks for the comments.
I set both start mode and stop mode to JVM.


OK.


What will happen when a thread needs 20 more minutes to complete its job?


Well for something like that procrun is not the toolkit to use.
First of all, if you need to frequently start/stop service why using
the service at the first place?
The sole purpose of service concept is to start the application
at boot mode or on demand and to start them in correct order.

Then there is absolute limit which OS imposes on the service
shutdown timeout, and this is for all services on the system,
see http://support.microsoft.com/kb/Q146092

So the only clean solution is that your shutdown code does
the actual cleanup causing the clean exit.

By spec, JVM won't exit if you have non-daemon threads running,
so if you cant make them exit, then the only solution is
System.exit, which calls OS process _exit() which causes
the SCM to think service failed.

Also you should design your application differently for
service and command line mode.

Procrun does not need to call the main() method.
Take a look at Tomcat. We call Bootstrap start/stop methods
and main() calls Bootstrap.start (after setting correct mode)



Regards
--
^TM

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

RE: Commons daemon - stop the service

[James Wang]

Thanks for the comments.
I set both start mode and stop mode to JVM. My test showed that worked best for 
me. The procrun documentation says that to use this mode, the start method 
should not stop until stop is called. My start method exits immediately but it 
did not seem to be the cause of my grievances. My stop code also calls 
System.exit() in a separate thread, after couple of seconds of sleep. I cannot 
get rid of it because some of our customers still want to start and stop the 
application using batch scripts. But the stop did not fail consistently with 
"unexpected" stoppage. That makes me think that there is an issue of timing. 
What I have recently tried is to terminate most, if not all, threads spawned by 
the applications gracefully. That seemed to have improved the performance 
(fewer error messages from service manager). But my testing is done when the 
app is not loaded with much work. What will happen when a thread needs 20 more 
minutes to complete its job? Would procrun be patient enough to wait (if I set 
the timeout to 20 minutes)? It is hard to test this scenario because I have not 
been able to put a heavy load on the application. So I would like know what 
actually happens after procrun calls the stop class? Does it monitor the JVM in 
some way? Does procrun eventually call System.exit() to shut down JVM?
Thanks.

James Wang

-Original Message-
From: Mladen Turk [mailto:mt...@apache.org] 
Sent: Thursday, May 31, 2012 12:15 PM
To: user@commons.apache.org
Subject: Re: Commons daemon - stop the service

On 05/31/2012 02:37 PM, James Wang wrote:
> I need some insights on how procrun shuts down an application. Procrun 
> has a parameter called "StopTimeout" which Defines the timeout in seconds 
> that procrun waits for service to exit gracefully. What happens after the 
> timeout period? Doe procrun shut down the JVM?
>
> A more general question is: how do the involved parties interact with 
> one another - JVM, procrun, and Windows service manager? I have been 
> perplexed by two errors: one says the process ended unexpectedly. The other 
> says service manager could not get a response from procrun (after a long 
> wait). In both cases, the event viewer showed errors related to prunsrv.exe. 
> These errors are more associated with the 32 bit version. AMD64 seems to work 
> a better.
>

Depends on the mode you select.
In general service stop is treated as separate process which should by some IPC 
mechanism inform the 'service' to stop.

The simplest one is System.exit, which just calls System.exit() for the service.
More complex involves either special process or method call which must cause 
main service to exit cleanly.

Shutdown timeout can occur if any of those goes over defined timeout.
Service code should never call System.exit by itself cause that can lead to 
'process ended unexpectedly'.
Reason is because 'stop' waits for 'start' to finish and then 'stopped'
is reported to service manager.

So if your service code uses system.exit then you must use java mode which 
spawns a separate process and stop is then program which must by some IPC 
(usually socket) inform the 'master' to shut down.

With jvm mode all that happens in the same process (and the same JVM) thus your 
stop code must set some variable in main program which will cause clean exit 
from main method. This can be tricky if you depend on daemon threads.

Hope that shares some light.


Regards
--
^TM

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Gilles Sadowski]

On Thu, May 31, 2012 at 07:00:58PM +0200, Thomas Neidhart wrote:
> On 05/31/2012 06:12 PM, Gilles Sadowski wrote:
> > Hi.
> > 
> >> Hi, in certain cases I ran into the problem that the PolynomialFitter.fit()
> >> method stalls, meaning that it does not return, nor throw an Exception. Is
> >> there a way to tell the PolynomialFitter to iterate only N-times to ensure
> >> that my program does not stall?
> > 
> > My guess is that it will throw an exception if you wait long enough. ;-)
> 
> In fact it will run forever ;-)

No it shouldn't. If the convergence criterion is never met it will throw an
exception after exhausting all the evaluations (which in the
"PolynomialFitter" is set to Integer.MAX_VALUE). Will be long but not
forever. :-)

> 
> With the default settings there is no criteria to stop the optimization
> process (but you can provide your own ConvergenceChecker which takes
> also iterations into account).

There is a default criterion: it is defined by a default instance of
"SimpleVectorValueChecker".

> 
> After further digging into this, I have seen that the two optimizers
> (GaussNewton, LevenbergMarquardt) use different convergence criteria,
> with the Gauss one being stricter.
> 
> So when providing your test case with the same default settings as for
> the LM than it works also for the GN case:
> 
> PolynomialFitter RshuntFitter =
>new PolynomialFitter(1, new GaussNewtonOptimizer(
>  new SimplePointChecker(10e-10, Precision.SAFE_MIN)));

Here the checker use the "point" while the default one uses the "value".
It doesn't give an explanation as to why one works and the other not.
One can just deduce that, if there is no bug in optimizer, the convergence
criterion is too stringent for the problem at hand.

> [...]

Best,
Gilles

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Gilles Sadowski]

Hi.

> > 
> 
> [snip test case]
> 
> > This looks like a bug. Could you please open a ticket on the bug tracking
> > system[1]? Once the issue is created, you should also upload a fully 
> > contained
> > unit test demonstrating the problem.
> 
> This is most likely related to the GaussNewtonOptimizer

Yes, hence my request to provide a fully-working self-contained unit tests
that displays the problem.

> (hasn't there
> been a change recently?).

No.

> 
> The test case runs through successfully with the
> LevenbergMarquardtOptimizer.

So?


Regards,
Gilles

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Thomas Neidhart]

On 05/31/2012 06:12 PM, Gilles Sadowski wrote:
> Hi.
> 
>> Hi, in certain cases I ran into the problem that the PolynomialFitter.fit()
>> method stalls, meaning that it does not return, nor throw an Exception. Is
>> there a way to tell the PolynomialFitter to iterate only N-times to ensure
>> that my program does not stall?
> 
> My guess is that it will throw an exception if you wait long enough. ;-)

In fact it will run forever ;-)

With the default settings there is no criteria to stop the optimization
process (but you can provide your own ConvergenceChecker which takes
also iterations into account).

After further digging into this, I have seen that the two optimizers
(GaussNewton, LevenbergMarquardt) use different convergence criteria,
with the Gauss one being stricter.

So when providing your test case with the same default settings as for
the LM than it works also for the GN case:

PolynomialFitter RshuntFitter =
   new PolynomialFitter(1, new GaussNewtonOptimizer(
 new SimplePointChecker(10e-10, Precision.SAFE_MIN)));

In fact the LM optimizer uses two different convergence criteria (the
provided ConvergenceChecker and additional ones that are provided at
construction time) and uses both in the optimization process.

Thomas

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Thomas Neidhart]

On 05/31/2012 06:12 PM, Gilles Sadowski wrote:
> Hi.
> 

[snip test case]

> This looks like a bug. Could you please open a ticket on the bug tracking
> system[1]? Once the issue is created, you should also upload a fully contained
> unit test demonstrating the problem.

This is most likely related to the GaussNewtonOptimizer (hasn't there
been a change recently?).

The test case runs through successfully with the
LevenbergMarquardtOptimizer.

Thomas

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: Commons daemon - stop the service

[Mladen Turk]

On 05/31/2012 02:37 PM, James Wang wrote:

I need some insights on how procrun shuts down an application. Procrun has a 
parameter called “StopTimeout” which Defines the timeout in seconds that 
procrun waits for service to exit gracefully. What happens after the timeout 
period? Doe procrun shut down
the JVM?

A more general question is: how do the involved parties interact with one 
another – JVM, procrun, and Windows service manager? I have been perplexed by 
two errors: one says the process ended unexpectedly. The other says service 
manager could not get a
response from procrun (after a long wait). In both cases, the event viewer 
showed errors related to prunsrv.exe. These errors are more associated with the 
32 bit version. AMD64 seems to work a better.



Depends on the mode you select.
In general service stop is treated as separate process which should by some IPC
mechanism inform the 'service' to stop.

The simplest one is System.exit, which just calls System.exit() for the service.
More complex involves either special process or method call which
must cause main service to exit cleanly.

Shutdown timeout can occur if any of those goes over defined timeout.
Service code should never call System.exit by itself cause that can
lead to 'process ended unexpectedly'.
Reason is because 'stop' waits for 'start' to finish and then 'stopped'
is reported to service manager.

So if your service code uses system.exit then you must use java mode
which spawns a separate process and stop is then program which must
by some IPC (usually socket) inform the 'master' to shut down.

With jvm mode all that happens in the same process (and the same JVM)
thus your stop code must set some variable in main program which will
cause clean exit from main method. This can be tricky if you depend on
daemon threads.

Hope that shares some light.


Regards
--
^TM

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [math] PolynomialFitter.fit() stalls

[Gilles Sadowski]

Hi.

> Hi, in certain cases I ran into the problem that the PolynomialFitter.fit()
> method stalls, meaning that it does not return, nor throw an Exception. Is
> there a way to tell the PolynomialFitter to iterate only N-times to ensure
> that my program does not stall?

My guess is that it will throw an exception if you wait long enough. ;-)

> 
> Maybe I should note that when I used a LevenbergMarquardOptimizer instead
> of a GaussNewtonOptimizer the fit worked fine for the limited number of
> test cases considered, but this is not a guarantee that the
> LevenbergMarquardOptimizer will work for all cases.
> 
> Here is a test case that stalls the PolynomialFitter.fit() on my machine:
> 
> PolynomialFitter RshuntFitter = new PolynomialFitter(1, new
> GaussNewtonOptimizer());
> RshuntFitter.addObservedPoint(-0.2, -7.12442E-13);
> RshuntFitter.addObservedPoint(-0.199, -4.33397E-13);
> RshuntFitter.addObservedPoint(-0.198, -2.823E-13);
> RshuntFitter.addObservedPoint(-0.197, -1.40405E-13);
> RshuntFitter.addObservedPoint(-0.196, -7.80821E-15);
> RshuntFitter.addObservedPoint(-0.195, 6.20484E-14);
> RshuntFitter.addObservedPoint(-0.194, 7.24673E-14);
> RshuntFitter.addObservedPoint(-0.193, 1.47152E-13);
> RshuntFitter.addObservedPoint(-0.192, 1.9629E-13);
> RshuntFitter.addObservedPoint(-0.191, 2.12038E-13);
> RshuntFitter.addObservedPoint(-0.19, 2.46906E-13);
> RshuntFitter.addObservedPoint(-0.189, 2.77495E-13);
> RshuntFitter.addObservedPoint(-0.188, 2.51281E-13);
> RshuntFitter.addObservedPoint(-0.187, 2.64001E-13);
> RshuntFitter.addObservedPoint(-0.186, 2.8882E-13);
> RshuntFitter.addObservedPoint(-0.185, 3.13604E-13);
> RshuntFitter.addObservedPoint(-0.184, 3.14248E-13);
> RshuntFitter.addObservedPoint(-0.183, 3.1172E-13);
> RshuntFitter.addObservedPoint(-0.182, 3.12912E-13);
> RshuntFitter.addObservedPoint(-0.181, 3.06761E-13);
> RshuntFitter.addObservedPoint(-0.18, 2.8559E-13);
> RshuntFitter.addObservedPoint(-0.179, 2.86806E-13);
> RshuntFitter.addObservedPoint(-0.178, 2.985E-13);
> RshuntFitter.addObservedPoint(-0.177, 2.67148E-13);
> RshuntFitter.addObservedPoint(-0.176, 2.94173E-13);
> RshuntFitter.addObservedPoint(-0.175, 3.27528E-13);
> RshuntFitter.addObservedPoint(-0.174, 3.33858E-13);
> RshuntFitter.addObservedPoint(-0.173, 2.97511E-13);
> RshuntFitter.addObservedPoint(-0.172, 2.8615E-13);
> RshuntFitter.addObservedPoint(-0.171, 2.84624E-13);
> PolynomialFunction RshuntFit = new PolynomialFunction(RshuntFitter.fit());

This looks like a bug. Could you please open a ticket on the bug tracking
system[1]? Once the issue is created, you should also upload a fully contained
unit test demonstrating the problem.

Thanks,
Gilles

[1] https://issues.apache.org/jira/browse/MATH

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [configuration] attributes in xml config don't apply to all entries of a list

[Oliver Heger]

Am 31.05.2012 08:30, schrieb Alexander Selg:

Hi Oliver,

thanks for your clarification.

 From my point of view it would be more straightforward assigning
attributes to all nodes of a list. Otherwise the list feature seems
incomlete to me.
Our lists are a bit longish so I was very happy that I can avoid
repeating tags in our config.xml.

Does it make sense to create an improvement issue?


Why not? However, I think this issue will not be dealt with in an 1.x 
version because it might break existing code.


For Configuration 2.x list handling and list delimiter parsing are 
certainly topics which can be improved.


Oliver



Otherwise I think I would prefer to read the list as string and parse
it as a list by myself ...

Thank you for your help,
Alex

2012/5/30 Oliver Heger:

Am 30.05.2012 16:53, schrieb Alexander Selg:


Hi,

I'm using a different implementation of the DefaultExpressionEngine. I
use attributes in our applications conf.xml to filter the result of
DefaultExpressionEngine.query().
So I have a config file like


str1,str2,str3
str4,str5,str6


In the query() methode of MyExpressionEngine I want to access these
attributes

ListqueryResults = super.query(root, key);
for (ConfigurationNode queryResult : queryResults) {
attributes = queryResult.getAttributes();
...
}

The problem is that I only get the attributes for the first node - the
subsequent nodes don't have any attributes set.
So for "str1" I'll get the attribute environment="test", for "str2"
and "str3" I'll get no attributes.

Is that a bug?
Am I doing something wrong?

I'm using commons-configuration 1.8 with jdk1.6

Any help would be appreciated,
Alex



Not sure whether this behavior is somewhere documented, but it is indeed
intended. There are unit tests for XMLConfiguration which test that
attributes are only assigned to the first node of a list.

I guess, there are different use cases. When the code was developed a
decision had to be taken. At that time assigning attributes only to the
first node seemed to be straightforward.

If you have any control over your XML, I would recommend to avoid
comma-separated properties with multiple values. In XML lists can be defined
in a natural way by just repeating tags. Then the association between
attributes and values nodes is obvious.

HTH
Oliver



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[math] PolynomialFitter.fit() stalls

[Kurt Pernstich]

Hi, in certain cases I ran into the problem that the PolynomialFitter.fit()
method stalls, meaning that it does not return, nor throw an Exception. Is
there a way to tell the PolynomialFitter to iterate only N-times to ensure
that my program does not stall?

Maybe I should note that when I used a LevenbergMarquardOptimizer instead
of a GaussNewtonOptimizer the fit worked fine for the limited number of
test cases considered, but this is not a guarantee that the
LevenbergMarquardOptimizer will work for all cases.

Here is a test case that stalls the PolynomialFitter.fit() on my machine:

PolynomialFitter RshuntFitter = new PolynomialFitter(1, new
GaussNewtonOptimizer());
RshuntFitter.addObservedPoint(-0.2, -7.12442E-13);
RshuntFitter.addObservedPoint(-0.199, -4.33397E-13);
RshuntFitter.addObservedPoint(-0.198, -2.823E-13);
RshuntFitter.addObservedPoint(-0.197, -1.40405E-13);
RshuntFitter.addObservedPoint(-0.196, -7.80821E-15);
RshuntFitter.addObservedPoint(-0.195, 6.20484E-14);
RshuntFitter.addObservedPoint(-0.194, 7.24673E-14);
RshuntFitter.addObservedPoint(-0.193, 1.47152E-13);
RshuntFitter.addObservedPoint(-0.192, 1.9629E-13);
RshuntFitter.addObservedPoint(-0.191, 2.12038E-13);
RshuntFitter.addObservedPoint(-0.19, 2.46906E-13);
RshuntFitter.addObservedPoint(-0.189, 2.77495E-13);
RshuntFitter.addObservedPoint(-0.188, 2.51281E-13);
RshuntFitter.addObservedPoint(-0.187, 2.64001E-13);
RshuntFitter.addObservedPoint(-0.186, 2.8882E-13);
RshuntFitter.addObservedPoint(-0.185, 3.13604E-13);
RshuntFitter.addObservedPoint(-0.184, 3.14248E-13);
RshuntFitter.addObservedPoint(-0.183, 3.1172E-13);
RshuntFitter.addObservedPoint(-0.182, 3.12912E-13);
RshuntFitter.addObservedPoint(-0.181, 3.06761E-13);
RshuntFitter.addObservedPoint(-0.18, 2.8559E-13);
RshuntFitter.addObservedPoint(-0.179, 2.86806E-13);
RshuntFitter.addObservedPoint(-0.178, 2.985E-13);
RshuntFitter.addObservedPoint(-0.177, 2.67148E-13);
RshuntFitter.addObservedPoint(-0.176, 2.94173E-13);
RshuntFitter.addObservedPoint(-0.175, 3.27528E-13);
RshuntFitter.addObservedPoint(-0.174, 3.33858E-13);
RshuntFitter.addObservedPoint(-0.173, 2.97511E-13);
RshuntFitter.addObservedPoint(-0.172, 2.8615E-13);
RshuntFitter.addObservedPoint(-0.171, 2.84624E-13);
PolynomialFunction RshuntFit = new PolynomialFunction(RshuntFitter.fit());

Thanks for your help,
Kurt

Re: [scxml] ANN: SCION-Java project

[Jacob Beard]

Will do. Thanks,

Jake

On Thu, May 31, 2012 at 9:31 AM, Rahul Akolkar  wrote:
> If you want to provide a patch to the Commons SCXML home page source
> via JIRA, we could add this to the "Related Projects" section [1].
>
> -Rahul
>
> [1] http://commons.apache.org/scxml/#Related_Projects
>
>
> On Wed, May 30, 2012 at 5:36 PM, Jacob Beard  wrote:
>> Hi,
>>
>> While not specifically related to SCXML Commons, I wanted to draw your
>> attention to a new SCXML-related project I have just released called
>> SCION-Java [0]. SCION is an implementation of SCXML in JavaScript [1],
>> and SCION-Java provides lightweight bindings to the SCION library for
>> Java. Some advantages of SCION-Java are:
>>
>> * liberally licensed (Apache 2)
>> * extremely simple Java API (just one class)
>> * well-tested, using the SCXML Test Framework [2]
>> * supports scripting with ECMAScript out of the box
>>
>> The Java API is not quite complete yet, as I still need to allow
>> registering state change listeners from Java.
>>
>> If you have any questions or comments, please do not hesitate to
>> contact me. Thanks,
>>
>> Jake
>>
>>
>> [0] https://github.com/jbeard4/SCION-Java
>> [1] https://github.com/jbeard4/SCION
>> [2] https://github.com/jbeard4/scxml-test-framework
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [scxml] ANN: SCION-Java project

[Rahul Akolkar]

If you want to provide a patch to the Commons SCXML home page source
via JIRA, we could add this to the "Related Projects" section [1].

-Rahul

[1] http://commons.apache.org/scxml/#Related_Projects


On Wed, May 30, 2012 at 5:36 PM, Jacob Beard  wrote:
> Hi,
>
> While not specifically related to SCXML Commons, I wanted to draw your
> attention to a new SCXML-related project I have just released called
> SCION-Java [0]. SCION is an implementation of SCXML in JavaScript [1],
> and SCION-Java provides lightweight bindings to the SCION library for
> Java. Some advantages of SCION-Java are:
>
> * liberally licensed (Apache 2)
> * extremely simple Java API (just one class)
> * well-tested, using the SCXML Test Framework [2]
> * supports scripting with ECMAScript out of the box
>
> The Java API is not quite complete yet, as I still need to allow
> registering state change listeners from Java.
>
> If you have any questions or comments, please do not hesitate to
> contact me. Thanks,
>
> Jake
>
>
> [0] https://github.com/jbeard4/SCION-Java
> [1] https://github.com/jbeard4/SCION
> [2] https://github.com/jbeard4/scxml-test-framework
>
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Commons daemon - stop the service

[James Wang]

I need some insights on how procrun shuts down an application. Procrun has a 
parameter called "StopTimeout" which Defines the timeout in seconds that 
procrun waits for service to exit gracefully. What happens after the timeout 
period? Doe procrun shut down the JVM?
A more general question is: how do the involved parties interact with one 
another - JVM, procrun, and Windows service manager? I have been perplexed by 
two errors: one says the process ended unexpectedly. The other says service 
manager could not get a response from procrun (after a long wait). In both 
cases, the event viewer showed errors related to prunsrv.exe. These errors are 
more associated with the 32 bit version. AMD64 seems to work a better.
Any suggestions?
Thanks.

James Wang | Software Engineer, Development | [Description: Description: 
infor-logo-esig] | direct: 734.623.4056 | fax: 734.623.4190 | 
james.w...@infor.com