Custom Consumers vs. MDBs

What are some of the benefits to use J2EE�s message driven beans as suppose to writing your own threading and Message Consumers? Can someone really touch on the issues and problems one can expect when not using a J2EE container service for threading and message consumption?
Thx!

Suzanne,
It is really up to you. The real advantage of using Dynamic Pages over custom PL/SQL / JavaScript is that they DP is more manageable. Once you PL/SQL gets over a certain size, you can no longer update via portal. Also, with the DP, you can update and view easily.
Other than that, it is really a personal preference
Sue

Similar Messages

Custom authorization for MDB in WLS 7.0

Hi,
Does anyone know how to authorize MDB using a Custom Authorization
Provider while the Weblogic Container registers the MDB as a listener
to JMS queue? My Custom Authorization Provider uses an oracle database
to store user roles and access control lists to allow a certain role
to access specific weblogic resources.
Any assistance is highly appreciated.
Thanks
Siva

The main reason is that JMS topics do not work well with HTTP clients. A topic cannot
initiate an HTTP call to the subscriber, so we have to store the message in memory
outside of JMS waiting for the subscriber to call us. Reliability is lost (if anyone
cared). The lifecycle of the outbound message is controled by the HTTP session timeout
(yuck!). This did not look like a solid feature that we should support.
If you like it, you can implement it yourself. I would recommend using JAX-RPC
handlers for that.
Thanks,
-ruslan
Michael Poulin wrote:
The deprication note is in "Creating JMS-Implemented WebLogic Web Services, section
Overview of JMS ...

JMS consumers and MDBs in free pool

          Hello
          I am using WLS 7.0 SP1. I notice the following when using MDBs listening on
          a JMS queue.
          The WLS console shows the number of JMS consumers to be equal to the <max-free-beans-in-pool>
          parameter value in the MDBs deployment descriptor. I would expect the number of
          JMS consumers to be equal to the <initial-free-beans-in-pool> value before I start
          posting messages to the queue.
          Thanks
          Ramdas


Hi Ramdas,
          I'm fairly sure that this is long-standing behavior, that
          also occurs in 6.1 and 8.1. Since the number of beans
          is limited by the number of available threads, the fact
          that all of them are allocated right away is usually not
          an issue.
          Post to the ejb newsgroup to make sure.
          Tom
          P.S. If you haven't already, I suggest reading
          the most recent version of the JMS performance guide. It
          contains info on tuning MDB threading and pooling. You
          can find the guide on dev2dev.
          Ramdas Hegde wrote:
          > Hello
          >
          > I am using WLS 7.0 SP1. I notice the following when using MDBs listening on
          > a JMS queue.
          > The WLS console shows the number of JMS consumers to be equal to the <max-free-beans-in-pool>
          > parameter value in the MDBs deployment descriptor. I would expect the number of
          > JMS consumers to be equal to the <initial-free-beans-in-pool> value before I start
          > posting messages to the queue.
          >
          > Thanks
          >
          > Ramdas

Messages from topic to multiple consumers are not ordered the same way

Hi,
We have a distributed topic. The message producer is a multi-threaded/connection producer (OSB in our case).
On the other side of the DT there are single connection consumers.
Our problem is that the consumers sometimes recieve the messages in different order:
Consumer A recieves message N and then N+1 (correct behaviour).
Consumer B recieves message N+1 and then N (correct behaviour).
This does not happen all the time. Most of the time the order is correct (99.9..%).
We also noticed that the message timestamp for message N and N+1 is the same.
This creates a problem for our system since both consumers must get the messages in the same order.
We cannot use UOO.
Any idea if this is a correct behavior for DT?
Any idea how to make the messages get to all consumers in the same order without using UOO?
Thanks,

Hi,
Hmm. You may have run into some new Bug given since "message timestamp for message N and N+1 is the same". First, let's dot our I's and cross our Ts to make sure that the system is setup in a way that will give you good ordering in the first place:
- Always use the same producer instance for each sequential send, and ensure that the producer's connection factory has "load balance" set to false. Note that OSB may be using a pool of producers implicitly for your sending app underneath-the-covers, which could lead to out-of-order, as different producers can load balance to different servers in your cluster. (I'm not sure how to check for this - if you provide a code snippet, I may be able to tell if this is happening.)
- Ensure that you only ever have a single thread processing the subscription - if you're using MDBs to receive from the subscription, then you need to ensure the MDB is setup to only startup a single thread (use a thread pool of size and/or set max-beans-in-free-pool to one)
- To account for out-of-order after app message processing failures (redelivery) with async consumers or MDBs, you need to (A) never configure redelivery delays, and (B) ensure the connection factory Maximum Messages setting is tuned down to 1 (it's default is 10).
I don't know how to do the above with OSB, which tends to layer it's own configuration on top of WL JMS configuration.
Assuming that you've assured all of the above, then you may have run into some sort of bug and I recommend filing a request with Oracle Support. In the mean-time, you might want to explore alternatives:
- Are you certain that you can't use UOO? It would be interesting to know why. This is a widely used feature (even by OSB itself), and it may be that you can enable it without any code change, plus, even if a code change is required, such changes tend to be isolated and small. In your use case, it looks like you may be able to configure a default UOO on the distributed topic itself (http://docs.oracle.com/cd/E11035_01/wls100/wlsmbeanref/core/index.html) - no code change needed - so that every destination member of your distributed destination will simply ensure that each new message is given the same UOO (a UOO that's particular to that member). OSB may provide some equivalent knob. Alternatively, you can code up your app so that each of your producers sets a useful UOO on each message.
- I assume you're using a replicated distributed topic (RDT). If there actually is a bug, then it would likely have something to do with the RDT's internal forwarders. If your consumers are MDBs or the SOA RA Adapter, then a simple alternative may be to use a Partitioned Distributed Topic (PDT) instead -- PDTs have no forwarders, and the MDB and the SOA RA Adapter can work with them transparently. If your consumers are neither of these, then working with a PDT will likely require that you use extensions (an advanced path that you may not want to take the time to follow).
Tom

