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

[Christian M. <chr...@ta...>]

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
>
>