Announcement Announcement Module
Collapse
No announcement yet.
DefaultMessageListenerContainer CommonJ WorkManager rejects Work - Weblogic 9.2 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • DefaultMessageListenerContainer CommonJ WorkManager rejects Work - Weblogic 9.2

    Hi,

    I'm trying to use the DefaultMessageListenerContainer in conjunction with the CommonJ WorkManager (via Spring's TaskExecutor abstraction) on Weblogic 9.2.

    When the DefaultMessageListenerContainer comes up and tries to schedule it's AsynchronousMessageListenerInvoker's with the WorkManager (to create a set of message consumers), the WorkManager immediately accepts and then rejects the work. I can see this as I'm using a WorkListener to log out work events.

    The interesting thing is that the WorkManager never attempts to execute the work before rejecting it (a breakpoint in AsyncMessageListenerInvoker confirms this). It simply rejects it outright.

    If I don't specify a TaskExecutor explicitly on the DefaultMessageListenerContainer and let Spring use it's default SimpleAsyncTaskExecutor then this seems to work - I see a number of message consumers created and all is well. However, my project mandates the use of CommonJ thread management.

    Also, using SimpleMessageListenerContainer and ServerSessionMessageListenerContainer (with the CommonJ WorkManager) work with no problems. However, the fault tolerant nature of the DefaultMessageListenerContainer is desired.

    Is there any reason why Weblogic's CommonJ implementation would reject the scheduling of message consumer work items before the work is attempted to be executed? And is there any reason why the DefaultMessageListenerContainer has this issue specifically? I've turned on WorkManager debug in Weblogic which wasn't able to shed any light.

    Many thanks in advance,

    Will

  • #2
    Same problem ?

    Hi ,

    I am also facing the same problem. Without taskExecutor it works fine but if I give the taskexecutor the task is simply not executed by the consumer.


    <bean id="jmsContainerForScheduler"
    class="org.springframework.jms.listener.DefaultMes sageListenerContainer">
    <property name="connectionFactory" ref="schedulerConnectionFactory" />
    <property name="destination" ref="schedulerQueue" />
    <property name="messageListener" ref="schedulerConsumer" />
    <property name="transactionManager" ref="txManager" />
    <property name="concurrentConsumers" value="1"/>
    <property name="maxConcurrentConsumers" value="6"/>
    <property name="taskExecutor" ref="taskExecutor"/>
    </bean>


    works when I do NOT provide

    <property name="taskExecutor" ref="taskExecutor"/>


    My commonj workmanager setting is

    <fair-share-request-class>
    <name>high_priority</name>
    <target>AdminServer</target>
    <fair-share>100</fair-share>
    </fair-share-request-class>
    <min-threads-constraint>
    <name>MinThreadsConstraint-5</name>
    <target>AdminServer</target>
    <count>1</count>
    </min-threads-constraint>
    <max-threads-constraint>
    <name>MaxThreadsConstraint-200</name>
    <target>AdminServer</target>
    <count>200</count>
    <connection-pool-name></connection-pool-name>
    </max-threads-constraint>
    <capacity>
    <name>CapacityCountFiveThousand</name>
    <target>AdminServer</target>
    <count>5000</count>
    </capacity>
    <work-manager>
    <name>billingWM</name>
    <target>AdminServer</target>
    <fair-share-request-class>high_priority</fair-share-request-class>
    <response-time-request-class xsi:nil="true"></response-time-request-class>
    <context-request-class xsi:nil="true"></context-request-class>
    <min-threads-constraint>MinThreadsConstraint-5</min-threads-constraint>
    <max-threads-constraint>MaxThreadsConstraint-200</max-threads-constraint>
    <capacity>CapacityCountFiveThousand</capacity>
    <ignore-stuck-threads>false</ignore-stuck-threads>
    </work-manager>


    I am using spring2.5.4 with weblogic 10 and jdk1.5.

    Comment


    • #3
      Hi!

      I had the same problem a couple of days ago, using WL 10.0.2 and Spring 2.5.6

      After some extensive debugging I have figured out what the problem is:
      DefaultMessageListenerContainer schedules the work while weblogic is starting up (not in a running state) whereas SimpleMessageListenerContainer schedules work when the JMS message is actually received, that is when weblogic has already started completely.

      The weblogic workmanager rejects work asynchonously from non-admin principals while in startup state. The rejection is only visible through a WorkListener because it happens at the execution callback asynchonously, not at scheduling.

      My solution is a custom WorkManagerTaskExecutor which defers the real scheduling of "Work"s until the server comes in the state RUNNING. The server state is checked using JMX.

      Send me an email if you are interested in the solution to "b dot lichtl at coco-mobile dot at".

      Regards,
      Balazs

      Comment

      Working...
      X