Not able to Call JDBC control from MDB

I need to call a method in the JDBC control from the Message Driven Bean(MDB). When I try to do so, Weblogic throws an error. I tried to call a Custom Control from MDB and the Custom Control called a method in the JDBC control but that does not work too. Can someone help me solve this?
Can't we call the JDBC control from MDB? There should be some way around this.
This is the error I get :
org.apache.beehive.controls.api.ControlException: Control initialization failure[org.apache.beehive.controls.api.ControlException: Contextual service org.apache.beehive.controls.api.context.ResourceContext is not available]
     at org.apache.beehive.controls.runtime.bean.ControlBean.ensureControl(ControlBean.java:326)
     at com.boehringer.supplier.control.db.ForecastJDBCControlBean.updateSpendWithCMId(ForecastJDBCControlBean.java:2879)
     at com.boehringer.supplier.control.java.SupplierControlImpl.processCustomer(SupplierControlImpl.java:1290)
     at com.boehringer.supplier.control.java.SupplierControlImpl.processSonicInboundMessage(SupplierControlImpl.java:1096)
     at com.boehringer.supplier.control.java.SupplierControlBean.processSonicInboundMessage(SupplierControlBean.java:663)
     at com.boehringer.sonic.SonicVendorInboundMDB.onMessage(SonicVendorInboundMDB.java:45)
     at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:466)
     at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
     at weblogic.ejb.container.internal.ContinuousJMSMessagePoller.processOneMessage(ContinuousJMSMessagePoller.java:138)
     at weblogic.ejb.container.internal.JMSMessagePoller.pollContinuously(JMSMessagePoller.java:404)
     at weblogic.ejb.container.internal.ContinuousJMSMessagePoller.pollForParent(ContinuousJMSMessagePoller.java:213)
     at weblogic.ejb.container.internal.JMSMessagePoller.run(JMSMessagePoller.java:543)
     at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.beehive.controls.api.ControlException: Contextual service org.apache.beehive.controls.api.context.ResourceContext is not available
     at org.apache.beehive.controls.system.jdbc.JdbcControlImplInitializer.initServices(JdbcControlImplInitializer.java:50)
     at org.apache.beehive.controls.runtime.bean.ImplInitializer.initialize(ImplInitializer.java:34)
     at org.apache.beehive.controls.runtime.bean.ControlBean.ensureControl(ControlBean.java:321)
     ... 12 more

Hi,
I am getting the same error. Did you got any solution for this?
Please help.
Any kind of help is appreciated.
Thanks,
Dpak

Design Pattern for execution queue

Anyone know of any good design patterns for using a JMS Queue and MDB's
          as async
          execution queue which maintains execution order by some key


