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

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

hey christian,

If I look at the created windows service that I made by using the
wrapper.exe -i wrapper.conf option, when i look at the path to the
executable it says X:\Foo\Bar\app\bin\wrapper.exe -s
X:\Foo\Bar\app\conf\wrapper.conf.

Now, I have the possibility when i create a generic application(for
clusterunaware services), to just specify the service that i want to make
generic. I have the possibility to give the generic service a specific
startup command, so I could definatly use the -t method if nesecairy.
 If I run it, it works perfectly fine without the us of the -t parameter(it
will probably use the -s parameter by default). What does the -t parameter
do actually?
What's the difference if i run it with -s or --t?

Indeed it says on the website(just as you say), that you need to call the
-t parameter for a service, but the -s parameter(that is default when you
install by the -i parameter) kinda confused me.

Looking forward to your replye, and tnx in advance

greetings,
Jeroen Vranckx


On 4 April 2012 07:10, Christian Mueller <
chr...@ta...> wrote:

> Hello,
>
> the parameter '-s' should not be called by the user but the service
> manager in order to control the wrapper as service.
>
> when you want to start the installed service from console or script,
> please run:
> X:\Foo\Bar\app\bin\wrapper.exe -t X:\Foo\Bar\app\conf\wrapper.conf
>
> for all available parameters, please run bin\wrapper -?
>
> The wrapper.internal.namedpipe property is for internal use only and
> shouldn't be set.
> Actually it is only being used during installation and actually I think
> it's redundant to have it on the servicemanager command.
> When you interact with a service, administrator privileges are required.
> However starting with the introduction of UAC in Windows Vista, an
> Administrator account also needs to elevate a process to run under high
> security context.  The Wrapper will check if it runs already elevated and
> if not, it will pop-up the elevation dialog, requesting the elevation. This
> will actually spawn an elevated process, which will do the required task.
> The IPC of the elevated process and the original process is done via a
> named pipe the original process allocates. The name of the named pipe is
> random, so that's why you see two different names. Using random names makes
> it possible to interact with multiple services simultaneously without
> clashing. To tell the elevated process at which pipe the original wrapper
> process is waiting for, the wrapper.internal.namedpipe is being defined.
> The elevated process then redirects stdin/stdout/stderr to the pipes and
> because by default stdin/stdout/stderr is buffered to save some
> performance, but in this case it will cause some timing issues and since
> the install/remove/start/stop actions are only running for a rather short
> time, performance doesn't matter that much.
>
> Hope this answers all your questions.
>
> Please let me know if you need any further information.
>
> Thank you,
>
> Christian
>
>  On Tue, Apr 3, 2012 at 5:43 PM, jeroen vranckx <jvr...@gm...>wrote:
>
>>  Just figured out something ^^
>> Seems like the wrapper.console.flush param and namedpipe param are a
>> indirect consequence of installing the service when you don't use
>> administrator params in cmd.
>> So if you're doing something like clustering, this will definatly mess
>> things up.
>>
>> Fixed this issue, and not having issues anymore.
>> Scripted the wrapper.exe -i option in windows powershell, and managed to
>> get the service running now. I'll be integrating it with the automatic
>> generation of the windows service as a generic service in the cluster.
>>
>> I still would like to know what those param do, as they do seem to be
>> wrapperrelated
>>
>>
>> On 3 April 2012 10:03, jeroen vranckx <jvr...@gm...> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>>
>> _______________________________________________
>> Wrapper-user mailing list
>> Wra...@li...
>> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>>
>>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>