[Beginners Corner] - Access Remote JMS
by ranadheer.machineni
Hi,
i am running a application in Jboss, which connects to JMS of another Remote JBoss. the problem is i am able to connect and receive Topics when i supply remote url to context like below
|
| Properties pro = new Properties();
| pro.put(Context.PROVIDER_URL,"jnp://remotehost:1099");
| jndiContext = new InitialContext(pro);
|
|
but when i remove the above and supply to jms-ds.xml like below its not working. it says the name of the Topic not found
|
| <mbean code="org.jboss.jms.jndi.JMSProviderLoader"
| name="jboss.mq:service=JMSProviderLoader,name=JMSProvider">
| <attribute name="ProviderName">DefaultJMSProvider</attribute>
| <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
| <!-- The combined connection factory -->
| <attribute name="FactoryRef">XAConnectionFactory</attribute>
| <!-- The queue connection factory -->
| <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
| <!-- The topic factory -->
| <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
| <!-- Uncomment to use HAJNDI to access JMS-->
| <attribute name="Properties">
| java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
| java.naming.provider.url=remotehost:1099
| </attribute>
|
| </mbean>
|
|
i tried with port number 1100 also, but help less. i need to use the second way any ways. any help is highly appreciated
Thanks
R
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157658#4157658
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157658
18 years, 1 month
[JNDI/Naming/Network] - Accesing Remote JMS, working when remote URL provided to the
by ranadheer.machineni
Hi,
i am running a application in Jboss, which connects to JMS of another Remote JBoss. the problem is i am able to connect and receive Topics when i supply remote url to context like below
Properties pro = new Properties();
| pro.put(Context.PROVIDER_URL,"jnp://remotehost:1099");
| jndiContext = new InitialContext(pro);
|
but when i remove the above and supply to jms-ds.xml like below its not working. it says the name of the Topic not found
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
| name="jboss.mq:service=JMSProviderLoader,name=JMSProvider">
| <attribute name="ProviderName">DefaultJMSProvider</attribute>
| <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
| <!-- The combined connection factory -->
| <attribute name="FactoryRef">XAConnectionFactory</attribute>
| <!-- The queue connection factory -->
| <attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
| <!-- The topic factory -->
| <attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
| <!-- Uncomment to use HAJNDI to access JMS-->
| <attribute name="Properties">
| java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
| java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
| java.naming.provider.url=remotehost:1099
| </attribute>
|
| </mbean>
i tried with port number 1100 also, but help less. i need to use the second way any ways. any help is highly appreciated
Thanks
R
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157652#4157652
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157652
18 years, 1 month
[JBoss jBPM] - Workflow with nested fork gets stuck when tasks are complete
by glen.johnson
I'm having a problem with a workflow, containing a nested fork, getting "stuck". This only happens when tasks are completed in a certain order.
I'm wondering if someone can have a look at this as we have several customers blocked on this one - and I have reached a dead end with trying to find a fix.
Here is the process definition:
<?xml version="1.0" encoding="UTF-8"?>
|
| <process-definition xmlns="urn:jbpm.org:jpdl-3.1" name="wf:fundingrequest">
|
| <swimlane name="initiator" />
|
| <start-state name="start">
| <task name="wf:startFundingRequestTask" swimlane="initiator" />
| <transition name="startToStep1" to="step1" />
| </start-state>
|
| <task-node name="step1">
| <task name="wf:step1FundingRequestTask" swimlane="initiator" />
| <transition name="step1ToFork1" to="fork1" />
| </task-node>
|
| <fork name="fork1">
| <transition name="fork1ToDec1" to="dec1" />
| <transition name="fork1ToStep2c" to="step2c" />
| </fork>
|
| <decision name="dec1">
| <transition name="No" to="join2"></transition>
| <transition name="Yes" to="fork1a">
| <condition>#{2 > 1}</condition>
| </transition>
| </decision>
|
| <fork name="fork1a">
| <transition name="fork1aToStep2a" to="step2a" />
| <transition name="fork1aToStep2b" to="step2b" />
| </fork>
|
| <task-node name="step2a">
| <task name="wf:step2aFundingRequestTask" swimlane="initiator" />
| <transition name="step2aToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2b">
| <task name="wf:step2bFundingRequestTask" swimlane="initiator" />
| <transition name="step2bToJoin1" to="join1" />
| </task-node>
|
| <task-node name="step2c">
| <task name="wf:step2cFundingRequestTask" swimlane="initiator" />
| <transition name="step2cToJoin2" to="join2" />
| </task-node>
|
| <join name="join1">
| <transition name="join1ToJoin2" to="join2" />
| </join>
|
| <join name="join2">
| <transition name="join2ToStep3" to="step3" />
| </join>
|
| <task-node name="step3">
| <task name="wf:step3FundingRequestTask" swimlane="initiator" />
| <transition name="step3ToEnd" to="end" />
| </task-node>
|
| <end-state name="end" />
|
| </process-definition>
|
We have a custom Join class which extends the default jBPM Join class. We have this custom Join class, because we have an Event.EVENTTYPE_NODE_LEAVE action handler JoinEndForkedTokens class which needs to get called when the Join node is "left".
The key thing is that the getting stuck problem only occurs when we have this custom Join class "wired in" and the tasks are completed in a certain order
The task completion order that exibits the "getting stuck" problem is as follows:
When task "step2c" is completed after tasks "step2a" and "step2b", then the workflow path does not leave node "join2" - and thus task "step3" does not get reached.
The following files are attached:
- The process definition for this nested fork workflow,
http://rapidshare.com/files/121903643/nestedfork-workflow-processdefiniti...
- The hibernate config and jbpm config files we are using
http://rapidshare.com/files/121903641/hibernate-context.xml.html
http://rapidshare.com/files/121903642/jbpm.cfg.xml.html
- A ZIP file containing our own workflow processing classes. Our custom Join class and JoinEndForkedTokens action handler are in the jBPM folder therein.
http://rapidshare.com/files/121903644/workflow.zip.html
- Two debug log files (with debug turned on for org.jbpm and org.alfresco.repo.workflow - the package for our workflow processing classes)
-- alfresco.step3-not-reached.log - for the above getting stuck scenario
http://rapidshare.com/files/121903639/alfresco.step3-not-reached.log.html
-- alfresco.step3-reached.log - for when "step2c" is NOT completed after "step2a" and "step2b", and "join2" is left and "step3" reached - and all is fine.
http://rapidshare.com/files/121903640/alfresco.step3-reached.log.html
I can't find anything wrong with our custom Join and neither our action handler JoinEndForkedTokens class (added as an action by the custom Join code), but when I change the hibernate and jbpm config files to point back to the default jBPM Join class, then the workflow does not get stuck.
What I have found so far is that when the workflow gets "stuck" it is because jBPM has "forgotten" to call the Join.execute() method (on Join2) after step2c has been completed - the problem only happening in the scenario when step2c is completed after step2a & step2b. But Join.execute() on Join2 is indeed called when both step2a and step2b have been completed, and Join1 is left.
... and for some reason, this weirdness only happens when we wire in our own custom Join class (which extends the default jBPM one).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157651#4157651
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157651
18 years, 1 month