This content has been marked as final. Show 4 replies
You might be able to override the selector via a configured "deployment plan" for the ejb but deployment plans don't provide overrides for every possible field, and I'm not sure if selector is covered.
Alternatively, (depending on your specific use case and flexibility), if each scope is independent, you might consider setting up a uniquely named destination for each scope, and configuring a "Foreign JMS Destination" on each of DEV, EIT, etc, to map each separate scope's desired target destination to the same local destination name that's used by the MDB.
The deployment plan doesn't seem to provide the necessary configuration of the MDBs. Here's more detail of the situation (please let me know if I'm using the wrong terminology)
We have 2 WebLogic servers "connecting" to the same database which, among other things does the AQ stuff (configured as specified in other Oracle docs). So, server A initiates a report job by creating a DB record with the report job query parameters. (These jobs can be scheduled to start at a later time also). In order to start the report job AQ sends a message to the "job ready to process" queue. This message should only be processed by server A, which initiated the job. If I don't specify a message selector for each deployment to servers A & B, the message could be delivered to server B instead of A. In that case, what's the prefered method to get the message redelivered to server A.
I can check a message property for the server name & only do the work if it's the right one. How do I get it redelivered if it's the wrong server? Throw an exception in the onMessage() method?
All this messaging worked great when I only had my local deveopment server running. But it fails when I deploy to both the new integration test server and the new functional test server both of which use the same messaging database.
Please let me know if I can provide additional information about this.
The deployment plan doesn't seem to provide the necessary configuration of the MDBs. Here's more detail of the situation (please let me know if I'm using the wrong terminology)You may want to try checking with the EJB forum.
How do I get it redelivered if it's the wrong server? Throw an exception in the onMessage() method?I don't know AQ well enough to say for sure. With WL JMS, there's basically be a 50% chance that the message would go to the other server.
Please let me know if I can provide additional information about this.A couple of wild ideas - just off the cuff:
Use a dedicated stateless-session-bean per server to redirect calls.
Namely (A) move the "onMessage()" code into a stateless-session-bean "SSB" and deploy it to the cluster. (B) Deploy a simple EJBA to ServerA (not to the cluster), and an EJBB to ServerB (not to the cluster), where each of these simply calls the SSB. (C) If a message for ServerA arrives on the MDB, but it's meant for ServerB, have the MDB invoke EJBB.
To improve performance, cache the EJBB reference in the MDB somewhere so that you only need to look it up once.
I wonder if the EJB folks may have a way to pull of this type of directed routing more simply. If you want to follow through on this idea, you might try posting to the EJB forum to see if you can get any advice. I'd be interested in knowing if you find out something helpful...
(It also might be possible to do this more elegantly with an RMI that's registered dynamically as part of startup - so there it can be customized specifically to serverA or B as needed, but I assume this wouldn't be standard EE.)
Insert a WL Distributed Q into the flow.
If you already have WebLogic JMS in the mix, this may be helpful:
Configure a WL JMS Server per server, and configure a "Uniform Distributed Queue" UDQ that spans these servers.
Deploy your current MDB so it uses this UDQ as a source destination. By default the MDB will only consume from the local JMS Server's UDQ member.
Write a new MDB that consumes from AQ and forwards messages. If a message arrives that doesn't belong on the current server, lookup the UDQ member that's on the desired server using the following JNDI syntax "jms-server-name@udq-jndi-name", and send the message directly to this location.
(Cache the Destination and Connection Factory reference for performance reasons - just as you should when producing to AQ...)
I have another idea which seems simpler - use a topic rather than a queue. That way the message gets sent to everyone and only the "target" server will do as instructed. As long as the message is the same, it seems like the delivery mechanism shouldn't matter.