Enforced ordering on redelivery will be supported in the
          next release, but only if the application clamps the pipe-line
          size down to its minimum and the MDB pool size down to one.
          I don't think enforced ordering is supported in the current release.
          We are looking at least partially addressing the general design
          pattern below in the release after next. I don't think I can
          get away with being more specific. (Sorry.) Currently, I
          think something along the line of Larry's solution is the only way to
          accomplish it. Interestingly, the recent thread started
          by "[email protected]" on correlating requests and responses
          seems to be somewhat related.
          Tom, BEA
          Larry Presswood wrote:
          > Well you are both correct however we have something which works
          > however it does involve some threading primitives which generally is not
          > a good idea
          > inside wlas but seems to work.
          >
          >
          > Generally have a singleton on the server which has slots for each key
          > with message
          > numbering for each message and force a wait if message for key is out of
          > order
          > during fifo processing rules. IE do what things you can do in parallel
          > but gate for
          > the last step.
          >
          > I think there is a general remote execution pattern out there.
          >
          > The general problem to solve is this:
          >
          > In a messaging system you want to process messages for each key/session
          > in order however
          > with a large number of sessions its possible to parallel messages for
          > different sessions
          >
          > Otherewise you can either create custom queues or a topic with a
          > selector and then
          > create custom consumers which does not behave as well from a resource
          > perspective
          > as MDB's do.
          >
          >
          >
          >
          >
          >
          >
          > Nick Minutello wrote:
          >
          >>I may be completely wrong - but I think that Larry is referring to the inherant
          >>out-of-order message consumption that you get when using MDB pools to consume
          >>from a Queue.
          >>
          >>In short, the only design pattern here is to deploy the MDB to only one machine
          >>in the cluster - and set the pool size to 1.
          >>
          >>In-order execution is incompatible with the parallel execution that MDB's give
          >>you.
          >>
          >>-Nick
          >>
          >>
          >>
          >>Tom Barnes <[email protected]> wrote:
          >>
          >>
          >>>Hi Larry,
          >>>
          >>>Generally, I think it is best to have a seperate queue per key if the
          >>>
          >>>number of keys is small. This prevents starvation of a particular
          >>>message. For example when handling message-priority, low priority gets
          >>>
          >>>an MDB pool of size 1, high priority gets and MDB pool of size 10.
          >>>
          >>>Note that WebLogic JMS allows a queue to specify a sort-order keys based
          >>>on arbitrary message fields. Note that the in-flight message pipe-line
          >>>
          >>>between server and asynchronous clients is unsorted.
          >>>
          >>>Tom, BEA
          >>>
          >>>Larry Presswood wrote:
          >>>
          >>>
          >>>>Anyone know of any good design patterns for using a JMS Queue and MDB's
          >>>>
          >>>>
          >>>>as async
          >>>>execution queue which maintains execution order by some key
          >>>>
          >>>>
          >>>>
          >>
          >>
          >>
          >

Crystal 8.5! Set table locations at run time to queries

Hopefully some people still remember version 8.5...
I have a number of reports which all work from a single database, this can be either Access or SQL Server, I'm currently testing on Access. I would like to use the same reports but print them for multiple databases, all of which have the same schema. To do this I'm creating UNION queries in one of the databases and I now want to change the location of the tables in the report to use these union queries instead.
For example, say the report uses table "Customer" in db1 but I have also have db2 and db3 with the same table, I'm enumerating all fields used in the report and creating a union in db1 something like:
SELECT field1, field2 FROM Customer IN 'db1.mdb'
UNION SELECT field1, field2 FROM Customer IN 'db2.mdb'
UNION SELECT field1, field2 FROM Customer IN 'db3.mdb'
Now I've tested this in Crystal Reports itself, i.e. setting the location to the new tables, and it works OK. I'm having to use an OLEDB connection otherwise the links get removed. When I try to set the location in code I just get no data on the report even though there is data available.
In code I'm going through all tables (and all tables in all sub reports) and I've tried setting the Location property to the name of the union, I've tried SetTableLocation "<path to db>", "<union name>" and I've tried both using SetLogOnInfo "<path to db>" as well.
I'm thinking perhaps converting the report to active data and plugging in an ADO recordset could be a solution but I'm not sure how feasible that is from code (i.e. converting the database driver from either pdsoledb.dll or pdbdao.dll to pdsmon.dll and creating a ttx on the fly...).
Any help much appreciated.

Hi,
SetTableLocation should work but you need to make sure you call it for each of the tables in the report or in this case the Union.
Just like in the report designer when you set the location you need to point to the table you want to change. Even though you get the prompt asking to set the same location for all the tables, it's doing the same thing for you.
Hope this helps,
Brian

Weblogic JMS single vs multiple Queues

I am building an application which acts as an event listener and based on the events received it needs to execute certain steps or work-flow. Is it better to have events posted to a single queue and MDB invoking different business logic components based on event type or to have one queue per event type and the corresponding MDBs invoke different business logic ? Our assumption is that a heavy workflow corresponding to a particular event will not starve the performance of other light weight events since they are processed in separate queues.
Your suggestions please.

Will I get an increased throughput by having heavy weight events processed in different queue instead of having one >queue / MDB for the complete set ?In general it is a good idea to have separate set of the Queue/MDB to support completely different business logic and different message types so you can tune destination and MDB pool size as per it's own concurrent processing requirements. With it's own set of Queue/MDB per business logic it will definitely help to achieve better parallel processing. Throughput also depends transaction boundaries at MDB side. For a given queue, JMS server will not deliver next message until current message is processed successfully and received acknowledgment.
If threads get stuck with the heavy weight event processing, is it still going to affect the events processed at other queues ?In general consumers(including MDB) for each destinations execute in separate thread in parallel. So stuck thread with one kind of consumer does not impact consumers on different destination, however if problem persist and high number of messages results in high number of stuck threads it will definitely starve WebLogic thread resources and cause negative impact on WebLogic system itself. One way to limit damage of the stuck thread is by limiting pool size of the individual MDB.
Hope this will help.
jayesh@yagnasys

