OK. The RMI hang problem is now fixed under http://svn.apache.org/viewvc?rev=740884&view=rev. The ANT script works nicely now.
Thanks, Raymond From: Raymond Feng Sent: Wednesday, February 04, 2009 12:11 PM To: [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml It looks the RMI threads are still active. Let me try to see if I can fix it by shutting down the RMI layer in binding.rmi code. Thanks, Raymond C:\Program Files\Java\jdk1.6.0_11\bin>jstack.exe 10140 2009-02-04 12:09:30 Full thread dump Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing): "DestroyJavaVM" prio=6 tid=0x00637400 nid=0x1c70 waiting on condition [0x0000000 0..0x0036fd4c] java.lang.Thread.State: RUNNABLE "RMI TCP Accept-8099" daemon prio=6 tid=0x03547400 nid=0x27b4 runnable [0x03e0f0 00..0x03e0fa14] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x229de420> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr ansport.java:369) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3 41) at java.lang.Thread.run(Thread.java:619) "GC Daemon" daemon prio=2 tid=0x0353d400 nid=0x1d08 in Object.wait() [0x03dbf000 ..0x03dbfa94] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x230d1d70> (a sun.misc.GC$LatencyLock) at sun.misc.GC$Daemon.run(GC.java:100) - locked <0x230d1d70> (a sun.misc.GC$LatencyLock) "RMI Reaper" prio=6 tid=0x0352f800 nid=0x2080 in Object.wait() [0x03d6f000..0x03 d6fb14] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x230d1020> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x230d1020> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:333) at java.lang.Thread.run(Thread.java:619) "RMI TCP Accept-0" daemon prio=6 tid=0x03465800 nid=0x1270 runnable [0x03d1f000. .0x03d1fb94] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x230d1078> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTr ansport.java:369) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:3 41) at java.lang.Thread.run(Thread.java:619) "Low Memory Detector" daemon prio=6 tid=0x02b52400 nid=0x1a80 runnable [0x000000 00..0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x02b4c400 nid=0x211c waiting on condition [0x00000000..0x02daf9bc] java.lang.Thread.State: RUNNABLE "Attach Listener" daemon prio=10 tid=0x02b4ac00 nid=0x2468 waiting on condition [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x02b49800 nid=0x27ac runnable [0x0000000 0..0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x02b41000 nid=0x2ac0 in Object.wait() [0x02cbf000 ..0x02cbfa94] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x22ed4a08> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x22ed4a08> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x02b3fc00 nid=0x8c8 in Object.wait() [0x 02c6f000..0x02c6fb14] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x22ed4a90> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x22ed4a90> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x02b3e000 nid=0x750 runnable "VM Periodic Task Thread" prio=10 tid=0x02b54800 nid=0x2bcc waiting on condition JNI global references: 968 Thanks, Raymond From: Simon Laws Sent: Wednesday, February 04, 2009 11:00 AM To: [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml On Wed, Feb 4, 2009 at 6:39 PM, Raymond Feng <[email protected]> wrote: Hi, We have cases that we need to stop the node after it's launched or wait for a user action (press 'q'). To support that, I added a '-t <TTLInMilliSeconds >' option for the JSE and Equinox launcher. For JSE: cd distribution\all java -jar target\features\manifest.jar ..\..\samples\calculator\target\sample-calculator.jar -t 1000 (wait for 1000 ms before the node is stopped) java -jar target\features\manifest.jar ..\..\samples\calculator\target\sample-calculator.jar (wait for user to press 'q') For Equinox: (-config target\features\configuration is optional) cd distribution\all java -jar target\features\equinox-manifest.jar -t 1000 -config target\features\configuration ..\..\samples\calculator\target\sample-calculator.jar (wait for 1000 ms before the node is stopped) java -jar target\features\equinox-manifest.jar -config target\features\configuration ..\..\samples\calculator\target\sample-calculator.jar (wait for user to press 'q') Thanks, Raymond -------------------------------------------------- From: "Raymond Feng" <[email protected]> Sent: Tuesday, February 03, 2009 10:10 PM To: <[email protected]> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml I also got the JSE launcher working the same way, for example: java -jar target\features\manifest.jar ..\..\samples\calculator\target\sample-calculator.jar Thanks, Raymond -------------------------------------------------- From: "Luciano Resende" <[email protected]> Sent: Tuesday, February 03, 2009 7:00 PM To: <[email protected]> Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml On Tue, Feb 3, 2009 at 6:05 PM, Raymond Feng <[email protected]> wrote: Hi, I made some progress to use Apache commons-cli to parse the command line arguments for the Equinox Launcher. It can now process the following options: [-config <equinoxConfiguration>]: The configuration folder for Equinox [-c <compositeURI>]: The composite URI contribution1 ... contributionN: A list of contribution files or URLs To try it, you can build the distribution/all first using "mvn clean install", then run the following command: java -jar target\features\equinox-manifest.jar -config target\features\configuration ..\..\samples\calculator-equinox\target\sample-calculator-equinox.jar Looks good... A related subject: I don't see a need to have a separate launcher which delegates to the JSE or Equinox Launcher. Can we just update the shell script to directly call the JSE or Equinox launcher main class? I'm working on the UNIX script based on the one from Tomcat. +1 Do we even need a script ? Can't we just document the command line in the sample README, and provide the necessary ant targets so users can do : ant run or ant run-managed. This way we avoid exposing the user that just want to run the sample, to multiple magical layers. Thanks, Raymond From: Raymond Feng Sent: Friday, January 30, 2009 10:02 AM To: [email protected] ; [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml For c), you can look at the META-INF/MANIFEST.MF inside generated "features/equinox-manifest.jar". The classpath contains only the entries for the equinox launcher. To pass in the configuration (where are the bundles) to Equinox, use "-Dosgi.configuration.area=features/configuration". From: ant elder Sent: Friday, January 30, 2009 9:50 AM To: [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml On Fri, Jan 30, 2009 at 5:38 PM, Raymond Feng <[email protected]> wrote: More comments inline. Thanks, Raymond From: ant elder Sent: Friday, January 30, 2009 9:23 AM To: [email protected] Subject: Re: Command-line launcher, was: Re: svn commit: r737681 - /tuscany/java/sca/samples/build-common.xml On Fri, Jan 30, 2009 at 4:56 PM, Raymond Feng <[email protected]> wrote: A few comments: 1) Our distribution already contains the manifest.jar and equinox-manifest.jar: * manifest.jar has the Main-Class set to the node launcher and Class-Path set to the required Tuscany modules and 3rd party jars * equinox-manifest.jar has the Mani-Class set to the equinox node launcher and Class-Path set to the dependent jars for the launcher itself without pulling other Tuscany modules and 3rd party jars which are bundles under OSGi. We also have the configuration generated to list the bundles. It can be pointed using -Dosgi.configuration.area (system property). I suggest that our tuscany.bat to leverage that instead of using the osgi.config and default.config which require manual maintenance and ** classpath drags unnecessary jars. 2) Let's use -<option> instead of positional arguments. For example, tuscany -osgi contrib 3) We should allow the deployment composite to be used to launch the node, for example tuscany -composite <compositeURI> contrib1 contrib2 ... contribN The compositeURI can be a relative URI in one of the contribs or an absolute URI which points to an external composite file. 4) Do we prefer to have multiple commands for different purposes or one command with different options? Some of those sounds really good, just to explain, there are two things that led to it being as it is right now. Firstly lots of ML discussion about runtimes, launching, and running samples where aspects of how this should work came up, without giving links to all the emails an OTTOMH summary is - to have a Tuscany persona, to remove the mystery about what happens, to make it simple, intuitive and consistent, and to enable simple sample builds. The second reason its like this is to get something going quickly with minimum work as it wasn't obvious if eveyone agreed we wanted something like this. One other thing was to make the .bat/.sh scripts as simple as possible as they're hard to maintain. For (1) i'm nervous it makes it complicated and makes it hard to see whats going on. The current config file is simple and fairly intuitive so there is no mystery compared to digging around in a bat script to point to jars somewhere else which you then have to unzip and look in the manifest. <rfeng>I have a different take here for the following reasons: a) MANIFEST.MF is defined by the jar spec and "Main-Class" and "Class-Path" are standard headers b) The manifest.jar and equinox-manifest.jar have the accurate set of classpath entries. And we also support the different configurations based on the distro, such as one for core, and one for web service. They are automatically generated by Tuscany and no manual steps are required. c) The OSGi launcher should not pull in other Tuscany modules and 3rd party jars which are OSGi bundles. Having them on the launcher classpath is problematic. d) Arguing about mystery, the launcher is already on the magical path anyway. I'm trying to avoid intuitive directory scanning in non-development mode. Well it doesn't seem as magical or mysterious as the alternative to me, any newbie could look at the bat scripts and config files and likely understand what was going on. IMVHO we seem to over engineer and complicate so much in Tuscany, to a actual user running tuscany.bat would it really make any difference at all? What ever, how about we wait till all the distribution, feature, and sample running discussions have got a bit more finalized so we know for sure if we need something like this launcher at all and if so exactly what it needs to do? For (c) could you give a bit more detail? We can probably fix it just by adding some more to the config file. ...ant -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://lresende.blogspot.com/ I switched calculator-rmi-sevice/buil.xml over to use this launcher and specify a timeout. A handy tactical fix. You'll see in itest/samples/build.xml that the rmi bit is commented out. The timeout seems to work but after the node is stopped the node launcher doesn't terminate. I expect we are holding some thread open somewhere. I don't think this has anything to do with the addition of the timeout but I don't have time to check it out just now. Simon
