MDB Topic & concurrency

The JMS faq say
"For Topics in WebLogic JMS 6.1, there is one JMSSession per bean instance in
the pool. Because of the way Topics work, the session, and thus every bean instance,
receives a copy of each message published on that Topic.
-- snip --
For each kind of MDB listening on the topic, the message is delivered exactly
once (i.e., the message will be delivered exactly once to an instance in each
named MDB pool listening on the topic)."
The two statements seem to condradict each other. One seems to say that each
instance in a pool will get a copy of the message and the otehr syas that the
pool as a whole will get only one copy of the message.
Am I being dense? Is there a version issue? What's going on?
-Gordon

If you have a cluster of N WLS servers and on each server you have a MDB
deployed which listens to topic T. Then an instance on each of the N
servers will receive a message from the topic.
If you send P messages to the topic T, then up to P instances may be
processing the messages in parallel on a given server. However, under
the covers they will all actually be using the same JMS Session. The
EJB container does some "fancy" stuff to get the JMS acks right. This
is one of those things that makes MDBs very attractive since it's a pain
to write this code yourself in JMS.
-- Rob
Gordon Palumbo wrote:
I would agree, but given the FAQ and this statement from an old post
(feb 2001)
"In the upcoming 6.0 service pack, only one instance per deployment
will receive
a copy of a topic message. In 6.0, each deployment listener instance
receives
a copy."
The statement that each instance get's a session (and is thus a
seperate listener)bothered
me.
I got worried about expected behavior or a lingering bug in Weblogic 6.X
I was looking for someone to confirm the actual behavior in WebLogic 6.1
-Gordon
Simon Evans wrote:
it is saying for each bean, there is a pool of instances. the message
gets delivered to each bean, but to only one instance from the pool.
one instance will be picked out of the pool to handle the message.
it would not make sense for each instance of the bean in a pool to
receive the message.
Gordon Palumbo wrote:
The JMS faq say
"For Topics in WebLogic JMS 6.1, there is one JMSSession per bean
instance
in
the pool. Because of the way Topics work, the session, and thus everybean instance,
receives a copy of each message published on that Topic.
-- snip --
For each kind of MDB listening on the topic, the message is deliveredexactly
once (i.e., the message will be delivered exactly once to an instancein each
named MDB pool listening on the topic)."
The two statements seem to condradict each other. One seems to saythat each
instance in a pool will get a copy of the message and the otehr syasthat the
pool as a whole will get only one copy of the message.
Am I being dense? Is there a version issue? What's going on?
-Gordon

