I am trying to get a MessageDriven (EJB 3) bean to subscribe to a JMS Topic on another glassfish instance on another host. Is this possible?
In the Glassfish console you can modify the JMS server and point it to another Glassfish instance or a standalone OpenMQ broker. Although you can configure several JMS hosts to my knowledge Glassfish will always use the one called default_JMS_host so that's the one you want to edit.
Just one thing: in such a setup the two server instances will share queues and topics, which may not be what you want if the two servers are for example running the same application but don't want to share e.g a particular queue. This can easily be solved via the Destination Resources configuration, by specifying different physical names for that queue.
Related
I have a Symfony application that is running on several servers behind a load balancer. So I have separate hosts www1, www2, www3, etc.
At the moment I'm running messenger:consume only on www1, in fear of race conditions and potentially messages being handled twice.
Now I have a scenario where I need to execute a command on each host.
I was thinking of using separate transports for each host and running messenger:consume on each, consuming only messages from its respective queue. However I want the configuration to be dynamic, i.e. I don't want to do another code release with different transports configuration when a new host is added or removed.
Can you suggest a strategy to achieve this?
If you want to use different queues and different consumers... just configure a different DSNs for each www, stored on environment variables (not code). Then you could have different queues or transports for each server.
The Transport Configuration can include the desired queue name within the DSN, and best practice is to store that configuration on an environment variable, not as code, so you wouldn't need "another code release with different transports config when a new host is added or removed". Simply add the appropriate environment variables when each instance is deployed, same as you do with the rest of the configuration.
framework:
messenger:
transports:
my_transport:
dsn: "%env(MESSENGER_TRANSPORT_DSN)%"
On each "www" host you would have a different value for MESSENGER_TRANSPORT_DSN, which would include a different queue name (or a completely different transport).
You would need to create a separate consumer for each instance, with a matching configuration (or run the consumer off the same instance).
But if all the hosts are actually running the same app, generally, you'd use a single consumer, and al the instances should publish to the same queue.
The consumer does not even need to run on the same server than any of the web instances, simply be configured to consume from the appropriate transport/queue.
How can I deploy and run Corda nodes of spring webserver based "Yo!CorDapp" example (https://github.com/joeldudleyr3/spring-observable-stream), on separate machines?
What are the configuration changes I need to implement in this regard.
As long as you are running each server on the same machine as the node it talks to, there shouldn't be any configuration required.
Simply start the nodes on their separate machines, then start the webserver on each machine, with the application properties modified or overridden to point to that node's RPC port.
Since the nodes are on separate machines, it's even possible to use the same RPC port for all nodes, since the IP address will differ.
So here is the question . I have an application running in weblogic 8 which is heavily dependent on JMS messages . The messages flow from a clustered MQ Server and the application which is in ejb 2 used to listen to directly in the MQ using configurations in the weblogic-ejb-jar.xml. The MQ server has two Queue Managers and two different Connection Factory name for those managers .
<weblogic-enterprise-bean>
<ejb-name>MDB_QM1</ejb-name>
<message-driven-descriptor>
<destination-jndi-name>QM1</destination-jndi-name>
<initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
<connection-factory-jndi-name>CF1</connection-factory-jndi-name>
</message-driven-descriptor>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>MDB_QM2</ejb-name>
<message-driven-descriptor>
<destination-jndi-name>QM2</destination-jndi-name>
<initial-context-factory>weblogic.jndi.WLInitialContextFactory</initial-context-factory>
<connection-factory-jndi-name>CF2</connection-factory-jndi-name>
</message-driven-descriptor>
</weblogic-enterprise-bean>
Now the application is to be migrated to weblogic 10.3 and the configurations has already been done in test for that .ejb version has changed to 3 and they have used annotations in the mdbs for queue config and such .But the real problem is this ,the application used to listen to the MQ directly and now they have configured a bridge which will transfer the message from MQ to a internal queue and the mdb will listen to that queue . The source MQ queue config in weblogic bridge config has only one connection factory in there and I am not sure if its possible to configure multiple queue managers , connection factories etc in a single queue . But in production there will be multiple queue managers etc .
I think its possible if I configure foreign servers for those queues then the clustering will be possible . But that will mean a huge change in the application and weblogic config also . So the ideal solution I am searching for is a way to connect to those multiple MQ queue managers with the existing bridge configuration. If its not possible , please suggest the next best thing . I am open to all ideas :)
Thanks
A WebSphere MQ cluster is all about how QMgrs talk to each other and does not hide from the application the fact that there are multiple physical instances of a queue. A separate connection is required to each queue manager instance. The app will need to either...
Use an instance of the bridge for each queue instance.
Configure the bridge to make multiple simultaneous connections to the different QMgrs.
Whoever made the decision to configure a bridge with a single connection factory did not consider the architecture of the underlying transport. You cannot overcome that poor decision with configuration, no matter how hard you try.
I am trying to get two mule projects to run at the same time that have similar paths, so that we can group our calls together (example http://domain.com/foo/service1 http://domain.com/foo/service2)
As a POC I have two projects, both that listen on localhost port 80.
project1 has a path of endpoint/v1
project2 has a path of endpoint/v2
Both deploy successfully to my mule server, but only project1's endpoint returns anything.
Any ideas on how to get this to work correctly?
That is because there is only one socket actually listening on that port (80).
If you want to have more than one path, you need to group the endpoints together in the same application, and this application can act as a proxy and call the ones with the actual logic.
Alternatively to Seba's proposal, a common pattern is to have one app in charge of exposing an HTTP endpoint then to dispatch messages to JMS queues that are listened to by the apps in charge of processing specific paths (say /v1 in one app and /v2 in another app).
case 1:
I'm having war in one jboss server and ejb jar in another jboss server.
I want to call my ejb from my servlet which is present in another server.
How to call it. can any one help me with a working sample and required configurations.
case 2:
Message Driven Bean(MDB) in my transaction jboss server and business method in another jboss server. How to call my business method from my transaction server.
kindly help me to solve this case
Thanks in advance
I can't (won't) help with a working example, but this is what you have to do:
Your EJBs (session beans) must be configured in a way to support remote access, RMI.
You have to export your EJB client classes into a separate JAR file; those are the interfaces and base classes required to perform an RMI call (stubs). This is required as clients (your WAR) must understand how to deserialize/serialize the RMI communication between your servlets and the remote EJBs.
Make the exported EJB client JAR available to your WAR file
Define an initial context pointing to your remote EJB server as described here.
Deploy and run it...
BTW: A personal opinion, RMI communication is painful and you should try to avoid it as it tightly couples the client (your WAR) to the remote EJBs.
EDIT: Which EJB version and which IDE do you use?