[JNDI/Naming/Network] - Best practices for inter-server JNDI lookup
by sgrenholm
Hello, I'm looking for best practices in communicating over JNDI (Remote EJB lookup and JMS) between two app servers. Ideas and gotchas are welcome!
My current testing topology involves 2 JBoss app servers, non-clustered, on the same machine. I expect in the future either app server will need to be clustered, but that isn't my main concern right now.
At present app server 1 runs 4.0.5.GA. App server 2 runs 4.0.3SP1, because it runs a 3rd party program that sadly requires that version - and business concerns require a separate app server (in deployment, they won't run on the same machine.)
Here's what I need to do: App server 2 needs to invoke both EJB and write to JMS queues on App server 1. App server 2 needs to write to queues on AS1.
Here's what I have. It works [woo-hoo...], after making sure there are no port conflicts in each app server. But I'd like to know if what I've done seems reasonable and robust. In particular, I defined an alias (LinkRefPair) to the XA Connection Factory on AS2 and made sure it was visible to AS1 - otherwise, AS1 couldn't connect to the new queue defined on AS2, even though it could see its name in JNDI (NameNotFoundException).
It feels wrong to have AS1 use AS2's Connection Factory, but it works.
On App Server 2, I've placed the following xml file in default/deploy:
| <server>
| <!-- Define a queue on AS2 as an endpoint for AS1, used by AS2 MDBs -->
| <mbean code="org.jboss.mq.server.jmx.Queue"
| name="jboss.mq.destination:service=Queue,name=FromAS1Queue">
| <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
| </mbean>
|
| <!-- export an alias to the transactional connection factory
| and scope it to qualified name (here, reusing AS2's JNDI 'queue/' )
| so that AS1 can use this connection factory
| without bringing in everything else at the top JNDI level.
| It appears that the AS1 needs the connection factory in
| order to use the FromAS1Queue defined above -->
| <mbean code="org.jboss.naming.LinkRefPairService"
| name="jboss.jms:alias=AS1QueueConnectionFactory">
| <attribute name="JndiName">queue/QueueConnectionFactory</attribute>
| <attribute name="RemoteJndiName">ConnectionFactory</attribute>
| <attribute name="LocalJndiName">java:/JmsXA</attribute>
| <depends>jboss:service=Naming</depends>
| </mbean>
|
| <!-- Addition of an external context MBean for AS2->AS1 EJB integration
| ejb-jar and jboss xml defines ejbs under ejb/myremotes
| AS1 is on port 1099, AS2 is at 21099
| -->
| <mbean code="org.jboss.naming.ExternalContext"
| name="jboss.jndi:service=ExternalContext,jndiName=external/as1beans">
| <attribute name="JndiName">external/as1beans</attribute>
| <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=jnp://localhost:1099/ejb/myremotes
| </attribute>
| <attribute name="InitialContext">javax.naming.InitialContext</attribute>
| <attribute name="RemoteAccess">true</attribute>
| <depends>jboss:service=Naming</depends>
| </mbean>
|
| <!-- Addition of an external context MBean for JMS integration -->
| <mbean code="org.jboss.naming.ExternalContext"
| name="jboss.jndi:service=ExternalContext,jndiName=external/as1queues">
| <attribute name="JndiName">external/as1queues</attribute>
| <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=jnp://localhost:1099/queue
| </attribute>
| <attribute name="InitialContext">javax.naming.InitialContext</attribute>
| <attribute name="RemoteAccess">true</attribute>
| <depends>jboss:service=Naming</depends>
| </mbean>
| </server>
|
And on App Server 1, a parallel xml file defines an external context JMX bean pointing to the queues - and the aliased connection factory - on AS2:
| <mbean code="org.jboss.naming.ExternalContext" name="jboss.jndi:service=ExternalContext,jndiName=as2/AS2server">
| <attribute name="JndiName">as2/AS2server</attribute>
| <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=jnp://localhost:21099/queue
| </attribute>
| <attribute name="InitialContext">javax.naming.InitialContext</attribute>
| <attribute name="RemoteAccess">true</attribute>
| <depends>jboss:service=Naming</depends>
| </mbean>
|
With this, AS1 can write to the queue on AS2 - and could probably listen using an MDB:
| Context initialContext = new InitialContext();
| QueueConnectionFactory queueConFac = (QueueConnectionFactory) initialContext.lookup("as2/AS2server/QueueConnectionFactory");
|
| connection = queueConFac.createQueueConnection();
| QueueSession queueSession = connection.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
| Queue queue = (Queue) initialContext.lookup("as2/AS2server/FromAS1Queue");
|
Many thanks for your comments, Stephen
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058412#4058412
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058412
19Â years
[JBossCache] - difference between mcast_addr and bind_addr
by seniorfrog
I am using treecache in a clustered environment (16 total nodes, 4x4). Our current configuration only specifies a bind_addr, but I believe specifying both a mcast_addr and mcast_port might help the performance issues we're running into. I'm trying to convince a few people to specify a mcast_addr and port, but I'm not sure I totally understand the difference between the two (even after going through all the documentation). Can someone please tell me the difference between these two parameters? Similarly, does a mcast_addr need to be specified if a bind_addr is already specified?
Here is some information just in case you might want to know:
JBossCache version 1.4.1 SP3
Hibernate version 3.2.4 ga
Websphere version 6.0.x
Solaris Machines (not sure of the exact version, but pretty recent).
| <UDP bind_addr="xxx.xxx.xxx"
| ip_mcast="true"
| ip_ttl="32"
| mcast_send_buf_size="150000"
| mcast_recv_buf_size="80000"
| ucast_send_buf_size="150000"
| ucast_recv_buf_size="80000"
| loopback="false"
| />
|
We are using optimistic locking with repl_sync, but this might change as we go through our performance/scalability cycle.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058409#4058409
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058409
19Â years
[JBoss jBPM] - Problem with Exception Handler or I just can't do this?
by jgreiner
Could someone tell me if this is an issue with exception handling or if I am just missing something, and doing it wrong.
Most nodes or ActionHandlers that access the database, or check on data, I have an exception handler. Something like
| <exception-handler exception-class="java.lang.Exception">
| <action class="com.pubco.das.process.handlers.PreflightExceptionHandler"></action>
| </exception-handler>
|
Then my exception handler sets the process instance to a task node.
| Node ebNode = ctx.getProcessInstance().getProcessDefinition().getNode(ProcessVariables.DASMASTER_EXCEPTION);
| ebNode.enter(ctx);
|
What I am finding is that this is working fine, except the node that threw the exception went ahead and transitioned its self to the next node in the process. I am seeing this on Decision nodes on a regular basis, I am currently testing to see if this happens on other nodes.
Could someone tell me if that is wrong or a bad practice? Do I need to manually stop the processInstance?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058408#4058408
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058408
19Â years
[JBoss Seam] - s:decorate vs ui:decorate - different behavior for multiple
by ASavitsky
Are these two (Seam decorate tag and Facelets ui:decorate) supposed to be similar? For example, let's take the following template (taken from Seam docs) that decorates input fields with errors:
template.xhtml:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
| xmlns:ui="http://java.sun.com/jsf/facelets"
| xmlns:s="http://jboss.com/products/seam/taglib">
| <s:span style="#{invalid ? 'color:red' : ''}">
| <ui:insert name="label" />
| <s:span rendered="#{required}"> *</s:span>
| </s:span>
| <s:span>
| <s:validateAll>
| <ui:insert />
| </s:validateAll>
| </s:span>
| </ui:composition>
When we're using ui:decorate, there are two columns created in the table, one for label, another one for input field (but no error decoration, obviously):
<h:panelGrid columns="2">
| <ui:decorate id="username" template="template.xhtml">
| <ui:define name="label">Username:</ui:define>
| <h:inputText value="#{user.username}" required="true" />
| </ui:decorate>
| </h:panelGrid>
When we're using s:decorate, it results in only one column being created, with both label and input field in it.
<h:panelGrid columns="2">
| <s:decorate id="username" template="template.xhtml">
| <ui:define name="label">Username:</ui:define>
| <h:inputText value="#{user.username}" required="true" />
| </s:decorate>
| </h:panelGrid>
Is this a desired behavior? I wonder whether s:decorate is supposed to behave the same way in respect to its child components...
Alex
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058405#4058405
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058405
19Â years
[JBoss Seam] - When and where to use jBPM in Seam app ?
by dkane
If I understand correctly, jBPM was developed for :
1) Defining navigation and pageflows
2) Providing support for business process context, which is wider than session context. This way componens can be persisted across multiple users/sessions. Also, tasks can be logically assigned to users.
For first task, in my case, JSF navigation rules is pretty enough and I don't need jBPM.
Second, cross-user context and assignments - yes, could be convenient for order management. In my application, order passes through multiple states and is being processed by multiple executives. I guess this is the classic case of jBPM practice.
But I afraid I don't understand the whole power of jBPM here comparing to oldschool approach. Order and it's status is being persisted in database, anyway. Executives can see only orders with states corresponding to their responsibilities, it is easy to program. Can jBPM simplify this job and/or encapsulate any functionality which requires lots of manual coding ? Or do I miss yet another important aspects of jBPM usage ?
Thank you.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058404#4058404
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058404
19Â years