[ http://jira.jboss.com/jira/browse/JBASM-3?page=comments#action_12421123 ] Galder Zamarreno commented on JBASM-3: -------------------------------------- A while back I had a brief discussion with Bryan on how to automate generation of thread dumps upon certain circumstances: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120189#... In this case, the trigger would have been non received responses to cluster wide sync RPCs, but your scenario could be covered as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Dimitris Andreadis commented on JBASM-3: ---------------------------------------- Don't know what a pure java solution would be in this case. I think Mladen has created an abstraction layer that let's you do this sort of stuff, but it still uses a native APR layer in the bottom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Dimitris Andreadis commented on JBASM-3: ---------------------------------------- The problem is that is the server is in shutdown mode or stuck it may not be able to respond to a remote JMX request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Aleksandar Kostadinov commented on JBASM-3: ------------------------------------------- I looked at the things and would suggest the following solutions: 1. For the listThreadDump() to work, server manager has to RMI connect to the server and call the method. It currently uses shutdown.jar for the job. So I'm going to change: 1.1. shutdown.jar to *not* be used 1.2. connect to the JBoss server 1.3. call the shutdown() method of jboss.system:type=Server 1.4. wait for server to shutdown (return if successful) 1.5. try calling listThreadDump() and output to server log or stdout (ignoring exceptions) 1.6. destroy process positives: * higher chance to be able to call the method successfully as server connection is not created after unknown number of services are already undeployed negatives: * dumps come in html markup (I tried EAP 4.3 CP02) * additional dependencies to server manager (jars) 2. for kill-3 jboss-native needs a pre-compiled native library to work on any platform. So I see it as an overkill for us. Instead I can change server start method to use specially crafted bash or/and perl script if the executable is found in PATH. Then doing destroy on the spawned process will cause kill -3 to the server process if it still exists followed by a kill -9. We can't send ctrl+c to a terminal so on windows one would be stuck installing cygwin or perl for the feature to work. As well every platform I've looked at can have perl and/or bash installed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Dimitris Andreadis reassigned JBASM-3: -------------------------------------- Assignee: Aleksandar Kostadinov (was: Shelly McGowan) Why not (about the 2nd threadump method) I think we should go first for the pure java solution. If researching the native option maybe you could look int the jboss-native libs. Mladen has made a wrapper that works on windows, too, so you can send signals and stuff. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Aleksandar Kostadinov updated JBASM-3: -------------------------------------- Attachment: (was: sm.diff) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Aleksandar Kostadinov commented on JBASM-3: ------------------------------------------- I have great issues with the classpath where things work in server manager test suite but not ant. As well I have some issues with jboss logging. And finally when interrupted apache-ant says stupid things. I'll ask questions to the forums. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Aleksandar Kostadinov commented on JBASM-3: ------------------------------------------- The biggest problem with added dependencies is that now jars need to be put in the jvm's classpath and not only the ant's taskdef. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179035#... If things cannot be fixed we need one of the following: 1. Give up from pure java solution 2. create a separate executable jar for the job so classpath can be passes to the forked process 3. add the classpath in the build.sh but that would prevent running test suite with "ant" executable without passing special parameters Please, advise! I have a small issue with jboss logging as well but should be considered after this one is resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBASM-3?page=com.atlassian.jira.plugin... ] Aleksandar Kostadinov commented on JBASM-3: ------------------------------------------- I resolved the issue with logging that for sure would have occurred in JBASM-13 as well. Unfortunately work done JBASM-12 and JBASM-13 require me to rework the changes I made and didn't commit before testing :/ btw JBASM-13 will require the additional classes I'm going to add to the server tasks' classpath as well changes to jboss-test ant tasks (to set Thread ContextClassLoader). So release of these changes is good to happen in that order: 1. jboss-test - server ant tasks improvement 2. server-manager including changes from JBASM-(3|12|13) 3. changes in jboss as test suite wiring these together -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira