Re: [Wrapper-user] clustering and java service wrapper

[jeroen v. <jvr...@gm...>]

Well, to keep you guys updated on my progress.

I managed to get the fix the logging off problem by using the
ignore_user_logoffs=TRUE option. Seems to do the trick, but I'm checking
out the other method to where I use the application as Windows Service too.
I managed to get that working too. Now when i go check out the service that
is installed on both nodes(well on the windows server cluster, you need to
install the service on both nodes locally), i can see that the path to the
executable is something like this:

X:\Foo\Bar\app\bin\wrapper.exe -s X:\Foo\Bar\app\conf\wrapper.conf
wrapper.console.flush=true wrapper.internal.namedpipe=0643816939
The named pipe is different on both servers

What does the wrapper.console.flush parameter do? And the namedpipe is
dependant on the wrapper?
Reason why I am asking this, is because I'm probably gonna need to script
some managementtools. Already tried to script something in powershell,
where i kept everything like that, but took a random number for the
namedpip(kept the number of digits though).

The service did get created, but it didn't start up. So Im' woundering if i
need to consider some stuff, when creating the windows service myself in
powershell instead of using the wrapper.exe -i method in cmd.

thanks in advance

jeroen Vranckx



On 28 March 2012 09:10, Christian Mueller <
chr...@ta...> wrote:

