Modifying Message Bridge at Runtime

Question

I'm trying to modify a message bridge at runtime. The message bridge is
          between two local Queues.
          What I'm trying to do is basically create an alias that points to one of
          many queues.
          For example, I want my workflow to always look up the queue with JNDI
          name A, but at runtime I want messages sent to A to really go to one of
          B,C,D. So, I create a message bridge from A to B, then want to change at
          runtime from A to C or A to D.
          Now, the message bridge works for the configuration that is setup when
          the server starts, but at runtime, changing the message bridge
          configuration via the admin console does not work. The messages are not
          forwarded after I do this. If I stop and start the server, the messages
          are forwarded to the new destination correctly.
          This is a very critical component of our evaluation of the product, and
          is a must for us to use it in our system. We need the most runtime
          configuration/parameterization as possible since we will be in a 24/7
          environment.
          How can I get this to work? Is this a bug, or was runtime configuration
          never intended for such a change?
          Thanks
          

Answer 1

Hi Steven,
          This use for the bridge was not anticipated.
          The bridge's destination fields are marked "non-dynamic"
          on the console and in the mbean javadoc, but perhaps it
          is still possible to make the bridge do what you require.
          Did you try stopping and restarting just the bridge, rather
          than rebooting the whole server? If that doesn't work (and
          I'm told it likely won't), you can
          try undeploying and redeploying the bridge (set the target
          of the bridge to nothing, then set it back to its intended
          host server.) Both of these methods can be done fully
          programmatically via JMX mbeans. I think they can
          even be scripted via weblogic.Admin (but I'm not sure how.)
          Tom, BEA
          P.S. Instead of the bridge, you could write your own
          forwarding mechanism - which would give you full flexibility.
          There is example forwarding code in appendices for
          the JMS Performance Guide whitepaper on dev2dev:
          http://dev-test.bea.com:90/products/wlserver/whitepapers/WL_JMS_Perform_GD.jsp
          P.P.S. Instead of one bridge, you could have multiple: one
          per remote destination. Then, if you need to change
          the remote destination, undeploy the current bridge
          and deploy the desired bridge. This can be
          done via the console or programmatically.
          P.P.P.S. If this issue is really a "deal-breaker", I suggest
          making sure that your BEA sales-person knows this, so that
          they have the opportunity to make suggestions.
          Steven Ostrowski wrote:
          > I'm trying to modify a message bridge at runtime. The message bridge is
          > between two local Queues.
          >
          > What I'm trying to do is basically create an alias that points to one of
          > many queues.
          >
          > For example, I want my workflow to always look up the queue with JNDI
          > name A, but at runtime I want messages sent to A to really go to one of
          > B,C,D. So, I create a message bridge from A to B, then want to change at
          > runtime from A to C or A to D.
          >
          > Now, the message bridge works for the configuration that is setup when
          > the server starts, but at runtime, changing the message bridge
          > configuration via the admin console does not work. The messages are not
          > forwarded after I do this. If I stop and start the server, the messages
          > are forwarded to the new destination correctly.
          >
          > This is a very critical component of our evaluation of the product, and
          > is a must for us to use it in our system. We need the most runtime
          > configuration/parameterization as possible since we will be in a 24/7
          > environment.
          >
          > How can I get this to work? Is this a bug, or was runtime configuration
          > never intended for such a change?
          >
          > Thanks
          >