MQ 5.3 and WLS 8.1

          I want to use MQ 5.3 from WLS 8.1 MDBs. Seems like I can
          a) configure MQ as a foreign jms service, or
          b) use a JMS bridge.
          Is there a difference? From the documentation it seems as though the bridge offers
          superior transactional semantics. If I use a bridge do I configure MQ to register
          objects in some other local file or LDAP JNDI repository, then bridge from that
          JNDI to WLS JNDI?
          I'm confused about this whole thing, so I apologize if my question doesn't make
          sense. Does anyone have an explicit example they can share?
          Thanks,
          Jay


Hi Jay,
          - Unless your intent is to allow MDBs to continue
          processing backlogged messages while MQ is
          off-line, there is usually little reason
          to use a bridge. A bridge
          introduces an extra hop which increases latency and
          may decrease performance.
          - I assume you will also want to send from WL
          to MQ. If so, look into the new 8.1 resource
          reference wrapper feature as it helps simplify
          this task. You may want to bridge from
          a local dest to MQ instead,
          for the same reasons as one would bridge in
          the inbound direction - to allow message
          processing to continue even if MQ is down...
          - If you use the bridge there is no need to
          configure foreign destination or connection
          factory "wrappers", as you can specify
          the MQ URL, CF name, and dest name directly in
          the bridge configuration. Ditto for MDB
          descriptors. But foreign wrappers are nice for
          MDBs as then the MQ URL, CF name,
          and dest name no longer need to be hard-coded
          into the MDB and instead reside in the config.xml...
          - I'm attaching some notes I have on
          integration which contains some additional information.
          Tom
          jay philoon wrote:
          > I want to use MQ 5.3 from WLS 8.1 MDBs. Seems like I can
          > a) configure MQ as a foreign jms service, or
          > b) use a JMS bridge.
          >
          > Is there a difference? From the documentation it seems as though the bridge offers
          > superior transactional semantics. If I use a bridge do I configure MQ to register
          > objects in some other local file or LDAP JNDI repository, then bridge from that
          > JNDI to WLS JNDI?
          >
          > I'm confused about this whole thing, so I apologize if my question doesn't make
          > sense. Does anyone have an explicit example they can share?
          >
          > Thanks,
          > Jay
          Transactional Integration of Foreign JMS Vendors with BEA WebLogic Server
          The following notes are derived mostly from "http://dev2dev.bea.com/technologies/jms/index.jsp".
          For additional questions, a good forum for WebLogic questions in general is "newsgroups.bea.com". These can be mined for information by using Google's newsgroup search function.
          Feature Overview
          - For a foreign JMS vendor to participate in a WL transaction it must support XA. Specifically, it must support the javax.jms.XA* interfaces.
          - In WL versions 6.0 and up it is possible to make synchronous calls to foreign JMS vendors participate in a WL transaction as long as the foreign vendor supports XA.
          - WL 6.0 and 6.1 MDBs can be driven by foreign vendors non-transactionally. They can be driven transactionally by a select few foreign vendors (MQ is not part of the select few)
          - WL 7.0 and later, MDBs can be driven by foreign vendors transactionally and non-transationally.
          - WL 6.1 and later WL provides a messaging bridge feature. Messaging bridges forward messages between any two JMS destinations, including foreign destinations, and can transfer messages transactionally or non-transactionally.
          - WL 8.1 JMS provides additional features that simplify transactional and JNDI integration of foreign vendors. See http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          Integration with 8.1 Details
          A good overview of 8.1 JMS interop capability is the presentation "Integrating Foreign JMS Providers with BEA WebLogic Server" here:
          http://www.bea.com/content/files/eworld/presentations/Wed_03_05_03/Application_Servers/1097-Foreign_JMS_Providers_WLS.pdf
          This document refers to helpful new 8.1 features, which simplify integration. These include:
          http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
          http://edocs.bea.com/wls/docs81/jms/j2ee_components.html#1033768
          And are also summarized here (under interoperability):
          http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          The 8.1 features are likely sufficient for most 8.1 integration needs, and you may not need to refer "Using Foreign JMS Providers With WLS" white-paper mentioned below.
          Integration with 6.1 and 7.0 Details
          Read the "Using Foreign JMS Providers With WLS" white-paper:
          http://dev2dev.bea.com/products/wlserver/whitepapers/jmsproviders.jsp
          Note that this white-paper does not take into account 8.1 features.
          MQ Remote Capable XA Clients
          Until recently, IBM MQ JMS clients could not work transactionally unless they were running on the same host as their MQ server. This is a limitation unique to MQ that was relaxed with the introduction of IBM's new "WebSphere MQ Extended Transactional Client". See:
          http://publibfp.boulder.ibm.com/epubs/pdf/csqzar00.pdf
          The product is new, and for some reason, configuration of this client seems to be tricky, even when WebLogic is not involved at all. Oddly, the main sticking point seems to be simply making sure that class paths refer to the required IBM jars:
          - Required on WLS where MQ objects are bound into JNDI:
          com.ibm.mq.jar, com.ibm.mqjms.jar
          - Required only if MQ objects are bound into JNDI on a different server:
          com.ibm.mq.jar
          If there are problems when using this client, first get it to work using a pure IBM client without any BEA classes involved. Once that is working, search the WL JMS newsgroup for answers and/or contact BEA customer support.
          MDB Thread Pool Notes
          WL7.0SP? and WL8.1 and later support the "dispatch-policy" field to specify which thread pool an MDB uses to run its instances. In most cases this field should be configured to help address potential performance issues and/or dead-locks:
          http://edocs.bea.com/wls/docs81/ejb/DDreference-ejb-jar.html#dispatch-policy
          (Note that "dispatch-policy" is ignored for non-transactional foreign vendors; in this case, the MDB "onMessage" callback runs in the foreign vendor's thread.)
          MDB Concurrency Notes
          Queue MDBs driven by foreign providers can run multiple instances concurrently. Topic MDBs driven by foreign providers are limited to one instance (not sure, but transactional foreign driven topic MDBs may not have this limitation). The size of the thread pool that the MDB runs in and the "max-beans-in-free-pool" descriptor limit how many instances run concurrently.
          Performance Tuning Notes
          The "WebLogic JMS Performance Guide" white-paper contains detailed performance design and tuning information for the Messaging Bridge, JMS, and MDBs.
          http://dev2dev.bea.com/products/wlserver/whitepapers/WL_JMS_Perform_GD.jsp

Materialized view long transaction time

I am using Oracle DB 11g R2 and created a materialized view log WITH SEQUENCE. I need to find out the exact date/time the transaction was made. I see that my MV log has the 'XID$$' column (NUMBER 22), but not sure how to determine the date/time from that. Is there another view/table I can join to get me that info? I see some have 'XID' column but they are RAW(8).
Thanks
Edited by: bobmagan on Feb 27, 2013 11:57 AM

- CDC is at least as performant as materialized view logs. If you do asynchronous CDC, it performs better since you're not burdening the source transactions with the overhead of synchronously maintaining the materialized view logs.
- CDC is at least as effective as materialized view logs. Since CDC is designed to publish changes to custom consumers where materialized view logs are designed to be used by Oracle to refresh a materialized view, it strikes me as a much safer solution. If someone comes along and creates a materialized view that starts using your materialized view log, for example, a solution that involves custom code to manipulate the materialized view is almost certainly going to fail.
- CDC isn't an extra cost option so there shouldn't be a cost difference
That leaves the question of simplicity. I'll certainly grant you that a materialized view log solution may appear simpler. But a lot of that simplicity advantage disappears over time. The fact that we're talking about doing things like querying relatively obscure data dictionary tables like all_summap, for example, is added complexity that a CDC-based solution doesn't need. But over time, I'd much rather maintain a CDC-based solution rather than hooking in to materialized view logs. If someone wants to build a materialized view and Oracle happens to be able to use the materialized view log you've created for your own CDC, the custom solution will stop working. Over time, Oracle introduces more and more functionality that allows the ROWID of a row to change (shrinking a table, flashback, etc.). If you're using CDC, Oracle will take care of making sure that all those things are presented to you correctly. If you're rolling your own solution, you have to test and ensure that your code handles all those cases correctly. When Oracle makes a change in some future release that you hadn't considered, you've got to notice the potential problem, code the fix, and test it. Most places are probably going to miss something and only discover that there is a problem when they do something like shrink a table and then find that their custom solution doesn't handle that gracefully.
Justin

Setting up re-delivery attempts in Foreign JMS Configuration !!!

Hi All
Could anyone please let know if it's possible to set number of re-delivery attempts for a JMS message in case of foreign JMS server configuration.
I am using weblogic 8.1 SP6. If it is possible, the please let me know how to set it up.
Thanks in advance.

Redelivery limits in WebLogic are implemented within WebLogic JMS - not in the MDB container.
If the foreign destination happens to be WebLogic JMS, then you can set a redelivery limit by configuring it on the MDB's source destination.
If the foreign destination is not WebLogic JMS, then I can think of three options:
-- Check with the foreign vendor to see if they have a redelivery limit feature.
-- Consider changing the producer application to set expiration times on the messages (whether this is a useful approach for you depends on your application).
-- Custom code your MDB application to take a different action once it detects a high redelivery count, or perhaps even code a separate application that only dequeues messages that have a high delivery count. Some JMS vendors (such as WebLogic JMS 9.0 and later), include a "JMSXDeliveryCount" property in each message that simplifies such coding.
Hope this helps!
Tom Barnes
WebLogic JMS Developer Team

JMS Monitoring -- "Message Current" value is not going down

Hi All,
We are using Weblogic 10.0 MP1. We have four servers in a cluster of which, two are in 'SHUTDOWN' state.
We are running a load test, keeping two managed servers up out of 4, in which we put lots of messages on a topic.The consumers are MDB's.
While running the load test, we can see lot of messages getting generated(by monitoring the "Messages Received" column) but at the end of test we still see thousands of message in the "Message Current" category(total message or Messages Received are 5 times the message in Message Current category ).We can still see messages in the current category after couple of hours.It seems messages are getting stuck.
Does the message(s) which remain in "Message Current" category means, they CANNOT be processed or they were processed earlier but failed.So they are in a infinite sort of loop 'cause of which keep on re-trying?
Is my assumption correct that: messages in the "Message Current" category should scale down to zero after the load test(may not be immediately-for lack of processing power, but in a short duration)?
I even increased my MDB count but it seems that processing of messages increased but the "Message Current" counter never came down.
Any pointer/help is greatly appreciated?
thanks

Please check following things in your envrionment.
a. Is your Multicast messaging working fine. There is a utility called MulticastMonitor that you can execute. Please see if all the servers in the cluster gets listed when you run this test. Syntax is located at: http://e-docs.bea.com/wls/docs92/cluster/multicast_configuration.html.
b. Also check if you have configured Multicasting in your code when you post messages to the topic on weblogic server.
If multicast messaging is broken, you need to fix the issue.

SONIC Queues

Generally when we are working with JMS Queues, We write
Java code for JMS Producers and JMS Consumers or MDB s which
will capture the responses from JMS Queues when we send
Asynchrous messages as requets to JMS Queues.
Then what exactly are these SONIC Queues. Are they any
PLugins? When do we use them? Will they work with
WebLogic or WebSphere Application server?
Do we need to Use SONIC / TIBCO Queues inorder to send
messages thru JMS Queues.
Can any one of you clarify my doubts?
Thanks

JMS is the specification, so you must use its implementations to get the functionality of the JMS. i recom. u to use OpenJMS. either create ur own queue in OpenJMS or used already defined queues in it. the following code may help u .
system overview..
I have two classes namely
MessageSender and MessageReceiver
I had tested both class by passing the bean to the queue, and then calling the listeners onMessage method and cast it to acual object and pass it to dao object to save it to the database.
if (message instanceof ObjectMessage)
try
ObjectMessage m = (ObjectMessage) message;
MessagePacket packet = (MessagePacket) m.getObject() ;
MessageBean mainMessage = packet.getMessage();
PostDetails postDetails = packet.getPostDetails();
I tested it by writing a test class as follows:
public static void main (String [] args){
MessageBean messageObject = new MessageBean();
PostDetails postDetails = new PostDetails();
//setting the attributes..
MessagePacket packet = new MessagePacket();
packet.setMessage(messageObject);
packet.setPostDetails(postDetails);
MessageSender sender = new MessageSender();
sender.setUpQueue();
sender.sendMessage(messageObject);
System.out.println("Message send");
MessageReceiver receiver = new MessageReceiver();
receiver.setUpQueue();
receiver.receiveMessage();
// System.out.println("Message received " + hold );
All the above code works perfectly fine
s khan

JMS Server on a cluster stores all msgs posted to Distributed Queue on 1 server failure

          Hi
          I have a Cluster setup with 2 managed servers srvr1 & srvr2 each running its own
          JMS server.
          Product version in use is Weblogic SP2.
          Configured a Distributed Queue and deployed it on both the JMS servers.
          Set the load-balancing to round-Robin and Server-Affinity to False on the connection
          factory.
          The producer is an external client which posts 100 messages to the Distributed
          queue.
          Consumers are MDBs pinned to the respective physical queues on the respective
          JMS servers.
          Each server has its own store.
          Once 100 messages are posted to the Distributed Queue. The messages are distributed
          to
          the 2 Physical Destinations equally i.e 50-50 each.
          While the MDBs are processing the msgs, server srvr1 is brought down at a point
          when it has consumed only 10 of its 50 msgs.
          When the srvr1 is brought up again, i am finding that the store for that JMS server
          contains the 40 unprocessed msgs in its physical queue + the msgs on the other
          queue that were unprocessed at the time this server crashed.
          When srvr1 went down, srvr2 was running and it went on to process all its 50 msgs
          completly. Why would those processed msgs show up again when srvr1 is brought
          up ?
          Please provide some input !!
          Ravi.


          The log message is from the distributed destination
          "forwarders". In distributed queues, these forwarders
          automatically move messages from queues without
          consumers to queues that have them (queue
          forwarders are disabled by default). In distributed topics,
          the forwarders serve
          to replicate a published message from the local
          topic member to each of the remote topic members.
          "Raviprasad Athivilli" <[email protected]> wrote:
          >
          >Tom
          >
          >I think you are right. When the server1 is brought up again, its picking
          >up all
          >the messages
          >that were written to the store.
          >
          >But as it starts processing them, i get this exception on the server2
          >that has
          >been running from the beginning.
          >
          ><Oct 10, 2003 6:20:19 PM EDT> <Error> <JMS> <040366> <JMS Distributed
          >Destination
          >member "MyQueue@JMSServer-02" in "MyQueue"
          >unable to accept connection from remote member "MyQueue@JMSServer-01"
          >due to exception
          >weblogic.jms.common.JMSException: can't find
          >queue target jndi table for MyQueue@JMSServer-01 != MyQueue
          >weblogic.jms.common.JMSException: can't find queue target jndi table
          >for MyQueue@JMSServer-01
          >!= MyQueue
          > at weblogic.jms.backend.BEDestination.setupSystemSubscription(BEDestination.java:3466)
          > at weblogic.jms.backend.BEManager.sessionAndTopicSubscriberCreate(BEManager.java:234)
          > at weblogic.jms.backend.BEManager.invoke(BEManager.java:384)
          > at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:602)
          > at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync(DispatcherImpl.java:152)
          > at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsyncFuture(DispatcherImpl.java:396)
          > at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown
          >Source)
          > at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
          > at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
          > at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821)
          > at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308)
          > at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
          > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
          > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)
          >
          >What does this mean ?
          >
          >Ravi.
          >Tom Barnes <[email protected]> wrote:
          >>Seems more than odd. Are you sure that q1 got unprocessed
          >>messages from q2? How did you confirm?
          >>
          >>Perhaps q1 got messages its MDB already processed back again -
          >>an indication that the MDB is throwing Runtime exceptions
          >>or Errors, and the container is rolling back transactions.
          >>
          >>Raviprasad Athivilli wrote:
          >>> Hi
          >>>
          >>> I have a Cluster setup with 2 managed servers srvr1 & srvr2 each running
          >>its own
          >>> JMS server.
          >>> Product version in use is Weblogic SP2.
          >>> Configured a Distributed Queue and deployed it on both the JMS servers.
          >>> Set the load-balancing to round-Robin and Server-Affinity to False
          >>on the connection
          >>> factory.
          >>>
          >>> The producer is an external client which posts 100 messages to the
          >>Distributed
          >>> queue.
          >>> Consumers are MDBs pinned to the respective physical queues on the
          >>respective
          >>> JMS servers.
          >>> Each server has its own store.
          >>>
          >>> Once 100 messages are posted to the Distributed Queue. The messages
          >>are distributed
          >>> to
          >>> the 2 Physical Destinations equally i.e 50-50 each.
          >>>
          >>> While the MDBs are processing the msgs, server srvr1 is brought down
          >>at a point
          >>> when it has consumed only 10 of its 50 msgs.
          >>>
          >>> When the srvr1 is brought up again, i am finding that the store for
          >>that JMS server
          >>> contains the 40 unprocessed msgs in its physical queue + the msgs
          >on
          >>the other
          >>> queue that were unprocessed at the time this server crashed.
          >>>
          >>> When srvr1 went down, srvr2 was running and it went on to process
          >all
          >>its 50 msgs
          >>> completly. Why would those processed msgs show up again when srvr1
          >>is brought
          >>> up ?
          >>>
          >>> Please provide some input !!
          >>>
          >>> Ravi.
          >>
          >