> Hello Vranckx,
>
> about the restart on log off, you are probably right about that the
> application gets restarted due to the cluster setting.
> If that's the case, you should actually see that in the Wrapper log file
> as well.
>
> The 2 options are actually the most easy ways of telling the Wrapper/JVM
> to ignore the logoffs.
>
> However, there is also another way.
> If you are willing to do some coding, you can take a look at integration
> method 3:
> http://wrapper.tanukisoftware.com/doc/english/integrate-listener.html
>
> The controlEvent(..) method receives signals/events raised by the System
> and allows you to implement your own logic on the various signals.
>
> The advantage of this option is that you wouldn't need to change the
> Wrapper version and also can keep running the applications the same way
> they are running right now.
> The API for the Wrapper can be found here:
> http://wrapper.tanukisoftware.com/jdoc/index.html
>
> If you have any questions in the implementation, please let me know.
>
> Best Regards,
> Christian
>
>
> On Tue, Mar 27, 2012 at 10:36 PM, jeroen vranckx <jvr...@gm...>wrote:
>
>> Thanks for the outstanding service Mr. Mueller,
>>
>> Your explanation makes perfect sense. Seems like I was thinking in the
>> right direction.
>> I went to check on the tips that you gave me, and was surprised that i
>> couldn't find the wrapper.ignore_user_logoffs setting.
>> Did a little resource on what version they are working with, and seems
>> like they are working with a  3.2.1version. (So that explains the missing
>> setting ^^).
>>
>> Went to check on the programmers also, and it seems that all applications
>> are running as console applications, and not as services. This explains
>> pretty much everything.
>> As they weren't actually running as services but as console applications,
>> and because they were using an outdated version that didn't have the
>> wrapper.ignore_user_logoffs setting,
>> it makes perfect sense that the JVM would shutdown.
>>
>> i need to clear a little misunderstanding though. The "so called"
>> services restarted after a log-off.
>> This is probably caused by the JVM shutting down like you said, because
>> of the fact that they are running as console applications.
>> The cluster sees that his resources went down, so he tries to bring them
>> back online. I think he probably initiates new JVM's then.
>>
>> As it is a production environment, I can't recreate the scenario. It's a
>> shame, but I think we have it pretty much figured out now, why it was going
>> wrong ^^.
>> Don't think there is a way to fix the issue in the currently running
>> environment.(without having to convert everything to services, or upgrading
>> to the new version of the wrapper).
>>
>> So I'm just gonna concentrate on the new environment.
>>  Now, for the new environment I'll need to make some decissions and if i
>> understand correctly i have 2 options to avoid the log off issue:
>>
>> 1: running the application as a real service (that will ignore the logoff
>> by default)
>>
>> 2: keep using the console application but use the option
>> ignore_user_logoffs=TRUE (when using at least the 3.3.1 version(i'll be
>> using the latest version of course ^^))
>>
>> Is this correct, or are there other options? Maybe keep in mind, that we
>> are using it in a clusterevironment.
>>
>> Thanks for your help in advance!
>> Vranckx Jeroen
>>
>>
>>
>> On 27 March 2012 13:51, Christian Mueller <
>> chr...@ta...> wrote:
>>
>>> Hello Vranckx,
>>>
>>> thank you for your mail.
>>>
>>> The native library of the Wrapper (wrapper.dll) is installing a signal
>>> handler for the JVM, making it possible to intercept signals/events, such
>>> as the logoff event, the system sends to all running processes, whenever a
>>> user logs off from a session.
>>> As you already have mentioned, the JVM is actually a process, which is
>>> by design not thought of running as a Service by itself. So whenever the
>>> JVM receives a logoff event from the system, it's default behavior is to
>>> shut itself down.
>>>
>>> When running as service, by default, the Wrapper catches this signal
>>> allowing the JVM to keep running even after the logoff signal (among some
>>> other signals) have been received.
>>>
>>> When running as console application, which is been done when running
>>> wrapper.exe -c, the default action is actually to forward the event to the
>>> JVM, which then will shut itself down.
>>> This behavior can be changed easily by setting the following property
>>> into your conf file:
>>> wrapper.ignore_user_logoffs=TRUE
>>>
>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-user-logoffs.html
>>>
>>> I don't think that's the issue, but just in case, if the Wrapper wasn't
>>> able to load the native library, it will print out a warning, indicating
>>> the reason of the failure.
>>> Please make sure that the wrapper.java.library.path.<n> property is
>>> being set correctly to the path where the native library is located.
>>> But since you said, that the services actually keep running after a
>>> logoff, I assume that the JVM was already loading the native library
>>> successfully.
>>>
>>>
>>> Please let me know if you have any further questions.
>>>
>>> Best Regards and Good luck with your thesis!
>>>
>>> Christian Mueller
>>> Tanuki Software, Ltd.
>>>
>>>
>>>  On Tue, Mar 27, 2012 at 7:00 PM, jeroen vranckx <jvr...@gm...>wrote:
>>>
>>>>  Hi everybody,
>>>>
>>>>
>>>>
>>>> This is my first time for posting a question here, but I thought it
>>>> would be best to ask some help with people who are familiar with the java
>>>> service wrapper already.
>>>>
>>>>
>>>>
>>>> So maybe it’s best that I give you some information about why I’m
>>>> asking this question and why I need your help.
>>>>
>>>> So I’m a student from Belgium, and I’m currently doing my
>>>> thesis(graduation paper?).
>>>>
>>>>
>>>>
>>>> The company were I’m doing this asked me to revise and migrate an
>>>> existing servercluster infrastructure. I’ve been working the past 2 weeks
>>>> on checking out the possibilities to upgrade and improve the existing
>>>> structure,
>>>>
>>>> And I think I have given them some options on that side.
>>>>
>>>>
>>>>
>>>> Now I have come to the actual clustering. The servercluster is only
>>>> used to cluster java-applications and services.
>>>>
>>>> There are a number of generic applications that run on the cluster,
>>>> which are using the java service wrapper.
>>>>
>>>>
>>>>
>>>> Now; one of the problems that they are having, is that when an
>>>> administrator logs on to one of the servernodes, and logs off again, all
>>>> the generic applications restart.
>>>>
>>>> They were thinking that this problem was probably caused by the wrapper.
>>>>
>>>>
>>>>
>>>> After reading the documentation, I seem to have found some indications
>>>> that indeed point in this direction.
>>>>
>>>> Not saying that the wrapper itself is doing anything wrong, but I think
>>>> that it’s probably used in a wrong manner.
>>>>
>>>>
>>>>
>>>> *“The problem is that Java on its own can not be run as a service.
>>>> Many simple tools like the Windows "sc" command can be used to run Java as
>>>> a service, but the user doing something as simple as logging off of the
>>>> machine will cause Java to shutdown.“*
>>>>
>>>> * *
>>>>
>>>> *“Most Java applications die rather abruptly if the user presses CTRL-C,
>>>> logs out of Windows, etc. You can work around some of these issues with a
>>>> Shutdown Hook, but the Wrapper implements this by using a **native
>>>> library<http://wrapper.tanukisoftware.com/doc/english/prop-native-library.html>
>>>> ** to directly capture the system signals. This makes it possible to
>>>> have a Java application installed as a Windows Service without it being
>>>> stopped when a user logs out. “*
>>>>
>>>> * *
>>>>
>>>> * *
>>>>
>>>> Now, what I think is what happens: the generic applications aren’t
>>>> correctly set-up to run as a windows service(probably combination of
>>>> clustering resource and java service wrapper misconfiguration),
>>>>
>>>> which causes the JVM’s to stop when logging off. The cluster notices
>>>> that there is something wrong with the clustering resource(generic
>>>> application), and starts it back up.
>>>>
>>>> This caused them to think at the company that the resources restarted,
>>>> but I think this isn’t the case. It’s the JVM that stops, and the
>>>> clustering that steps in.
>>>>
>>>>
>>>>
>>>> Now, I’m wondering where I need to start looking to fix this problem. I
>>>> think the problem lies with the fact that the java-application isn’t
>>>> running as a windows service.
>>>>
>>>> I did already notice something with the command line parameters of the
>>>> generic resources. They are using the following commands to run the java
>>>> applications:
>>>>
>>>> X:\Foo\Bar\FooBAR\bin\wrapper.exe -c  X:\ Foo \ Bar \ FooBAR
>>>> \conf\wrapper.conf
>>>>
>>>>
>>>>
>>>> If my first quick read of the documentation was correctly, that will
>>>> let it run as a console-application. Don’t know if this has anything to do
>>>> with it, just guessing.
>>>>
>>>> I’m probably going to re-read the whole documentation again, to get
>>>> myself more familiar with the java service wrapper.
>>>>
>>>> I’m not just looking for the answer, I really want to look into the
>>>> problem here. That’s why I’m looking for some input here, to get a point to
>>>> work from.
>>>>
>>>> My time is limited, so I need to work efficient(need to do management
>>>> and probably a whole lot of testing), so I thought it would be best to ask
>>>> for some help here.
>>>>
>>>>
>>>>
>>>> So is there someone who has some experience with clustering and java
>>>> service wrapper?  Or somebody that has a hunch what the problem is?
>>>>
>>>>
>>>>
>>>> Your help will certainly be appreciated.
>>>>
>>>> I apologize for my bad English, and hoping to hear your ideas on this
>>>> one.
>>>>
>>>>
>>>>
>>>> Vranckx Jeroen
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF email is sponsosred by:
>>>> Try Windows Azure free for 90 days Click Here
>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>> _______________________________________________
>>>> Wrapper-user mailing list
>>>> Wra...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> _______________________________________________
>>> Wrapper-user mailing list
>>> Wra...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>