low performance with lingo and activemq

[nefilim]

I sent a similar message to the ActiveMQ list but got no responses.

I'm using Lingo 1.3 with an embedded Activemq 4.1.1 (using the intra vm transport) one the server and a client on a separate physical machine.

I have these options set on the connection factory:

        <bean id="jmsFactory" class="org.apache.activemq.ActiveMQConnectionFactory" >
                <property name="brokerURL" value="vm:(broker:(${callback.jms.brokerUrl})?persistent=false&brokerName=callbackBroker&useJmx=true)?marshal=false"/>
                <property name="useAsyncSend" value="true"/>
                <property name="useSyncSend" value="false"/>
                <property name="alwaysSessionAsync" value="true"/>
                <property name="objectMessageSerializationDefered" value="true"/>
                <property name="optimizeAcknowledge" value="true"/>
                <property name="optimizedMessageDispatch" value="true"/>

Messages (non persistent) gets sent intra VM to temp queue A, which the remote client then consumes. A message (persistent) also gets sent from temp queue B back to temp queue A (not entirely sure on why this happens, this is what I see using the JMX console - this is supposed to one way async remote invocation).  

The problem appears to be related to getting messages into queue A, I can see the queue enqueue count lagging the the amount of messages being sent. I have a queue in Java in front of it and I can see a backlog starting to build in there. This threshold appears to be around 100 messages / sec, it cannot submit  messages any quicker than that.

Looking through the Lingo source one possible cause I see is that the messages that gets sent when a callback is called is sent with MultiplexRequestor.request() which appears to block for a timeout period until a response message is received. request() instead of send() is chosen since the metadata for the method indicates oneWay is false. The method in question is void and throws no exceptions, the metadata.oneway never gets evaluated since the SimpleMetadataStrategy in the JmsProxyFactoryBean(JmsClientInterceptor) was constructed with oneWayForVoidMethods left at the default false. I don't know where this JmsProxyFactoryBean gets constructed, as I've supplied it a custom metadataStrategy and invocationFactory with proper metadataStrategy in the configuration:

    <bean id="callbackRegistryServiceListener" class="org.logicblaze.lingo.jms.JmsServiceExporterMessageListener">
        <property name="service" ref="callbackService"/>
        <property name="serviceInterface" value="CallbackService"/>
        <property name="connectionFactory" ref="jmsFactory"/>
        <property name="persistentDelivery" value="false"/>
        <property name="invocationFactory" ref="invocationFactory"/>
        <property name="metadataStrategy" ref="metadataStrategy" />
    </bean>

    <bean id="callbackService"
        class="org.logicblaze.lingo.jms.JmsProxyFactoryBean">
        <property name="serviceInterface"
            value="CallbackService" />
        <property name="connectionFactory" ref="jmsFactory" />
        <property name="destination" ref="callbackDestination" />
        <property name="marshaller" ref="clientLingoMarshaller" />
        <property name="remoteInvocationFactory" ref="invocationFactory"/>
        <property name="metadataStrategy" ref="metadataStrategy" />
    </bean>

The code in JmsServiceExporterMessageListener looks suspicious, not sure why it creates the factory instead of getting it from Spring:

    protected Object createRemoteProxy(Message message, Class parameterType, Object argument) throws JMSException {
        JmsProxyFactoryBean factory = new JmsProxyFactoryBean();

it neglects to copy over the metadataStrategy, so I added it:

        log.info("Setting metdataStrategy to [" + metadataStrategy + "] which has oneway [" + ((SimpleMetadataStrategy)metadataStrategy).isOneWayForVoidMethods() + "]");
        factory.setMetadataStrategy(metadataStrategy);

I could see that callbacks now gets treated as one way messages and the submission is much faster, my backlog queue in Java never grows, in other words messages gets submitted as fast as they come in.

Now I see a problem with the consumers, the dequeue count is lagging the enqueue count and the activemq temp queue size is growing. That's another matter...

So in conclusion, does anyone know if not copying the metadatastrategy when creating the new JmsProxyFactoryBean is an oversight? Is it ok for callback methods to be treated as oneway methods (if they meet the criteria of course) ?

Thanks
Peter



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email