Similar Messages

  • MDB topic listener and concurrent processing

    Hello to everybody.
    I ve prototyped simple db publisher ,which publishes changed data from database to JMS topic. Then I have my MDB which listens on JMS topic.
    I setup and implemented all correctly and it worked. There was 1 consumer = 1 mdb instance. Then I tried to do load testing , So I triggered 8000 changes from database. The db adapter did the job and published the 8000 messages on the JMS topic in a while. To mimic processing in MDB I put the sleep(10seconds) in MDB.
    MDB topic processing seems to me as not concurrent one. Why? I observed 10 message decrease with 5-10 seconds.
    What I expected was: concurrent processing of 8000 JMS messages by 1 MDB (so MDB is poolable component isnt it?).
    So for 500 instances of topic MDB and 8000 messages on the JMS topic, I expected at least 8000/500 X 10 = 160 seconds to process message load.
    I am using WLS 816.
    Can You give me some hits.
    Thanks
    Roman

    I did the same test on Weblogic 10 and it worked as expected. MDB durable subscriber consumed 8000 messages (each msg processing had 10 secs sleep inside.) within 2 minutes. So it is ok.
    But why it did not worked on WLS 8.1? Is this a bug ?

  • MDB Topic works, Queue doesnt 9.0.3

    Hi Gurus,
    As I wrote in subject, the topics work fine, but queues dont. MDB cannot reach the message. It looks like it dosn't know about queue. My OC4J realese 9.0.3. Did anybody encaunter similar issue ?

    Do you see any errors in server log when MDB was deployed or when message was enqueued?

  • MDB Maximum concurrent beans for Weblogic on Linux

    Has anyone noticed that the formula for determining maximum concurrent beans in use for MDBs for WL/Linux platform does not work. However, it does work for WL/Windows. The number of bean in use keeps growing (not bounded by either the number of worker threads or <max-beans-in-free-pool> settings. I have noticed the number crossing 1000 when <max-beans-in-free-pool> is set to only 40 and ThreadCount on the default execute Queue is only 100.

    if your MDB is using the default Execute Queue with 100 threads, the max instances of the mdb should be 51.
    I am surprised that this should be different on Win and Linux.
    Are your beans getting destroyed due to exceptions being thrown from the onMessage method ? this would be reflected in the DestroyedBeansCount.
    which version are you using ?
    cheers,
    Mihir

  • MDB/Topic/WLS cluster question

              Hi
              I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              in cluster config where say I have 3 servers with say server#1 hosting the Topic
              [not a distributed destination]. I have an an ear file containing an MDB with
              no pool size limit. After deploying the ear in the cluster - lets say that each
              server on the cluster has 5 instances of the MDB [just an example] and a message
              is published on the Topic.
              Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              is yes]
              Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              the same Topic - thats just going to get treated as a completely separate subscriber
              independent of the first MDB though the implementing class is the same - right?
              thanks
              Anamitra
              

              Anamitra wrote:
              > Hi
              > I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              > in cluster config where say I have 3 servers with say server#1 hosting the Topic
              > [not a distributed destination]. I have an an ear file containing an MDB with
              > no pool size limit. After deploying the ear in the cluster - lets say that each
              > server on the cluster has 5 instances of the MDB [just an example] and a message
              > is published on the Topic.
              >
              > Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              > is yes]
              Yes.
              > Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Yes.
              > Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              > the same Topic - thats just going to get treated as a completely separate subscriber
              > independent of the first MDB though the implementing class is the same - right?
              Yes.
              >
              > thanks
              > Anamitra
              >
              For a little more information, I'm attaching notes on durable
              subscriber MDBs.
              A JMS durable subscription is uniquely identified within a cluster by a combination of "connection-id" and "subscription-id". Only one active connection may use a particular "connection-id" within a WebLogic cluster.
              In WebLogic 8.1 and previous, a durable topic subscriber MDB uses its name to generate its client-id. Since JMS enforces uniqueness on this client-id, this means that if a durable subscriber MDB is deployed to multiple servers only one server will be able to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB connection id, which is unique within a cluster, comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The above prevents a durable topic subscriber MDB from running on multiple servers. When an instance of the MDB starts on another server, it deploys successfully, but a conflict is detected and the MDB fails to fully connect to JMS. The work-around is the following:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              4) A copy of each message is sent to each to each server's MDB pool.
              

  • Concurrent program performance Issue

    Hi,
    We are currently experiencing performance issue in one of the concurrent program related
    to the HR module. The concurrent request is currently completing in 3 hrs time.
    We have obtained a trace for the concurrent program.
    Please help me analyze the cause of the performance issue from the trace file.
    Trace file below:
    BEGIN SLC_PYINF_USMONACCROH_PKG.SLC_421_HANDLE_OUTBOUND(:errbuf,:rc,:A0,:A1,
    :A2,:A3,:A4,:A5,:A6,:A7,:A8,:A9,:A10,:A11); END;
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 76.08 9602.16 700828 1330818 663813 1
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 76.08 9602.16 700828 1330818 663813 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 3 0.00 0.00
    SQL*Net message from client 3 0.00 0.00
    PL/SQL lock timer 969 9.83 9485.16
    UPDATE HRAPPS.SLC_PYINF_USMONACCRO_STG SET PROCESS_STATUS = 2
    WHERE
    CONC_REQUEST_ID = :B2 AND SET_SEQUENCE_NUM = :B1 AND PROCESS_STATUS = 1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 24.83 45.67 145127 695479 602714 560730
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 24.83 45.67 145127 695479 602714 560730
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    0 UPDATE SLC_PYINF_USMONACCRO_STG (cr=684898 pr=134556 pw=0 time=44759708 us)
    1135266 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=694708 pr=124937 pw=0 time=6874212 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 15622 1.43 13.94
    db file sequential read 25578 0.52 14.30
    latch: cache buffers lru chain 3 0.00 0.00
    DELETE FROM SLC_PYINF_USMONACCRO_ARC
    WHERE
    EXTRACT_DATE<TRUNC(SYSDATE)-60
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 7.41 15.05 87598 87668 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 7.41 15.06 87598 87668 0 0
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    0 DELETE SLC_PYINF_USMONACCRO_ARC (cr=87668 pr=87598 pw=0 time=15053606 us)
    0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_ARC (cr=87668 pr=87598 pw=0 time=15053595 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file sequential read 3 0.00 0.00
    db file scattered read 11025 0.61 13.21
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1
    call count cpu elapsed disk query current rows
    Parse 2 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 10.14 10.23 116633 123540 0 2
    total 6 10.14 10.23 116633 123540 0 2
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=58317 pw=0 time=5290475 us)
    560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58317 pw=0 time=1689204 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 15646 0.27 6.24
    db file sequential read 625 0.00 0.01
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
    PROCESS_STATUS = 2
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 5.20 8.32 51482 69842 0 1
    total 3 5.20 8.32 51482 69842 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=69842 pr=51482 pw=0 time=8323369 us)
    560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=69842 pr=51482 pw=0 time=2811304 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 6514 0.30 6.09
    db file sequential read 114 0.00 0.02
    SELECT MAX(SET_SEQUENCE_NUM)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 5.34 6.63 58318 61770 0 1
    total 3 5.34 6.63 58318 61770 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=58318 pw=0 time=6639527 us)
    560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58318 pw=0 time=2250410 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 7820 0.30 4.46
    db file sequential read 313 0.00 0.05
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B2 AND
    SET_SEQUENCE_NUM = :B1 AND PROCESS_STATUS = 1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 4.99 4.88 58315 61770 0 1
    total 3 4.99 4.88 58315 61770 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=58315 pw=0 time=4887337 us)
    560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58315 pw=0 time=1688451 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 7824 0.00 3.02
    db file sequential read 313 0.00 0.00
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
    PROCESS_STATUS = 1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 4.98 4.87 58318 61770 0 1
    total 3 4.98 4.87 58318 61770 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=58318 pw=0 time=4872548 us)
    560730 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58318 pw=0 time=1688407 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 7821 0.00 2.98
    db file sequential read 312 0.00 0.00
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
    PROCESS_STATUS = -1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 4.45 4.36 58317 61770 0 1
    total 3 4.45 4.36 58317 61770 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=58317 pw=0 time=4369473 us)
    0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=58317 pw=0 time=4369425 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 7823 0.00 2.98
    db file sequential read 312 0.00 0.00
    SELECT COUNT(*)
    FROM
    HRAPPS.SLC_PYINF_USMONACCRO_STG WHERE CONC_REQUEST_ID = :B1 AND
    PROCESS_STATUS < 0
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 4.14 4.24 51481 61770 0 1
    total 3 4.14 4.24 51481 61770 0 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1 SORT AGGREGATE (cr=61770 pr=51481 pw=0 time=4243020 us)
    0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_STG (cr=61770 pr=51481 pw=0 time=4242968 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 6537 0.06 2.90
    db file sequential read 104 0.00 0.00
    DELETE FROM SLC_PYINF_USMONACCRO_GLI_ARC
    WHERE
    EXTRACT_DATE<TRUNC(SYSDATE)-60
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.63 2.52 7681 7689 0 0
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.63 2.52 7681 7689 0 0
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    0 DELETE SLC_PYINF_USMONACCRO_GLI_ARC (cr=7689 pr=7681 pw=0 time=2521592 us)
    0 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_GLI_ARC (cr=7689 pr=7681 pw=0 time=2521583 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file sequential read 1 0.00 0.00
    db file scattered read 976 1.00 2.36
    UPDATE HRAPPS.SLC_PYINF_USMONACCRO_GLI_STG SET PROCESS_STATUS = 2
    WHERE
    CONC_REQUEST_ID = :B1 AND PROCESS_STATUS = 1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 1.89 2.25 5863 16125 60963 52309
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 1.89 2.25 5863 16125 60963 52309
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    0 UPDATE SLC_PYINF_USMONACCRO_GLI_STG (cr=11787 pr=1273 pw=0 time=1332023 us)
    122679 TABLE ACCESS FULL SLC_PYINF_USMONACCRO_GLI_STG (cr=16291 pr=5859 pw=0 time=48501241 us)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file scattered read 745 0.01 0.76
    db file parallel read 1 0.00 0.00
    db file sequential read 5 0.00 0.00
    SELECT B.ATTRIBUTE1 ,B.ATTRIBUTE2 ,B.ATTRIBUTE3 ,T.FLEX_VALUE_MEANING ,
    T.DESCRIPTION
    FROM
    FND_FLEX_VALUES_TL T ,FND_FLEX_VALUES B WHERE B.FLEX_VALUE_ID =
    T.FLEX_VALUE_ID AND T.LANGUAGE = USERENV ('LANG') AND TRIM(UPPER
    (B.FLEX_VALUE)) = TRIM(UPPER (:B1 )) AND B.ENABLED_FLAG = 'Y' AND UPPER
    (B.VALUE_CATEGORY) = UPPER ('SLCHR_INTERFACE_CLEANUP')
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 0.25 0.86 1640 3286 0 2
    total 5 0.25 0.86 1640 3286 0 2
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    2 NESTED LOOPS (cr=3286 pr=1640 pw=0 time=866461 us)
    2 TABLE ACCESS FULL FND_FLEX_VALUES (cr=3280 pr=1637 pw=0 time=848331 us)
    2 TABLE ACCESS BY INDEX ROWID FND_FLEX_VALUES_TL (cr=6 pr=3 pw=0 time=18101 us)
    2 INDEX UNIQUE SCAN FND_FLEX_VALUES_TL_U1 (cr=4 pr=2 pw=0 time=9705 us)(object id 849241)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file sequential read 4 0.00 0.02
    db file scattered read 208 0.30 0.71
    SELECT PHASE_CODE, STATUS_CODE, COMPLETION_TEXT, PHASE.LOOKUP_CODE,
    STATUS.LOOKUP_CODE, PHASE.MEANING, STATUS.MEANING
    FROM
    FND_CONCURRENT_REQUESTS R, FND_CONCURRENT_PROGRAMS P, FND_LOOKUPS PHASE,
    FND_LOOKUPS STATUS WHERE PHASE.LOOKUP_TYPE = :B3 AND PHASE.LOOKUP_CODE =
    DECODE(STATUS.LOOKUP_CODE, 'H', 'I', 'S', 'I', 'U', 'I', 'M', 'I',
    R.PHASE_CODE) AND STATUS.LOOKUP_TYPE = :B2 AND STATUS.LOOKUP_CODE =
    DECODE(R.PHASE_CODE, 'P', DECODE(R.HOLD_FLAG, 'Y', 'H',
    DECODE(P.ENABLED_FLAG, 'N', 'U', DECODE(SIGN(R.REQUESTED_START_DATE -
    SYSDATE),1,'P', R.STATUS_CODE))), 'R', DECODE(R.HOLD_FLAG, 'Y', 'S',
    DECODE(R.STATUS_CODE, 'Q', 'B', 'I', 'B', R.STATUS_CODE)), R.STATUS_CODE)
    AND (R.CONCURRENT_PROGRAM_ID = P.CONCURRENT_PROGRAM_ID AND
    R.PROGRAM_APPLICATION_ID= P.APPLICATION_ID ) AND REQUEST_ID = :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 971 0.25 0.16 0 0 0 0
    Fetch 971 0.53 0.65 0 13605 0 971
    total 1943 0.78 0.81 0 13605 0 971
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    971 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=17489 pr=0 pw=0 time=877481 us)
    2913 NESTED LOOPS (cr=16518 pr=0 pw=0 time=1643550 us)
    971 NESTED LOOPS (cr=11663 pr=0 pw=0 time=658551 us)
    971 NESTED LOOPS (cr=5837 pr=0 pw=0 time=95374 us)
    971 TABLE ACCESS BY INDEX ROWID FND_CONCURRENT_REQUESTS (cr=2924 pr=0 pw=0 time=63054 us)
    971 INDEX UNIQUE SCAN FND_CONCURRENT_REQUESTS_U1 (cr=1953 pr=0 pw=0 time=43874 us)(object id 240792)
    971 TABLE ACCESS BY INDEX ROWID FND_CONCURRENT_PROGRAMS (cr=2913 pr=0 pw=0 time=28198 us)
    971 INDEX UNIQUE SCAN FND_CONCURRENT_PROGRAMS_U1 (cr=1942 pr=0 pw=0 time=17956 us)(object id 849182)
    971 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=5826 pr=0 pw=0 time=558105 us)
    971 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=4855 pr=0 pw=0 time=539171 us)(object id 906518)
    971 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=4855 pr=0 pw=0 time=172115 us)(object id 906518)
    SELECT MAX(LT.SECURITY_GROUP_ID)
    FROM
    FND_LOOKUP_TYPES LT WHERE LT.VIEW_APPLICATION_ID = :B2 AND LT.LOOKUP_TYPE =
    :B1 AND LT.SECURITY_GROUP_ID IN (0,
    TO_NUMBER(DECODE(SUBSTRB(USERENV('CLIENT_INFO'),55,1), ' ', '0', NULL, '0',
    SUBSTRB(USERENV('CLIENT_INFO'),55,10))))
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1945 0.11 0.11 0 0 0 0
    Fetch 1945 0.18 0.10 0 3890 0 1945
    total 3891 0.29 0.21 0 3890 0 1945
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Rows Row Source Operation
    1945 SORT AGGREGATE (cr=3890 pr=0 pw=0 time=142954 us)
    1945 FIRST ROW (cr=3890 pr=0 pw=0 time=96520 us)
    1945 INDEX RANGE SCAN (MIN/MAX) FND_LOOKUP_TYPES_U1 (cr=3890 pr=0 pw=0 time=89938 us)(object id 906517)
    INSERT INTO HRAPPS.SLC_HRINF_INT_SUMMARY (INT_SUMMARY_ID,
    INT_SUMMARY_CREATE_DATE ,INT_SUMMARY_LAST_UPDATE_DATE, INTERFACE_NAME ,
    HANDLER_CONC_REQUEST_ID, INT_CONC_REQUEST_ID ,SET_SEQUENCE_NUMBER,
    SET_RECORD_COUNT, INT_FROM_DATE ,INT_TO_DATE, INT_STATUS_1_STATE,
    INT_STATUS_1_MESSAGE ,INT_STATUS_1_STARTED, INT_STATUS_1_COMPLETED ,
    INT_STATUS_1_SUCCESS_COUNT, INT_STATUS_1_ERROR_COUNT ,INT_STATUS_2_STATE,
    INT_STATUS_2_MESSAGE ,INT_STATUS_2_STARTED, INT_STATUS_2_COMPLETED ,
    INT_STATUS_2_SUCCESS_COUNT, INT_STATUS_2_ERROR_COUNT ,INT_STATUS_3_STATE,
    INT_STATUS_3_MESSAGE ,INT_STATUS_3_STARTED, INT_STATUS_3_COMPLETED ,
    INT_STATUS_3_SUCCESS_COUNT, INT_STATUS_3_ERROR_COUNT ,INT_STATUS_4_STATE,
    INT_STATUS_4_MESSAGE ,INT_STATUS_4_STARTED, INT_STATUS_4_COMPLETED ,
    INT_STATUS_4_SUCCESS_COUNT, INT_STATUS_4_ERROR_COUNT ,INT_STATUS_5_STATE,
    INT_STATUS_5_MESSAGE ,INT_STATUS_5_STARTED, INT_STATUS_5_COMPLETED ,
    INT_STATUS_5_SUCCESS_COUNT, INT_STATUS_5_ERROR_COUNT )
    VALUES
    (:B7 , :B6 , :B6 , :B5 , :B4 , NULL , NULL, NULL, :B3 , :B2 , :B1 , NULL ,
    NULL, NULL , NULL, NULL , :B1 , NULL , NULL, NULL , NULL, NULL , :B1 , NULL
    , NULL, NULL , NULL, NULL , :B1 , NULL , NULL, NULL , NULL, NULL , :B1 ,
    NULL , NULL, NULL , NULL, NULL )
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.01 0.12 12 1 12 1
    Fetch 0 0.00 0.00 0 0 0 0
    total 2 0.01 0.12 12 1 12 1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 70 (recursive depth: 1)
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    db file sequential read 12 0.02 0.12
    Thanks & Regards,
    Rup

    Hi;
    Please check our previous topic
    Concurrent manager real time tune
    Oracle apps database
    tune concurrent manager
    Oracle apps database
    Concurrent Manager very slow
    Concurrent Manager very slow........
    Regard
    Helios

  • Error running A Simple MDB example with oc4j

    Hi All,
    I am new to OC4J, I am trying the example for MDB from OTN's site, A Simple MDB example with OC4J. When I start my OC4J on the command line > java -jar oc4j.jar
    I get the following exception:
    Error deploying file:/C:/unzipped/mdb_hello_world/build/mdb/mdb.jar homes: No lo
    cation set for Topic resource MessageDrivenBean MDB
    Error in application mdb: Error loading package at file:/C:/unzipped/mdb_hello_w
    orld/build/mdb/mdb.jar, Error deploying file:/C:/unzipped/mdb_hello_world/build/
    mdb/mdb.jar homes: No location set for Topic resource MessageDrivenBean MDB
    04/07/09 15:21:40 Error instantiating application 'mdb' at file:/C:/unzipped/mdb
    helloworld/build/mdb.ear: Error initializing ejb-module; Exception Error in ap
    plication mdb: Error loading package at file:/C:/unzipped/mdb_hello_world/build/
    mdb/mdb.jar, Error deploying file:/C:/unzipped/mdb_hello_world/build/mdb/mdb.jar
    homes: No location set for Topic resource MessageDrivenBean MDB
    04/07/09 15:21:41 Error starting HTTP-Server: Address already in use: JVM_Bind
    04/07/09 15:21:41 Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)
    initialized
    I have just followed all the steps provided to run the example exactly as given.
    I did add my Topic and TopicConnectionFatory entries in my jms.xml -
    <topic name="The Topic" location="jms/theTopic">
    <description>A MDB topic</description>
    </topic>
    <topic-connection-factory location="jms/theTopicConnectionFactory" />
    Here is the ejb-jar.xml given in the example:
    <?xml version="1.0"?>
    <!DOCTYPE ejb-jar>
    <ejb-jar>
    <enterprise-beans>
    <message-driven>
    <description>My message driven bean</description>
    <ejb-name>MDB</ejb-name>
    <ejb-class>MDB</ejb-class>
    <transaction-type>Container</transaction-type>
    <message-driven-destination>
    <destination-type>javax.jms.Topic</destination-type>
    <subscription-durability>NonDurable</subscription-durability>
    </message-driven-destination>
    <resource-ref>
    <description>The log topic where log events are broadcasted...</description>
    <res-ref-name>jms/theTopic</res-ref-name>
    <res-type>javax.jms.Topic</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    <resource-ref>
    <description>The Factory used to produce connections to the log topic...</description>
    <res-ref-name>jms/theTopicConnectionFactory</res-ref-name>
    <res-type>javax.jms.TopicConnectionFactory</res-type>
    <res-auth>Container</res-auth>
    </resource-ref>
    </message-driven>
    </enterprise-beans>
    <assembly-descriptor>
    <container-transaction>
    <method>
    <ejb-name>MDB</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Supports</trans-attribute>
    </container-transaction>
    </assembly-descriptor>
    </ejb-jar>
    Here is my orion-ejb-jar.xml:
    <?xml version="1.0"?>
    <!DOCTYPE orion-ejb-jar PUBLIC "-//Evermind//DTD Enterprise JavaBeans 1.1 runtime//EN" "http://xmlns.oracle.com/ias/dtds/orion-ejb-jar.dtd">
    <orion-ejb-jar deployment-version="1.0.2.2" deployment-time="e7f5a3f42d">
    <enterprise-beans>
    <message-driven-deployment name="MDB" destination-location="jms/theTopic" connection-factory-location="jms/theTopicConnectionFactory">
    <resource-ref-mapping name="jms/theTopic" />
    <resource-ref-mapping name="jms/theTopicConnectionFactory" />
    </message-driven-deployment>
    </enterprise-beans>
    <assembly-descriptor>
    <default-method-access>
    <security-role-mapping name="&lt;default-ejb-caller-role&gt;" impliesAll="true" />
    </default-method-access>
    </assembly-descriptor>
    </orion-ejb-jar>
    I don't know what is wrong. Please help me.
    Rohini

    Hello,
    I guess that you didn't define the Topic and/or TopicConnectionFactory on your OC4J
    Inside $J2EE_HOME/config (see: subfolders .../j2ee/home/config e.g.)folder are several xml files appropriate for OC4J configuration. There's also jms.xml. Please, verify this one, it should have some entries for your settings.
    Just like in an example below:
    <topic-connection-factory name="TopicConnectionFactory" location="jms/TopicConnectionFactory"/>
    <topic name="theTopic" location="jms/theTopic"/>
    The names should be the same like in your MDB deployment descriptors. It works of course after next OC4J server restart.
    I hope helped you
    Krzysztof

  • Distributed Topics function as intended?

    My question conerns distributed topics and how their intended functionality in a clustered environment should work.
              We have a clustered WLS 8.1 environment with two managed servers with app A and app B deployed to each of them. App A has a distributed topic that it publishes messages to. App A also has a JMS Server on each managed server with a physical topic on each one. So both of these topics are tied to the one Distributed topic. App B is subscribed to this distributed topic. When App A publishes a message to this topic - WL publishes a message to each physical topic on each managed server. Then App B's MDBs (one on each managed server) retrieve their message - in effect processing the one message twice (from an application standpoint). The behavior that I'd like to see is if one message is published to the distributed topic - that one of App A's physical topics would get the message - and that one of the MDBs in App B would process the message. In effect now we receive double messages into App B. Using a distributed Queue in App A is currently not possible as multiple different apps must listen for messages from App A.
              So if you were not running in a clustered environment you would not see this type of behavior because you'd ultimately be publishing only one message to one topic and your mdb would receive only one message.
              Can anyone comment on this?

    Hi,
              This is expected behavior. The purpose of a topic, or a distributed topic, is message replication. You would see the same behavior even if the topic was not distributed:
              MDB App A gets a message copy on both servers 1 and 2
              MDB App B gets a message copy on both servers 1 and 2
              If you made the MDB topic subscriptions "durable", you would get the behavior you desire. This is because durable subscriptions are exclusive, so that only the first MDB pool for App A to attach to the subscription would get messages - the other MDB pool A on the other server would be idle (but constantly retrying until the first MDB pool A fails, undeployes, or shuts down).
              I think this information is also in the MDB chapter of the 8.1 EJB Vdocs...
              Tom

  • Dynamic Topics in JMS

    Hi,
    I'm not sure if something like this is possible so I am looking for some guidance please.
    I need publish/subscribe functionality. I have countless number of Items/products/things that I would like users to be able to subscribe to. User sees an item and they "subscribe" to that item for notifications of any changes to that item.
    Subscribing to a JMS Topics seem to limited. It seems to only allow the user to: subscribe(SOME_TOPIC) Doing this the JMS Topic has no idea that the user really wants only notifications for a specific item (like ITEM_1 or ITEM_n).
    I don't see a way to dynamically create JMS Topics like subscribe(ITEM_1_TOPIC) and also subscribe(ITEM_n_TOPIC)Any help would be greatly appreciated.
    The implementation of the JMS MDB Topic would be same except for only the value passed in to the Topic's 'subscribe' method.
    Thanks,
    Jared

    I think what your question boils down to is whether you can call Session.createTopic(topicName) to create new topics on-the-fly. The JMS specification doesn't require this to be possible, but many vendors including Glassfish Message Queue do allow this.
    If your JMS provider doesn't allow dynamically-created topics you can achieve the same effect by using a standard topic name and then a message selector to "filter" the topic. A message selector allows the consumer to specify that they want to receive only those messages which match some specified condition based on a message property.
    Nigel

  • Newbie performance question

    Our system is set up to send a lot of XML messages to a JMS topic on WL8.1. I have an MDB listening to the topic and a couple of stateless session beans that get invoked by the MDB. The rate is something on the order of 10/sec(moderately sized xml messages). Both beans do some database interfacing.
              Basically we run for an 45min - 1 hour with no problems, take a break, then run the same scenario again and at some point (specifically last time, 20 minutes in) I noticed a drastic fall behind in the MDB processing (I measure the time the client publishes the message to when my MDB processes via some log files I keep).
              I'm new to J2EE stuff and haven't thus far looked into the performance tuning of my EJBs/MDBs. I read a white paper on tuning beans which describes the various properties that can be set but doesn't go into detail on what to set them at.
              Currently I dont' have any settings for initial-beans-in-pool or max-beans-in-pool. I'm trying to determine if this will help solve the problem and how to get an idea of what to start with for numbers there. All my beans have "Not supported" for the transaction type.
              If anybody can point me to some detailed information on this matter or has any suggestions - I'd greatly appreciate it.

    Hi,
              Sorry I didn't earlier - I was on vacation.
              >>> I'm not using persistance (this is controlled at the topic level correct?) - at least I don't think I am.
              This is typically controlled at the application level. The sender must send messages as "persistent" (see JMS doc), and the subscriber must be "durable" (see MDB doc). Message persistence can be overridden via topic configuration or JMS configuration (such as by configuring JMS without a persistent store).
              >>> I don't think CPU usage was the issue because several other processes running on the box trucked on as usual.
              I don't this is a sufficient gauge of CPU usage or CPU bottlenecks. It is possible for an app to peg out at 100% CPU and still have other applications "truck on as usual".
              >>> Like I said, a couple of the EJBs invoked by the MDB do some database insertions with data extracted from the xml messages. However, after reading some more the default value for max-beans-in-pool is 1000 - I can't imagine 1000 beans are tied up doing this allowing the topic to back up??
              Maximum MDB/EJB concurrency is limited by the number of available threads in addition to "max-beans-in-pool". The number of available threads is configurable and is typically far less than 1000. For info, see the JMS Performance Guide I mentioned earlir and/or the MDB documentation.
              Since performance drops after a certain time-period, another thing to check is whether the message backlog increases significantly as time goes on. It is often useful to check for this by generating multiple JMS statistics dumps as time goes on - you can use the "JMSStats.java" program (available on dev2dev) for this purpose. It would also be interesting to check how DB and DB host-machine stats change as the application runs.
              Tom

  • How to use IBM MQ as a JMS Provider?

     

    Chapter 8.2 on session pools in the 1.0.2 spec seems to make no real mention
              of transansactions. If not could you point exactly where? What steps would
              one use to cause a foreign messaging-server to infect an async message
              with a JTA transaction using Chapter 8.2 session pools?
              Chapter 8.3 describes the XA libraries, which are not related to session pools.
              The general community feeling on Chapter 8.2 SessionPools is that in almost all
              cases they are
              inferior to MDBs. To make it worse, they are not a required part of the J2EE
              spec. Their
              only real advantage is that they can pool access to a single topic subscription.
              Nice, but hardly
              worth the trouble. Just brainstorming here, but the elegant solution here
              seems simple: extend
              the JMS spec to allow multiple consumers on a single subscription. This would
              also nicely solve
              one MDB/topic problem, as even with SessionPools, there is no way to have MDBs
              on multiple
              servers share a single subscription...
              I don't think the spec states that SessionPools should run on a client. I'm
              fairly sure
              that SessionPools were intended to be a server-side entity. The numerous
              repetitions stating
              that the MessageListener runs on the app server and that the app server controls
              the threads seems to support
              this. It is an extension past Chapter 8.2 to get them to work off-server.
              (Albeit potentially a nice one, if
              one is absolutely determined to use these things instead of MDBs.)
              Maciej Szefler wrote:
              > I've noticed that BEA maintains that this is a shortcoming in the JMS
              > spec -- particularly that there is no way to integrate XA messages from
              > other JMS implementations into Weblogic without the vendor implementing
              > propriatary Weblogic interfaces, I quote your FAQ:
              >
              > "The only reason this works for WebLogic Server JMS is that we have defined
              > a WebLogic Server extension interface that has a method to associate a
              > message with a transaction. This interface, MDBTransaction, is defined in
              > news://newsgroups.bea.com/[email protected]. It has one method,
              > associateTransaction(), that takes a javax.jms.Message parameter. This
              > message must be associated with the transaction. We are hoping that other
              > JMS vendors interested in integrating with WebLogic Server will implement
              > this interface. "
              >
              > "Another approach called source managed transactions, would be for there to
              > be an API to tell the JMS provider to start a transaction on your behalf
              > before delivering the message to an asynchronous consumer. This API doesn't
              > exist in J2EE either. Even if there were such a provision, few non-WLS JMS
              > providers can begin and drive such a transaction by themselves."
              >
              > I would like to know where it is that you guys came up with this novel (and
              > incorrect) position. The JMS API to do this exists, it is called ASF (JMS
              > spec chapter 8) and if WebLogic implemented it correctly then there would be
              > no problem driving XA MDBs using MQseries. The fact of the matter is that
              > Weblogic 6.1 server is simply not JMS compliant in this respect. The 6.1 JMS
              > implementation does not expose the ASF correctly (it relies on the client
              > using a special ServerSesisonPool implementation), nor does the MDB
              > container use the ASF (which I guess is understandable since it isn't
              > implemented correctly). The question is, is Weblogic 7.0 Server going to use
              > ASF to drive MDBs and is the Weblogic 7.0 JMS implemetation going to
              > correctly expose the ASF to advanced clients that may wish to use it?
              >
              > -Maciej Szefler
              > FiveSight Technologies Inc.
              >
              > "Tom Barnes" <[email protected]> wrote in message
              > news:[email protected]...
              > > Clarification. See in-line.
              > >
              > > Tom Barnes wrote:
              > >
              > > > Hi Steve,
              > > >
              > > > This request comes up numerous times in this newsgroup. Since
              > > > the FAQ isn't quite up to date, here is the cut-and-paste response:
              > > >
              > > > Resources:
              > > > Resource Library/White-Papers/WebLogic Server section on dev2dev site:
              > > >
              > http://dev2dev.bea.com/resourcelibrary/whitepapers.jsp?highlight=whitepapers
              > > > jmsproviders.doc, jmsmdb.doc, jmsjta.doc
              > > >
              > > > Code Library/Code Samples/WebLogic Server section on dev2dev site:
              > > > "WebLogic MQSeries JMS Support"
              > > > wlsmqseries.zip
              > > >
              > > > Code Library/Alpha Code/WebLogic Server section on dev2dev site:
              > > > "Sample JMSBridge For WebLogic 6.0"
              > > > JMSBridge60.zip
              > > >
              > >
              > > The above is 6.0 sample code that has nothing to do the below 6.1 alpha
              > bridge, and
              > > was not developed by anyone on the JMS team. The location for the 6.1
              > information is:
              > >
              > > Resource Library/Guides and Tutorials
              > > "Introducing WebLogic Messaging Bridge"
              > > MessagingBridge61.zip
              > >
              > > (see
              > >
              > http://dev2dev.bea.com/resourcelibrary/guidestutorials/technicalguides.jsp?h
              > ighlight=guidestutorials)
              > >
              > >
              > >
              > > >
              > > > The 6.1 MDB can be driven directly by standard JMS implementations -
              > but
              > > > not transactionally by vendors that do not implement the
              > > > weblogic.jms.extensions.MDBTransaction interface. Such vendors
              > > > (including MQSeries) can be made transactional by using a messaging
              > bridge
              > > > to synchronously forward MQSeries messages into WL queues that in turn
              > > > drive the MDB. The 7.0 MDB will be able to be driven transactionally
              > > > by non-WL vendors.
              > > >
              > > > The messaging bridge works with JMS implementations that implement
              > > > the standard J2EE JMS API. This bridge is available as alpha code
              > > > for 6.1, will be fully supported in 6.1SP3 (due out in June?), and is
              > also
              > > > part of 7.0 (currently released in beta).
              > > >
              > > > Tom
              > > >
              > > > steve chen wrote:
              > > >
              > > > > We like to use IBM MQ as our message provider, use Message Driven
              > Bean (Weblogic
              > > > > 6.1) as the consumer. How do we configure WLS so it uses IBM MQ
              > instead of WLS
              > > > > built in JMS as the provider?
              > > > >
              > > > > Thanks
              > >
              

  • EBS 11i OAM Monitor

    Hi,
    I am opening my EBS OAM, to monitor my Applications.
    On the first page > Overview >     Applications System Status
    Host                    Platform          Host Status     Admin     Database     Concurrent Processing     Forms     Web
    ORACLEPROD     LINUX Intel     Up                   Up     Up                 Down                   Up         UpI can see in the chart that Concurrent Processing is down? Why? How do I startup it? I am surprise because the users are not complainig even
    if it is down the wholeday :( , Or maybe they do not use the concurrent processing?
    Please help,
    Thanks a lot
    Ms K

    Hi;
    Please check Hussen Sawwan greatest previous post about same topic
    concurrent processing status down in OAM
    I belive it will answer you
    Regard
    Helios

  • EBS 11i OAM 11GR2PS1 integration

    Hi All,
    I am trying to integrate EBS 11i with OIM 11.1.2.1 and OID 11.1.1.6 .
    please let me know any document that i can follow , any prerequisites and screen shots you may have.Please share.
    Thanks.

    Hi;
    Please check Hussen Sawwan greatest previous post about same topic
    concurrent processing status down in OAM
    I belive it will answer you
    Regard
    Helios

  • Concurrent MDBs

    Hi!
              SUN JMS specs say, that "The session used to create the message consumer
              serializes the execution of all message listeners registered with the
              session. At any time, only one of the session's message listeners is
              running." As I understand this statement, I can be sure, that for particular
              session only one listener is active in any moment of time.
              Further statement says that "In the J2EE 1.3 platform, a message-driven bean
              is a special kind of message listener." And, "Like a stateless session
              bean, a message-driven bean can have many interchangeable instances running
              at the same time. The container can pool these instances to allow streams of
              messages to be processed concurrently. Concurrency can affect the order in
              which messages are delivered, so you should write your application to handle
              messages that arrive out of sequence. "
              So, in J2EE real JMS listener is located somewhere in the app server and
              gets messages in serialized manner, but it passes these messages to MDBs,
              which can run concurrently?
              The questions are:
              * does serialized mode of standard JMS listeners ensure the correct message
              order?
              * how I can serialize message processing, using MDBs? I use WLS7, if it may
              help. I guess I can tune server to use only one instance of MDB... Any other
              approaches?
              

    There have been several posts on this topic in the past. If I remember
              correctly, while you will be able to maintain order integrity with a single
              consumer or MDB instance, it would work only as long as there are no
              rollbacks. There is no guarantee of ordering in the event of rollbacks.
              Thanks,
              Adarsh
              "Michael Jouravlev" <[email protected]> wrote in message
              news:[email protected]...
              > Hi!
              >
              > SUN JMS specs say, that "The session used to create the message consumer
              > serializes the execution of all message listeners registered with the
              > session. At any time, only one of the session's message listeners is
              > running." As I understand this statement, I can be sure, that for
              particular
              > session only one listener is active in any moment of time.
              >
              > Further statement says that "In the J2EE 1.3 platform, a message-driven
              bean
              > is a special kind of message listener." And, "Like a stateless session
              > bean, a message-driven bean can have many interchangeable instances
              running
              > at the same time. The container can pool these instances to allow streams
              of
              > messages to be processed concurrently. Concurrency can affect the order in
              > which messages are delivered, so you should write your application to
              handle
              > messages that arrive out of sequence. "
              >
              > So, in J2EE real JMS listener is located somewhere in the app server and
              > gets messages in serialized manner, but it passes these messages to MDBs,
              > which can run concurrently?
              >
              > The questions are:
              > * does serialized mode of standard JMS listeners ensure the correct
              message
              > order?
              > * how I can serialize message processing, using MDBs? I use WLS7, if it
              may
              > help. I guess I can tune server to use only one instance of MDB... Any
              other
              > approaches?
              >
              >
              >
              >
              

  • Topic vs MDB's

              Hi,
              We are designing an application which will serve as message broker between different
              publisher and subscriber applications. We are planning to use Weblogic 6.1 JMS
              for that purpose. Could you please let me know what are the pros and cons of having
              multiple topics for different types of messages VS having a single topic serving
              all types of messages and multiple MDB's with message selectors to process those
              messages?
              Also, could you please let me know the resources I can refer for looking at different
              design patterns and design considerations for this type of JMS message broker?
              Thanks,
              Goutam.
              

    Jason -- One important point is that the EJB specification (specifically MDBs) does not guarantee FIFO processing. Here is the quote from section 15.4.6 of the spec:
    A container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class, although the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. Message-driven beans should therefore be prepared to handle messages that are out of sequence: for example, the message to cancel a reservation may be delivered before the message to make the reservation.
    That said, I have seen queuing systems that have used both types of arrangements you describe (although none were using JMS.) For the generic case, there were problems if the queue was backed up so you might consider multiple queues with different priorities, each of which has a generic payload. This helps starvation of time critical messages.
    If you do establish different topics, then you will have more work to do in terms of deployment and management of the topics, but the messages will be cleanly separated and you may be able to make some optimizaitons of message processing since they can be created in a form that best mathces their use.
    Overall, my experiences with generic queues, once we established multiple queues with different priorities, was good. Just be ready for the additional overhead of processing XML messages.
    Thanks -- Jeff

Maybe you are looking for

  • PDO Layer Error while approving a changed version of PO

    Hi, We are in SRM7.0 , EC Scenario , ECC 6.0 In SAP SRM system am experiencing a workflow issue , second level approver is not able to approve/receive the workitem of a changed PO. Moment we try to open the PO (changed version) and navigate to Approv

  • I can't install iOS4.1 from Tiger...

    What a screw up on Apple's part... I have iTunes 9.0.2 and you need at least 9.2 to install iOS4. iTunes 9.2 requires Leopard (I'm running Tiger). And of course iTunes 10 requires Leopard as well. So people with Tiger are SOL I guess. How stupid is t

  • Mapping: Fitting managers into rooms ?

    Hello All, The below map is disinclined to acquiesce to my request; translation: itz knot verkin. I'm trying to fit the 'managers' in the source into 'room's in the target. Assuming a max of 4 rooms, I want them filled up with 4 managers per room (wi

  • Ccm 5.x DB

    hi in callmanager 4.x the database used was MS SQL, what about callmanager 5.x, which database it is using? thanks

  • I hit download and nothing has happened. I did save it. It's driving my crazy.

    There are no details. It simply does nothing. I tried it a week ago and the same thing happened.