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

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

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