Menu
▾
▴
wrapper-user
|
From: Philip K. <pk...@sp...> - 2003-10-31 15:27:22
|
Thanks, I will work on creating something simple, (may take me a while). Please understand that I am also not a subject matter expert. I did try running wrapper via the command line vs a service and the same issue. Wrapper just creates the one process, the JVM? Then the JVM spawns the JNI functions? I am thinking it's a thread / COM issue. Has anyone else tried to keep pointer in the JVM that are used by several JNI functions from with in Wrapper? -----Original Message----- From: wra...@li... [mailto:wra...@li...] On Behalf Of Leif Mortenson Sent: Thursday, October 30, 2003 10:07 PM To: wra...@li... Subject: Re: [Wrapper-user] DCOM and wrapper Jim, > I haven't really had a chance to get back to it, but that's partly > because I don't know what to check next. Ditto. I tried doing some Google searches, but there is way too much info out there and without an example to get me started it is going take way too much time. >> If one of you guys could write up a simple simple application >> which demonstrates this problem and explain to me what is going, I >> might be able to figure out the problem and learn a little about COM >> at the same time :-) I emphasize the word simple here. > > Wow, you managed to use "simple" and "COM" in the same sentence. Is > that gramatically correct? Hey, that was after I said that I don't know what I am talking about :-) I should have known though. Very little of the Windows API that I have had to delve into to get the Wrapper working has been "simple". >> In either case the Wrapper process is using the CreateProcess API >> to create the > > The "CreateProcess" seems to have some inherent COM qualities, though > what I haven't a clue. :-/ How about an as simple as possible example program. Cheers, Leif ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Wrapper-user mailing list Wra...@li... https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Philip K. <pk...@sp...> - 2003-11-05 01:44:02
|
Ok, here is my guess on what is going on. DCOM/COM interfaces exists in a MTA (multi thread apartment) and maintains is own reference counter to threads using it, as stated my Microsoft. When I the java app in ran within wrapper the jni calls are started in new threads. I can view this via the Microsoft debugger. When the first call finishes that thread ends, (prior to me next jni call) and it kills the last and only reference in the MTA. Thus when the other JNI calls go to use this interface it now longer exists. So the question is why do the jni calls get place in new threads. This is not the results when the app is not ran within wrapper. IE "java myAppClass" Thanks Phil |
|
From: Leif M. <le...@ta...> - 2003-11-06 03:35:33
|
Philip, That is strange. I can't think of any reason why a new thread would be spawned when running under the Wrapper but not when run standalone. If the JNI is spawning a new thread then it must be something that the native code is going out of its way to do. There is nothing in the JNI call itself that would do this. Are you absolutely certain that there is nothing in your java application which is starting a new java thread that is in turn calling into JNI? If a thread is being spawned inside of the native call, then the original thread should be returning to the JVM context? Is it possible to confirm that this is happening? Cheers, Leif Philip Kubat wrote: > Ok, here is my guess on what is going on. DCOM/COM interfaces exists > in a MTA (multi thread apartment) and maintains is own reference > counter to threads using it, as stated my Microsoft. When I the java > app in ran within wrapper the jni calls are started in new threads. I > can view this via the Microsoft debugger. When the first call finishes > that thread ends, (prior to me next jni call) and it kills the last > and only reference in the MTA. Thus when the other JNI calls go to use > this interface it now longer exists. > > So the question is why do the jni calls get place in new threads. This > is not the results when the app is not ran within wrapper. IE “java > myAppClass” > > Thanks > > Phil > |
|
From: Leif M. <le...@ta...> - 2003-12-12 03:48:06
|
Philip, Have you made any progress with your DCOM issue? There was a post today on a related issue that may be at the root of your problems. He noticed that DCOM was expecting the JVM to be the one specified by JAVA_HOME, but the JVM launched by the Wrapper was not the same due to the value of the wrapper.java.command property. Go take a look at the issue and let me know the status of your problem. http://sourceforge.net/tracker/index.php?func=detail&aid=820216&group_id=39428&atid=425187 Cheers, Leif Philip Kubat wrote: > Ok, here is my guess on what is going on. DCOM/COM interfaces exists > in a MTA (multi thread apartment) and maintains is own reference > counter to threads using it, as stated my Microsoft. When I the java > app in ran within wrapper the jni calls are started in new threads. I > can view this via the Microsoft debugger. When the first call finishes > that thread ends, (prior to me next jni call) and it kills the last > and only reference in the MTA. Thus when the other JNI calls go to use > this interface it now longer exists. > > So the question is why do the jni calls get place in new threads. This > is not the results when the app is not ran within wrapper. IE “java > myAppClass” > > Thanks > > Phil > |
|
From: Jim R. <jr...@er...> - 2003-12-12 14:30:55
|
Leif, What's strange is the DCOM _client_ work fine. We have an =20 implementation of both the client and the server side of OPC. Both use =20 DLLs. The client is fine, the server fails. Jim On 2003.12.11 20:47, Leif Mortenson wrote: > Philip, > Have you made any progress with your DCOM issue? There was a post =20 > today on a related issue that may be at the root of your problems. He =20 > noticed that DCOM was expecting the JVM to be the one specified by =20 > JAVA_HOME, but the JVM launched by the Wrapper was not the same due =20 > to the value of the wrapper.java.command property. >=20 > Go take a look at the issue and let me know the status of your =20 > problem. =20 > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D820216&gro= up_id=3D39428&atid=3D425187 >=20 > Cheers, > Leif >=20 > Philip Kubat wrote: >=20 >> Ok, here is my guess on what is going on. DCOM/COM interfaces exists =20 >> in a MTA (multi thread apartment) and maintains is own reference =20 >> counter to threads using it, as stated my Microsoft. When I the java =20 >> app in ran within wrapper the jni calls are started in new threads. =20 >> I can view this via the Microsoft debugger. When the first call =20 >> finishes that thread ends, (prior to me next jni call) and it kills =20 >> the last and only reference in the MTA. Thus when the other JNI =20 >> calls go to use this interface it now longer exists. >>=20 >> So the question is why do the jni calls get place in new threads. =20 >> This is not the results when the app is not ran within wrapper. IE =20 >> =E2=80=9Cjava myAppClass=E2=80=9D >>=20 >> Thanks >>=20 >> Phil >> >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for =20 > IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys =20 > admin. > Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user --=20 Jim Redman (505) 662 5156 x85 http://www.ergotech.com |
|
From: Georg S. <geo...@ti...> - 2003-11-03 10:54:35
|
1) get Don Box's "Essential COM" and read / understand it 2) Start creating something simple... ;-) I don't think, CreateProcess() has some inherent COM qualities, it is the started process, that has. Georg Philip Kubat wrote: >Thanks, I will work on creating something simple, (may take me a while). >Please understand that I am also not a subject matter expert. > >I did try running wrapper via the command line vs a service and the same >issue. > >Wrapper just creates the one process, the JVM? Then the JVM spawns the JNI >functions? I am thinking it's a thread / COM issue. > >Has anyone else tried to keep pointer in the JVM that are used by several >JNI functions from with in Wrapper? > >-----Original Message----- >From: wra...@li... >[mailto:wra...@li...] On Behalf Of Leif >Mortenson >Sent: Thursday, October 30, 2003 10:07 PM >To: wra...@li... >Subject: Re: [Wrapper-user] DCOM and wrapper > >Jim, > > > >>I haven't really had a chance to get back to it, but that's partly >>because I don't know what to check next. >> >> > >Ditto. I tried doing some Google searches, but there is way too much >info out there and >without an example to get me started it is going take way too much time. > > > >>> If one of you guys could write up a simple simple application >>>which demonstrates this problem and explain to me what is going, I >>>might be able to figure out the problem and learn a little about COM >>>at the same time :-) I emphasize the word simple here. >>> >>> >>Wow, you managed to use "simple" and "COM" in the same sentence. Is >>that gramatically correct? >> >> > >Hey, that was after I said that I don't know what I am talking about >:-) I should have >known though. Very little of the Windows API that I have had to delve >into to get the >Wrapper working has been "simple". > > > >>> In either case the Wrapper process is using the CreateProcess API >>>to create the >>> >>> >>The "CreateProcess" seems to have some inherent COM qualities, though >>what I haven't a clue. >> >> > >:-/ > >How about an as simple as possible example program. > >Cheers, >Leif > > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Wrapper-user mailing list >Wra...@li... >https://lists.sourceforge.net/lists/listinfo/wrapper-user > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Wrapper-user mailing list >Wra...@li... >https://lists.sourceforge.net/lists/listinfo/wrapper-user > > |
|
From: Prashant R. <pra...@pr...> - 2003-11-04 05:26:22
|
Hello group, Integration method 1 requires that program "realpath" be copied along with wrapper, and the .so file. what is the significance of this "realpath" file? Thanks Prashant |
|
From: Leif M. <le...@ta...> - 2003-11-04 08:34:32
|
Prashant,
The realpath utility has actually not been used since version
3.0.3. I have left it in for
a couple releases to give projects a chance to upgrade their build
scripts. The references
that were still in the documentation were mistakes. They should have
been pulled out for
the 3.0.3 release.
The realpath utility used to help the shell script work around
symbolic link references
to find its true location. As of version 3.0.3, the shell script that
comes with the Wrapper
is now able to do this on its own making the file obsolete.
Thanks for pointing this out. I have fixed the docs for the next
release.
Cheers,
Leif
Prashant Reddy wrote:
>Hello group,
>
>Integration method 1 requires that program "realpath" be copied along with
>wrapper, and the .so file.
>what is the significance of this "realpath" file?
>
>Thanks
>Prashant
>
>
|
|
From: Prashant R. <pra...@pr...> - 2003-11-04 08:51:17
|
Leif, Thanks for the reply, clears things up. Couple more questions.. 1.On unix systems what is the difference between wrapper begin started in "console" more and "start" more.. Do both install the application as daemon? what happens if the wrapper is started in console mode in one xterm window, and then I close the same window (/session)? Will the application continue to run as daemon, meaning can i log out and expect it to be running? 2. What does "dump" mode do? Thanks Prashant ----- Original Message ----- From: "Leif Mortenson" <le...@ta...> To: <wra...@li...> Sent: Tuesday, November 04, 2003 2:04 PM Subject: Re: [Wrapper-user] realpath on unix? > Prashant, > The realpath utility has actually not been used since version > 3.0.3. I have left it in for > a couple releases to give projects a chance to upgrade their build > scripts. The references > that were still in the documentation were mistakes. They should have > been pulled out for > the 3.0.3 release. > > The realpath utility used to help the shell script work around > symbolic link references > to find its true location. As of version 3.0.3, the shell script that > comes with the Wrapper > is now able to do this on its own making the file obsolete. > > Thanks for pointing this out. I have fixed the docs for the next > release. > > Cheers, > Leif > > Prashant Reddy wrote: > > >Hello group, > > > >Integration method 1 requires that program "realpath" be copied along with > >wrapper, and the .so file. > >what is the significance of this "realpath" file? > > > >Thanks > >Prashant > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user |
|
From: Leif M. <le...@ta...> - 2003-11-04 09:10:04
|
Prashant, >1.On unix systems what is the difference between wrapper begin started in >"console" more and "start" more.. >Do both install the application as daemon? what happens if the wrapper is >started in console mode in one xterm window, and then I close the same >window (/session)? >Will the application continue to run as daemon, meaning can i log out and >expect it to be running? > > The "console" command will run the Wrapper in the current console. You will not be able to type "exit" in the console unless you first stop the Wrapper. If you kill the console via any other means then the Wrapper and its JVM will also be stopped because they are child processes of the console. The benefit of console mode is that you are able to see the Wrapper's output in the console as well as have the ability to press CTRL-C and CTRL-\ within that console. The "start" command is used to launch the Wrapper as a detached process. When running as a detached process, you will immediately regain control of the console used to launch the Wrapper. You will also be able to now close the console and the Wrapper will stay running. The drawbacks are that the only way to see the output is to "tail -f wrapper.log" and you will need to use the "stop" command to stop the wrapper and the "dump" command to request a thread dump. No matter how the Wrapper is launched, the "stop" and "dump" commands can always be used from another console. You mentioned installing the Wrapper as a daemon. The "start" command will launch the Wrapper as a daemon process, but it will not be restarted when the system is rebooted. This install process is a little different for every platform and depends on what the application being run by the Wrapper actually does. I have described how to do this on Solaris and Debian Linux systems on the following page. If you are using another platform, take a look at these for hints. I would also appreciate instructions for your platform so I can add it to the docs. http://wrapper.tanukisoftware.org/doc/english/launch-nix.html >2. What does "dump" mode do? > > Try it :-) It tells the Wrapper to in turn prompt the JVM to perform a thread dump. If you launched the Wrapper using the "console" command, you can also do this by pressing CTRL-\ in the console where the Wrapper is running. Cheers, Leif |
