I am new to Wso2 EI and MB. I have named a 'topic.salesOrderTopic=salesOrderTopic' in jndi properties file. And, i have configured a message store in EI having parameters as below :
<messageStore class="org.apache.synapse.message.store.impl.jms.JmsStore" name="salesOrderJmsStore" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="store.jms.destination">salesOrderJmsStore</parameter>
<parameter name="store.producer.guaranteed.delivery.enable">false</parameter>
<parameter name="store.jms.cache.connection">false</parameter>
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="connectionfactory.QueueConnectionFactory">amqp://admin:admin#clientID/carbon?brokerlist='tcp://localhost:5675'</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter> </messageStore>
I have also configured two message processor in my machine (deployed with same proxy which publishes using the above message store). I could also see two consumers in MB. Strange thing is only one processor is processing the published message. Another one is not. If i deactivate the active processor, the other processor is processing the message with no problem. Can you guys help me to understand where i am going wrong ?? I am expecting publish-subscribe model to work.
note : In MB, the salesOrderTopic is listed in both queue's list and topic list.
Related
I have an inbound endpoint configuration and I want to read the value of the coordination parameter from a file.
I can read the java.naming.provider.url value from a file with this way
<parameter name="java.naming.provider.url" key="conf:/configurations/inbound/InboundJNPURLVal"/>
I tried same structure for the coordination parameter value,
<parameter name="coordination" key="conf:/configurations/inbound/InboundCoordinationVal"/>
Although the InboundCoordinationVal file content is "false", the value of the coordination parameter was "true" in the WSO2 management console.
Is there any way to manage this value of the coordination parameter?
Thanks for any idea!
in one of my wso2 environments I have a problem with message sampling processors which from time to time stop gathering messages from queues.
We have around 60 message processors and often after environment restart or after deployment some of them just stops, and restart working after several minutes, sometimes hours. There are no errors in wso2carbon.log. Last logs about these processors are the ones that they have started :(
I think this may have something to do with some kind of a resource limit on this environment, because it only effects one environment.
Here's a sample code for message processor and it's message store.
<?xml version="1.0" encoding="UTF-8"?>
<messageProcessor
class="org.apache.synapse.message.processor.impl.sampler.SamplingProcessor"
messageStore="ms_notifyOfDocumentChangeOut_getDocument"
name="mp_notifyOfDocumentChangeOut_getDocument" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="max.delivery.drop">Disabled</parameter>
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="client.retry.interval">0</parameter>
<parameter name="interval">5000</parameter>
<parameter name="sequence">s_notifyOfDocumentChangeOut_queue_getDocument</parameter>
<parameter name="concurrency">1</parameter>
<parameter name="is.active">true</parameter>
</messageProcessor>
<?xml version="1.0" encoding="UTF-8"?>
<messageStore class="org.apache.synapse.message.store.impl.jms.JmsStore"
name="ms_notifyOfDocumentChangeOut_getDocument" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="store.producer.guaranteed.delivery.enable">false</parameter>
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="store.failover.message.store.name">ms_notifyOfDocumentChangeOut_getDocument</parameter>
<parameter name="store.jms.cache.connection">false</parameter>
<parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
<parameter name="store.jms.destination">ms_notifyOfDocumentChangeOut_getDocument</parameter>
</messageStore>
Any ideas which resources are required for it to work correctly?
I've suspected max-threads, but..
cat /proc/sys/kernel/threads-max
62735
Configuring lst_t_core, lst_t_max in jms.properties worked. Thank You Jean-Michel :)
I'm working on a project involving message stores and message forwarding processors within WSO2 ESB 4.8.1. The issue I've noticed is that in case of a problem with the endpoint specified for the processor, the message gets redelivered four times the number I set for max.delivery.attempts parameter before the processor deactivates.
The definition from this page says that the number represents the "Maximum redelivery attempts before deactivating the processor".
Here is my message processor configuration:
<messageProcessor name="msgProcessor" class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor" targetEndpoint="myEP" messageStore="messageStoreTest" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">200</parameter>
<parameter name="client.retry.interval">5000</parameter>
<parameter name="max.delivery.attempts">1</parameter>
<parameter name="message.processor.reply.sequence">main</parameter>
<parameter name="message.processor.fault.sequence">fault</parameter>
<parameter name="is.active">true</parameter>
</messageProcessor>
Anybody else noticed this? Thank you.
This seems to be a bug in the Message Processor component of the ESB, affecting the 4.9.0 version.
The JIRA issue for this is located here, with the bug being currently unresolved.
We are using WSO2 ESB and as transport we have WebSphere MQ which is accessed using JMS.
Problem is that each proxy service works in one thread with WebSphere MQ and because of that we have performance issues.
How can we start multiple instances of proxy service without deploying multiple copies of it? Maybe there are some hidden configuration parameters?
In addition to already mentioned parameter
<parameter name="transport.jms.ConcurrentConsumers">2</parameter>
you might need to add another one:
<parameter name="transport.jms.IdleTaskLimit">2147483647</parameter>
This parameter represents number of idle message read attempts per thread. When counter of such idle read attempts becomes equal to this parameter, the thread stops reading messages (if it is not the only reader).
Given that, setting this parameter to the upper limit of java int provides you with virtually infinite reading by all the threads.
You should define this parameter in your proxy conf :
<parameter name="transport.jms.ConcurrentConsumers">2</parameter>
WSO2 use one consumer by default
Have a look there : http://mmalithh.blogspot.fr/2013_05_01_archive.html
In my ESB service (v 4.6.0) error log file (wso2-esb-errors.log), have the warning:
SystemValidator Could not validate the system for configuration parameter : CPU
What is it meaning ? And how can I fix it ?
Thanks.
This can be happened due to your configuration. You can find the recommended system configuration values which are specified in ESB_HOME/repository/conf/etc/config-validation.xml file.
<Validator class="org.wso2.carbon.core.bootup.validator.SystemValidator">
<Parameter id="CPU">1024</Parameter>
<Parameter id="RAM">2048</Parameter>
<Parameter id="swap">256</Parameter>
<Parameter id="freeDisk">1024</Parameter>
<Parameter id="ulimit">1000</Parameter>
</Validator>
Are using the IBM JDK?. If so the reason could be the one reported at[1].
[1] https://wso2.org/jira/browse/CARBON-14125
During SystemValidator phase what actually happens is Carbon server check the configuration of the running system with the recommended settings on ESB_HOME/repository/conf/etc/config-validation.xml.
Since you haven't change the config file according to your case server has failed to validate CPU performance. Possible situation can be your CPU performance is below the recommended value(1024 MHz). As a fix you may need to run your ESB server on machine with recommended settings.
Thank you.