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 :)
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!
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.
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.
I am getting a connection timed out when I try to invoke from a WS client a method from a CXF Web service I have deployed. Both are using custom interceptors, and the service is overloaded due to multiple invocations.
Caused by: java.net.ConnectException: ConnectException invoking http://xxx.xx.xx.xx:12005/myservice/repository?wsdl: Connection timed out
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1338)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1322)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:622)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 36 more
I tried multiple solutions to disabled the timeout or to increase it but all failed.
First, I tried to create a CXF configuration file like the following:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd">
<http-conf:conduit name="*.http-conduit">
<http-conf:client CacheControl="no-cache"
ConnectionTimeout="0" ReceiveTimeout="0" AllowChunking="false" />
</http-conf:conduit>
</beans>
Then, I forced my application to load it by using the Java system property -Dcxf.config.file=/home/test/resources/cxf.xml
In the logs I can see that the configuration is read and thus probably applied
INFO: Loaded configuration file /home/test/resources/cxf.xml.
Unfortunately the connection timed out still occurs.
The second solution I tried consists of setting the policy programmatically on all the clients by using the following piece of code:
public static void setHTTPPolicy(Client client) {
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(0);
httpClientPolicy.setReceiveTimeout(0);
httpClientPolicy.setAsyncExecuteTimeout(0);
http.setClient(httpClientPolicy);
}
but again the connection timeout occurs.
Do I miss something? Is there some other timeouts to configure? any help is welcome.
CXF allows you to configure threadpooling for your webservice endpoint. This way, you can cater for timeouts occurring as a result of scarce request processing resources. Below is a sample config using the <jaxws:endpoint/> option in cxf:
<jaxws:endpoint id="serviceBean" implementor="#referenceToServiceBeanDefinition" address="/MyEndpointAddress">
<jaxws:executor>
<bean id="threadPool" class="java.util.concurrent.ThreadPoolExecutor">
<!-- Minimum number of waiting threads in the pool -->
<constructor-arg index="0" value="2"/>
<!-- Maximum number of working threads in the pool -->
<constructor-arg index="1" value="5"/>
<!-- Maximum wait time for a thread to complete execution -->
<constructor-arg index="2" value="400000"/>
<!-- Unit of wait time -->
<constructor-arg index="3" value="#{T(java.util.concurrent.TimeUnit).MILLISECONDS}"/>
<!-- Storage data structure for waiting thread tasks -->
<constructor-arg index="4" ref="taskQueue"/>
</bean>
</jaxws:executor>
</jaxws:endpoint>
<!-- Basic data structure to temporarily hold waiting tasks-->
<bean id="taskQueue" class="java.util.concurrent.LinkedBlockingQueue"/>
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.