[JBoss Tools] - Remote debugging via SSH?
by J. Koch
J. Koch [https://community.jboss.org/people/JoPe] created the discussion
"Remote debugging via SSH?"
To view the discussion, visit: https://community.jboss.org/message/766661#766661
--------------------------------------------------------------
Is there a way to debug a remote JBoss AS 7 from Eclipse / JBoss Tools via SSH?
I'm developing locally in Eclipse and testing on a local JBoss AS 7. I added the local JBoss AS to the JBoss Tools "Servers" view in Eclipse. Even though the line
{code}#JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"{code}
is commented in my [JBoss home]/bin/standalone.conf file, I can just hit the "Start the server in debug mode" button in my Servers view in Eclipse, and debugging will just start right away.
Now I have added a remote server that I can access through SSH to the servers list in the Servers view. I can deploy my application to the remote JBoss by dragging it to the server in the Servers view and start it through the "Start the server" button, just like with my local JBoss installation. Only the "start the server in debug mode" button is disabled for the remote server, and I have no clue why. I uncommented the line
{code}JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"{code}
in the remote server's [JBoss home]/bin/standalone.conf file, but this didn't help.
https://community.jboss.org/servlet/JiveServlet/showImage/2-766661-19741/... https://community.jboss.org/servlet/JiveServlet/downloadImage/2-766661-19... https://community.jboss.org/servlet/JiveServlet/showImage/2-766661-19743/... https://community.jboss.org/servlet/JiveServlet/downloadImage/2-766661-19...
Is it even possible to debug via SSH? Is there a different secure way for remote debugging that I can try?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/766661#766661]
Start a new discussion in JBoss Tools at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
[JBoss Messaging] - Jboss Messaging 1.4.3 GA; cluster node restart problem
by vineet badoni
vineet badoni [https://community.jboss.org/people/vineetbadoni] created the discussion
"Jboss Messaging 1.4.3 GA; cluster node restart problem"
To view the discussion, visit: https://community.jboss.org/message/772999#772999
--------------------------------------------------------------
Hi,
We are using Jboss 5.1.0 GA cluster which uses Jboss Messaging (1.4.3 GA default version shipped with Jboss 5.1.0 GA). We have a situation after few restarts of the cluster nodes only one node picks up the messages from the Queue.
Details
- We have 2 nodes cluster let us say Node 1(N1) and Node 2(N2).
- We have clustered queues deployed on both the nodes N1 and N2.
- We use clustered XA connection factory to post message in the Queue.
- We have MDBs which pick up the messages from the Queue.
Our product engine puts the messages in the local queue and Office load balances the messages to the cluster node and failover also work fine.
After sometime when we restart a cluster nodes one by one then we get into a state when only one node of the cluster(MDB) picks up the message from the Queue. But we verified that during restart there were no exceptions and errors in the server logs.
After googling over web we found this
https://issues.jboss.org/browse/JBMESSAGING-1931 https://issues.jboss.org/browse/JBMESSAGING-1931
and which suggests that re-starting the MDB container brings back the MDBs live and they start picking up the messages
The problems which we are facing with the proposed solution
- This solution does not work for us because we cannot monitor and wait for this state manually and re-start the MDB container. Is there a programmatic way of doing this? Meaning an intelligent way to decide that the system is in such kind of state and we have to restart the MDB containers.
The bigger problem is we really do not understand what is the reason for this? What is making the cluster to in this state.
Please suggest some clean solution.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/772999#772999]
Start a new discussion in JBoss Messaging at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
[Beginner's Corner] - jboss5 client
by yan jinjin
yan jinjin [https://community.jboss.org/people/milanball] created the discussion
"jboss5 client"
To view the discussion, visit: https://community.jboss.org/message/772897#772897
--------------------------------------------------------------
2012-10-30 11:46:06,660 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Configured: name=jboss.web.deployment:war=/RollingEventPortlets state=Instantiated mode=Manual requiredState=Configured
java.lang.RuntimeException: Exception setting attribute SecurityManagement on mbean jboss.web.deployment:war=/RollingEventPortlets
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:170)
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:114)
at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:58)
at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.install(ServiceController.java:274)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.management.InvalidAttributeValueException: Set attribute has class class org.jboss.security.integration.JNDIBasedSecurityManagement loaded from BaseClassLoader@159576c3{vfsfile:/C:/Program%20Files/Progress/Control%20Tower%202.1/portal/jboss-5.1.0.GA/server/default/conf/jboss-service.xml} that is not assignable to attribute class interface org.jboss.security.ISecurityManagement loaded from BaseClassLoader@35a9cea3{vfsfile:/C:/Program%20Files/Progress/Control%20Tower%202.1/portal/jboss-5.1.0.GA/server/default/deploy/RollingEventPortlets.war/}
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.checkAssignable(ModelMBeanAttributeInterceptor.java:229)
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:88)
at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:617)
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:166)
... 46 more
2012-10-30 11:46:06,660 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Real: name=vfsfile:/C:/Program%20Files/Progress/Control%20Tower%202.1/portal/jboss-5.1.0.GA/server/default/deploy/RollingEventPortlets.war/ state=PreReal mode=Manual requiredState=Real
org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.web.deployment:war=/RollingEventPortlets
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:118)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Exception setting attribute SecurityManagement on mbean jboss.web.deployment:war=/RollingEventPortlets
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:170)
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:114)
at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:58)
at org.jboss.system.microcontainer.ConfigureAction.installAction(ConfigureAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.install(ServiceController.java:274)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:90)
... 29 more
Caused by: javax.management.InvalidAttributeValueException: Set attribute has class class org.jboss.security.integration.JNDIBasedSecurityManagement loaded from BaseClassLoader@159576c3{vfsfile:/C:/Program%20Files/Progress/Control%20Tower%202.1/portal/jboss-5.1.0.GA/server/default/conf/jboss-service.xml} that is not assignable to attribute class interface org.jboss.security.ISecurityManagement loaded from BaseClassLoader@35a9cea3{vfsfile:/C:/Program%20Files/Progress/Control%20Tower%202.1/portal/jboss-5.1.0.GA/server/default/deploy/RollingEventPortlets.war/}
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.checkAssignable(ModelMBeanAttributeInterceptor.java:229)
at org.jboss.mx.interceptor.ModelMBeanAttributeInterceptor.invoke(ModelMBeanAttributeInterceptor.java:88)
at org.jboss.mx.interceptor.PersistenceInterceptor.invoke(PersistenceInterceptor.java:76)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
at org.jboss.mx.server.AbstractMBeanInvoker.setAttribute(AbstractMBeanInvoker.java:461)
at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:617)
at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java:166)
... 46 more
2012-10-30 11:46:06,676 WARN [org.jboss.system.server.profileservice.hotdeploy.HDScanner] (HDScanner) Failed to process changes
org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/772897#772897]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
[jBPM] - Re: JBPM Persistence Error
by Jason J
Jason J [https://community.jboss.org/people/jasonjho] created the discussion
"Re: JBPM Persistence Error"
To view the discussion, visit: https://community.jboss.org/message/772892#772892
--------------------------------------------------------------
Hi Kris,
I have a workflow that should be persisted at a wait-state (safe point) that uses an intermediateCatchEvent via conditionalExpression. When the process is reloaded, my understanding is the process instance will continue where it left off - as you mentioned.
However, the workflow is designed so that a drools rule is what actually unblocks the blocking conditional wait step.
ex:
<intermediateCatchEvent id="_6" name="Wait for Document Approval" >
<conditionalEventDefinition>
MyDocument(status == "Approved")
</...>
</...>
then in a rule defined in the same session:
rule X
when:
....
then:
$myDocument.setStatus("Approved")
I see the rule firing, but the workflow is never advanced out of the block state.
Any explanation?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/772892#772892]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
[jBPM] - Persisted process not resuming from wait state
by Jason J
Jason J [https://community.jboss.org/people/jasonjho] created the discussion
"Persisted process not resuming from wait state"
To view the discussion, visit: https://community.jboss.org/message/772878#772878
--------------------------------------------------------------
Environment: jBPM 5.2.0 + Drools 5.3.1 + H2
I have a jBPM flow that is configured for persistence and after a server restart, is reloaded the following way:
{code}
ksession = JPAKnowledgeService.+loadStatefulKnowledgeSession+(session_*id*, kbase, *null*, env);
ksession.addEventListener(listener) // this doesn't seem to work
ksession.fireAllRules()
{code}
At this point, shouldn't the workflow process be restarted? I can see that there are processinstanceinfo, sessioninfo and eventtype tables in my database, so I know some information was persisted from my original execution. But why is the event listener not being called after the reload to let me know what node the workflow is currently on, and subsequently, what node the process is traveling to?
In my workflow, let's say I am halfway through and I come across a wait states that looks like the following:
{code}
<intermediateCatchEvent id="_6" name="Wait for Document Approval" >
<conditionalEventDefinition>
MyDocument(status == "Approved")
</...>
</...>
{code}
At this point, a rule is evaluated and changes the state on MyDocument to "Approved", causing this wait state to unblock and move to the next node in the workflow.
I thought at this point, jBPM would persist the process b/c it is considered a "safe point". But when my server is restarted and I try to advance the workflow from this wait point (let's say I change the document status to "Approved") - it never moves forward. Part of me thinks that the worklow is not really running -- only the rules alone that are being fired in the session.
So my question is - how can I verify that this workflow is correctly restarted and resumed? I thought the EventListener on the session would be notified of node entry/exit as it does normally.
Any ideas?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/772878#772878]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 5 months