C or C++ JMS Client

          Hi,
          Is there any way to have a C++ or a C program running as a JMS client?
          Thanks in advance,
          Goutam.


Hi,
          See attached FAQ for C JMS client and other
          C integration approaches.
          Tom
          Goutam Mukherjee wrote:
          > Hi,
          >
          > Is there any way to have a C++ or a C program running as a JMS client?
          >
          > Thanks in advance,
          > Goutam.
          JMS Integration of Foreign Vendors with BEA WebLogic Server
          The following notes are derived mostly from "http://dev2dev.bea.com/technologies/jms/index.jsp".
          For additional questions, a good forum for WebLogic questions in general is "newsgroups.bea.com". These can be mined for information by using Google's newsgroup search function.
          JMS Integration Overview
          - For integration with "non-Java" and/or "non-JMS" platforms, see "Non-Java Integration Options" below.
          - For a foreign JMS vendor to participate in a WL transaction it must support XA. Specifically, it must support the javax.jms.XA* interfaces.
          - In WL versions 6.0 and up it is possible to make synchronous calls to foreign JMS vendors participate in a WL transaction as long as the foreign vendor supports XA.
          - WL 6.0 and 6.1 MDBs can be driven by foreign vendors non-transactionally. They can be driven transactionally by a select few foreign vendors (MQ is not part of the select few)
          - WL 7.0 and later, MDBs can be driven by foreign vendors transactionally and non-transationally.
          - WL 6.1 and later WL provides a messaging bridge feature. Messaging bridges forward messages between any two JMS destinations, including foreign destinations, and can transfer messages transactionally or non-transactionally.
          - WL 8.1 JMS provides additional features that simplify transactional and JNDI integration of foreign vendors. See http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          Integration with 8.1 Details
          A good overview of 8.1 JMS interop capability is the presentation "Integrating Foreign JMS Providers with BEA WebLogic Server" here:
          http://www.bea.com/content/files/eworld/presentations/Wed_03_05_03/Application_Servers/1097-Foreign_JMS_Providers_WLS.pdf
          This document refers to helpful new 8.1 features, which simplify integration. These include:
          http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
          http://edocs.bea.com/wls/docs81/jms/j2ee_components.html#1033768
          And are also summarized here (under interoperability):
          http://edocs.bea.com/wls/docs81/jms/intro.html#jms_features
          Also read the extensive MDB documentation, which extensively covers integrating foreign vendors:
          http://edocs.bea.com/wls/docs81/ejb/message_beans.html
          The 8.1 features are likely sufficient for most 8.1 integration needs, and you may not need to refer "Using Foreign JMS Providers With WLS" white-paper mentioned below.
          Integration with 6.1 and 7.0 Details
          Read the "Using Foreign JMS Providers With WLS" white-paper:
          http://dev2dev.bea.com/products/wlserver/whitepapers/jmsproviders.jsp
          Note that this white-paper does not take into account 8.1 features.
          For 7.0 read the extensive 8.1 MDB documentation, which largely also applies to 7.0:
          http://edocs.bea.com/wls/docs81/ejb/message_beans.html
          Non-Java Integration Options
          - WL JMS has a JNI based C client which can be called directly from windows. This C client supports 7.0 and up, and will be officially packaged with WLS in 9.0 (virtually unchanged). The C API is currently only supported through the jms newsgroup. See "JMS C API", here:
          http://dev2dev.bea.com/technologies/jms/index.jsp
          - WL supports direct Windows COM access through its "JCOM" feature. This doesn't include the JMS API, but one can invoke EJBs which in turn invoke JMS. See
          http://e-docs.bea.com/wls/docs61/jcom.html
          http://e-docs.bea.com/wls/docs70/jcom/
          http://e-docs.bea.com/wls/docs81/jcom/
          - Similar to JCOM, but more advanced, WL supports IIOP standard based access on multiple platforms. You can use the BEA Tuxedo C client for this purpose (no license fee). This doesn't include the JMS API, but one can invoke EJBs which in turn invoke JMS. See
          http://e-docs.bea.com/wls/docs81/rmi_iiop/
          http://e-docs.bea.com/wls/docs70/rmi_iiop/
          http://e-docs.bea.com/wls/docs61/rmi_iiop/
          Unlike most other approaches, the IIOP client approach also allows the client to begin and commit user (JTA) transactions (not configured).
          - If you already have a BEA Tuxedo license, one option is communicate through BEA Tuxedo (which has various APIs on Windows) and configure a WebLogic Server to respond to these requests via the WTC bridge. Search for "WTC" in the BEA docs. Unlike most other approaches, the Tuxedo API approach also allows the client to begin and commit user (JTA) transactions.
          - Another approach is to interop via web-service standards. Or even to simply to invoke a servlet on the WL server using a basic HTTP call from Windows. These in turn can invoke the JMS API. There is a white-paper on "Interoperability Study of BEA WebLogic Workshop 8.1 and Microsoft .NET 1.1 Web Services", that demonstrates web-services here:
          http://ftpna2.bea.com/pub/downloads/WebLogic-DotNet-Interop.pdf
          - Yet another approach is to use a third party product that is designed to wrap any JMS vendor. There are even open source versions. In no particular order, here are some examples: Open3 WinJMS, CodeMesh, Active JMS, SpiritSoft
          Notes on MQ Remote Capable XA Clients
          Until recently, IBM MQ JMS clients could not work transactionally unless they were running on the same host as their MQ server. This is a limitation unique to MQ that was relaxed with the introduction of IBM's new "WebSphere MQ Extended Transactional Client". See:
          http://publibfp.boulder.ibm.com/epubs/pdf/csqzar00.pdf
          The product is new, and for some reason, configuration of this client seems to be tricky, even when WebLogic is not involved at all. Oddly, the main sticking point seems to be simply making sure that class paths refer to the required IBM jars:
          - Required on WLS where MQ objects are bound into JNDI:
          com.ibm.mq.jar, com.ibm.mqjms.jar
          - Required only if MQ objects are bound into JNDI on a different server:
          com.ibm.mq.jar
          If there are problems when using this client, first get it to work using a pure IBM client without any BEA classes involved. Once that is working, search the WL JMS newsgroup for answers and/or contact BEA customer support.
          MDB Thread Pool Notes
          WL7.0SP? and WL8.1 and later support the "dispatch-policy" field to specify which thread pool an MDB uses to run its instances. In most cases this field should be configured to help address potential performance issues and/or dead-locks:
          http://edocs.bea.com/wls/docs81/ejb/DDreference-ejb-jar.html#dispatch-policy
          (Note that "dispatch-policy" is ignored for non-transactional foreign vendors; in this case, the MDB "onMessage" callback runs in the foreign vendor's thread.)
          MDB Concurrency Notes
          Queue MDBs driven by foreign providers can run multiple instances concurrently. Topic MDBs driven by foreign providers are limited to one instance (not sure, but transactional foreign driven topic MDBs may not have this limitation). The size of the thread pool that the MDB runs in and the "max-beans-in-free-pool" descriptor limit how many instances run concurrently.
          Design Guide-Lines and Performance Tuning Notes
          The "WebLogic JMS Performance Guide" white-paper contains detailed design, performance, and tuning information for Clustering, Messaging Bridge, JMS, and MDBs.
          http://dev2dev.bea.com/products/wlserver/whitepapers/WL_JMS_Perform_GD.jsp

Custom Consumers vs. MDBs

Similar Messages

Maybe you are looking for