Menu
▾
▴
Re: [Wrapper-user] clustering and java service wrapper
|
From: Christian M. <chr...@ta...> - 2012-04-23 02:48:19
|
Hello jeroen, Thank you for your detailed explanation. When the cluster controller is trying to bring down the Wrapper application, is there anything in the log file, which would give a hint on why the wrapper processes isn't stopping. Furthermore, you said that the java application keeps running, but is the wrapper process also still running? If the cluster controller sends a signal to the JVM to shutdown, please remember that the jvm, which runs as console, has been set to ignore signals (in order to keep running after a logoff signal has been received)... Looking forward to hearing back from you. Best Regards, Christian On Fri, Apr 20, 2012 at 11:39 PM, jeroen vranckx <jvr...@gm...>wrote: > Well, i did some more research, and have some more indepth information > I'm not bringing down the node itself, I rather simulate a failure of the > disk, which the wrapper application depends on. After some research in the > cluster logs(which made me realise some in depth clustermechanisms i didn't > know), i filtered out this related information for you. > > > [RCM] TransitionToState(Disk J:\) ProcessingFailure-->[WaitingToTerminate > to DelayRestartingResource]. [RCM] rcm::RcmGroup::UpdateStateIfChanged: > (Java Service Group, PartialOnline --> Pending) > [RCM] TransitionToState(wrapper Application) Online-->[WaitingToTerminate > to OnlineCallIssued]. > [RCM] TransitionToState(wrapper Application) [WaitingToTerminate to > OnlineCallIssued]-->[Terminating to OnlineCallIssued]. > [RCM] HandleMonitorReply: TERMINATERESOURCE for 'wrapper Application', > gen(16) result 0. > [RCM] Restarting resource 'wrapper Application'. > seems like the cluster does try to terminate the wrapper-application, but > i know for a fact(I can see that the proces of the java-application keeps > running in task manager), that he doesn't succeed in doing this. > > After that the disk comes back online, the generic application is brought > back online. The cluster actually now makes a second JVM. And well, these > are running the exact same application, so the generic application(second > JVM) fails again. > > After he does the failover to the other node, everything works again and > he can bring up teh generic application. but what is happening now? the > original proces is still running on the other node. > So i have the same proces running on both nodes, and the cluster isn't > aware of this. > > Now I have made myself a fix, by just killing any left over Java-processes > when i do a failover. > > I have to mention, that running the same application as windows service > fixes this problem. seems like the cluster is communicating differntly with > the generic application > > > RCM] TransitionToState(Disk J:\) ProcessingFailure-->[WaitingToTerminate > to DelayRestartingResource]. > [RCM] rcm::RcmGroup::UpdateStateIfChanged: (Java Service Group, > PartialOnline --> Pending) > [RCM] TransitionToState(H2) Online-->[WaitingToTerminate to > OnlineCallIssued]. > [RCM] TransitionToState(H2) [WaitingToTerminate to > OnlineCallIssued]-->[Terminating to OnlineCallIssued]. > [RES] Generic Service <H2>: Terminate request. > [RCM] TransitionToState(FileServer-(testjp)(Disk J:\)) > Online-->[WaitingToTerminate to OnlineCallIssued]. > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=0) > > > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > [RES] Generic Service <H2>: GenSvcTerminate: retrying... > [RES] Generic Service <H2>: GenSvcTerminate : calling SCM (didStop=1) > [RES] Generic Service <H2>: Service died; status = 1062. > [RCM] HandleMonitorReply: TERMINATERESOURCE for 'H2', gen(0) result 0. > [RCM] Restarting resource 'H2'. > > the resource checking the service control manager, if the windows service > is really offline does work well in this case. > So in the new environment, we will probably go for running the > applications als services, and on top of that running the powershell script > with taskscheduler on the server to kill all remaining java processes after > a failover. > > I do want to know what goes wrong with the Wrapper Application though ^^. > seems like a misscommunication between cluster and wrapper. Just giving you > some feedback on what i'm thinking here. > > greetings jeroen > > > On 20 April 2012 10:04, Christian Mueller < > chr...@ta...> wrote: > >> Hello Jeroen, >> >> I'm very sorry for the delay. >> >> How are you bringing down the node? >> If I understand how you bring it down or what you mean by "bringing the >> resource offline", I will probably able to tell you more. >> >> Best Regards, >> >> Christian >> >> >> >> >> On Tue, Apr 17, 2012 at 6:35 PM, jeroen vranckx <jvr...@gm...>wrote: >> >>> >>> Thanks for the information christian, >>> >>> I have another question regarding using the wrapper to run a java proces >>> as console application on a windows cluster. The application is brought >>> online quit neatly, and I can see in the log that the JVM is started >>> succesfully. Now, if I bring the resource offline, i however won't see the >>> JVM shutting down in the logs. >>> >>> I would like to see this if possible. >>> Is this a problem with the cluster not interacting t-with the java >>> service wrapper? >>> Am I using a wrong implementation-possibility? using wrappersimpleApp at >>> the moment. >>> >>> Are there other possilities to check if there are JVM still running on >>> the machine? So by not using the wrapper? >>> >>> The thing is, that I'm having some issues concerning java-processes who >>> don't get shut down. So this means that a proces will keep running on one >>> node(even though the cluster itself says that the service is failed), and >>> will start up on the other node. Which means that the same proces is >>> running on both node. which is a disaster ^^. >>> >>> Hope you can help >>> >>> jeroen Vranckx >>> >>> On 6 April 2012 07:31, Christian Mueller < >>> chr...@ta...> wrote: >>> >>>> Hello Jeroen, >>>> >>>> I don't think you are able to start the service by issuing "wrapper.exe >>>> -s ..\conf\wrapper.conf" from console or any user session. >>>> >>>> When running the Wrapper with -t, it tells the Service Control Manager, >>>> to start the service. Using the API call StartService: >>>> >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686321%28v=vs.85%29.aspx >>>> >>>> For instance, if you call, net start {service}, it will also call >>>> StartService quite like the Wrapper when run as wrapper -t >>>> >>>> With the StartService call, the service manager will start then the >>>> service command (wrapper -s) and waits for the process to start the control >>>> dispatcher and connect to the service control manager. This is being done >>>> in the service process by calling StartServiceCtrlDispatcher. >>>> >>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686324%28v=vs.85%29.aspx >>>> Therefore, running bin\wrapper -s, from console without the service >>>> manager waiting for a connection, will ultimately cause a failure. >>>> >>>> That mechanism is a bit similar for instance to the TCP handshake. >>>> >>>> Hope this helps you out. >>>> >>>> Cheers, >>>> Christian >>>> >>>> >>>> On Wed, Apr 4, 2012 at 6:57 PM, jeroen vranckx <jvr...@gm...>wrote: >>>> >>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> For Developers, A Lot Can Happen In A Second. >>>> Boundary is the first to Know...and Tell You. >>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>>> http://p.sf.net/sfu/Boundary-d2dvs2 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Wrapper-user mailing list >> Wra...@li... >> https://lists.sourceforge.net/lists/listinfo/wrapper-user >> >> > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
