I want to proxy RemoteUserStoreManagerService (exposed on WSO2 IS) over WSO2 ESB.
When I call getUserClaimValuesForClaims operation I get the response. I tested the WSO2 IS (connected to my Active Directory) for performance. I sent requests in 100 threads (each thread with 250ms delay) and it gave me an average response of 250ms (which is ok for me).
So I proxied the getUserClaimValuesForClaims operation using the Transformation proxy and it also worked. But during the performace testing (with the same or smaller load) I have got following errors and not all the messages have returned (on average 1 of 100 messages).
[2014-01-06 19:28:21,047] INFO - LogMediator To: http://www.w3.org/2005/08/addressing/anonymous, WSAction: , SOAPAction: , MessageID: urn:uuid:d2b85c03-beaf-409b-bf39-2e8143bd9e0b, Direction: response
[2014-01-06 19:28:38,441] ERROR - SourceHandler I/O error: An established connection was aborted by the software in your host machine
java.io.IOException: An established connection was aborted by the software in your host machine
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:202)
at sun.nio.ch.IOUtil.read(IOUtil.java:175)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:243)
at org.apache.http.nio.reactor.ssl.SSLIOSession.receiveEncryptedData(SSLIOSession.java:348)
at org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:376)
at org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady
[2014-01-06 19:29:14,051] WARN - TargetHandler http-outgoing-66: Connection time out while in state: REQUEST_DONE
[2014-01-06 19:29:14,061] WARN - EndpointContext Endpoint : AnonymousEndpoint will be marked SUSPENDED as it failed
[2014-01-06 19:29:15,041] WARN - EndpointContext Suspending endpoint : AnonymousEndpoint - last suspend duration was : 30000ms and current suspend duration is : 30000ms - Next retry after : Mon
[2014-01-06 19:29:14,451] WARN - SourceHandler Connection time out after request is read: http-incoming-57
I thing that it says, it timeouts on backend; but I get the response logged in faultSeuence.
I noticed that the problem is caused by the XSLT mediator in proxy implementation, because when I removed the xslt mediators the log is empty. I tried xquery and it was the same. Even the log mediator in outSequence causes this issues.
Here is my final Proxy.
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="GetUserProxy" transports="https http" startOnLoad="true" trace="disable">
<target>
<endpoint>
<address uri="https://localhost:9443/services/RemoteUserStoreManagerService.RemoteUserStoreManagerServiceHttpsSoap12Endpoint/"/>
</endpoint>
<inSequence/>
<outSequence>
<log/>
<send/>
</outSequence>
<faultSequence/>
</target>
</proxy>
When I remove the log mediator, the WARN messages disapears from log and ALL response messages are returned to SoapUI.
Could anybody tell me why it behaves this way?
Thank you very much.
David
RemoteUserStoreManagerService is an admin service. Therefore, you need to send Identity Server's user name/password in a basic authentication header or session cookie. I can not see setting of authorization headers in your proxy configuration such as following
<property expression="fn:concat('Basic ', base64Encode('username:password'))" name="Authorization" scope="transport"></property>
More details would be here. Also you need to create a message body to send to the "RemoteUserStoreManagerService" and read the response messages. These must be implemented using ESB configuration. However, you can write an custom ESB mediator to do this also. Sample java code to call this service can be found here. You can find the detail on writing custom mediator from here
We have figured out, that the problem is probably more general and doesn't relate only to WSO2 IS, because we have the same problem when similating the WSO2 IS service as SoapUI mock.
The problem is probably in HTTP-passthru transport in axis configuration, because when we switched to HTTP-NIO the problem disapears and it is even faster.
There is a post about performance tunnig that helped us.
Howevever, I would like to know what transport we should use in production or where the problem is. Because now it seems that we cannot use HTTP-passthru transport for production environment.
Is anyone experiencing this problem?
what are the versions of ESB and IS your working with..?
try to restart the ESB and call the Service again. Do remember call to Identity server is a secure call.
Related
I'm trying to write a SFTP location through a jms/http proxy. However when there is an error on SFTP endpoint (wrong password, network connectivity issue, remote Dir not exists) I want to trigger fault sequence and handle this error (Try some DLC kind of scenario). I found that fault Sequcence is not invoking for FTP errors unless you set OUT_ONLY=false. However WSO2 docs recommends set OUT_ONLY=true for ftp writes. Similar Question is asked here too. How to handle VFS proxy error in WSO2 EI 6.4?
If I set OUT_ONLY=false it triggers faultSquence for both failures and success FTP writes.
Any workaround to catch FTP errors and trigger faultSequence ?
You can define a responseAction in the endpoint configuration. Please refer to the following sample configuration. The responseAction spedifies when a response comes to a timed out request specifies whether to discard it or invoke the fault handler. Apart from defining the responseAction in the endpoint, you can replace the send mediator with the file connector and it will also invoke the fault sequence during an error.
<send>
<endpoint name="wms-fault-endpoint">
<address uri="vfs:ftp://admin:admin1#localhost:2121/testJ/out">
<timeout>
<duration>10000</duration>
<responseAction>fault</responseAction>
</timeout>
</address>
</endpoint>
</send>
[1]-https://docs.wso2.com/display/EI611/Endpoint+Error+Handling
[2]- https://docs.wso2.com/display/ESBCONNECTORS/File+Connector
We are getting below exception with Kafka 2.11 and wso2 esb 6.2 with sasl enabled. SASL mechanism in wso2 esb and Kafka clsuter is PALIN but randmoly seeing Error 2 in logs.
Does anybody experienced this error and any help is appreciated.
Error 1:
java.util.concurrent.ExecutionException: org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for TESTTOPIC: 30051 ms has passed since batch creation plus linger time
Error 2:
[2019-11-02 01:36:50,265] ERROR - [Producer clientId=producer-4526] Connection to node -1 failed authentication due to: Unexpected handshake request with client mechanism PLAIN, enabled mechanisms are [GSSAPI] {org.apache.kafka.clients.NetworkClient}
Based on the Second Error Message *Unexpected handshake request with client mechanism PLAIN, enabled mechanisms are [GSSAPI]*, it would seem that the saslMechanism has not been configured properly on the ESB side. It is configured to GSSAPI Kerberos by default.
I would recommend getting the latest version of the Kafka Connector. You can find the documentation and the relevant links here
One such example of a PLAIN configuration with the Kafka Connector would be :
<kafkaTransport.init>
<bootstrapServers>localhost:9092</bootstrapServers>
<keySerializerClass>org.apache.kafka.common.serialization.StringSerializer</keySerializerClass>
<valueSerializerClass>org.apache.kafka.common.serialization.StringSerializer</valueSerializerClass>
<securityProtocol> SASL_PLAINTEXT </securityProtocol>
<saslMechanism> PLAIN </saslMechanism>
<saslJaasConfig>org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="12345"</saslJaasConfig>
<maxPoolSize>100</maxPoolSize>
</kafkaTransport.init>
This is the relevant configuration required to make use of the Kafka Connector. The Security Protocol can be configured to SASL_SSL as well.
Here is one such proxy configuration
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="KafkaTransport"
startOnLoad="true"
statistics="disable"
trace="disable"
transports="http,https">
<target>
<inSequence>
<kafkaTransport.init>
<bootstrapServers>localhost:9092</bootstrapServers>
<keySerializerClass>org.apache.kafka.common.serialization.StringSerializer</keySerializerClass>
<valueSerializerClass>org.apache.kafka.common.serialization.StringSerializer</valueSerializerClass>
<securityProtocol>SASL_SSL</securityProtocol>
<saslMechanism>PLAIN</saslMechanism>
<sslKeystoreLocation>/Users/Ibaqu/kafka.client.keystore.jks</sslKeystoreLocation>
<sslKeystorePassword>admin123</sslKeystorePassword>
<sslTruststoreLocation>/Users/Ibaqu/kafka.client.trustore.jks</sslTruststoreLocation>
<sslTruststorePassword>admin123</sslTruststorePassword>
<saslJaasConfig>org.apache.kafka.common.security.plain.PlainLoginModule required username="admin" password="12345";</saslJaasConfig>
<maxPoolSize>100</maxPoolSize>
</kafkaTransport.init>
<kafkaTransport.publishMessages>
<topic>test</topic>
</kafkaTransport.publishMessages>
</inSequence>
</target>
<description/>
</proxy>
You can give this particular proxy a try to test your connection.
I want to cache the response in my proxy and when i hit my proxy again then it should get me the cached data. I have tried using Cache mediator but am unable to find if my data is really getting cached or not.So basically what i am trying to achieve is if i have data in cache then it shouldn't hit the endpoint.It should send the response from cache. Looking forward to your answer. Thanks in advance
I have my service code as:
public class GetMirrorValue {
public String getValue(String data) throws Exception {
System.out.println("Inside Service code");
return data;
}
}
my inSequence is:
<sequence xmlns="http://ws.apache.org/ns/synapse" name="CheckCacheSeq">
<cache scope="per-host" collector="false" hashGenerator="org.wso2.caching.digest.DOMHASHGenerator" timeout="20">
<implementation type="memory" maxSize="100"/>
</cache>
<send>
<endpoint key="DummyEP"/>
</send>
</sequence>
and my out sequence is:
<outSequence xmlns="http://ws.apache.org/ns/synapse">
<cache scope="per-host" collector="true"/>
<send/>
</outSequence>
but whenever i hit my proxy service consecutively through try-it tool, i get data from service but not from cache coz every time in my server System.out.println("Inside Service code"); gets printed?
You can modify your backend service (The endpoint invoked by proxy service), to print something in the server log, once a request got hit. First request should hit the backend. Then within the cached period, requests won't go to the backend service. It will go to backend service only after cache is expired. So looking at the print on the backend server log, you can observe the caching behavior.
http://docs.wso2.org/wiki/display/ESB460/Sample+420%3A+Simple+Cache+Implemented+on+ESB+for+the+Actual+Service
You can enable wirelogs in ESB to see the requests/responses going through ESB.
As near as I can tell, the WSO2 ESB does not properly handle proxying a service operation that does not return a response message.
Here's the scenario:
We've got a code-first, axis2 generated web service sitting on WSO2 application server 4.1.0.
The java class that the service is based on has some methods like:
public void updateMyObject(MyObject obj) throws MyServiceException
Axis2 generates a WSDL that does not contain a response message, so this is essentially one-way.
NB: An axis2 generated client stub operating against this operation works fine. When invoking the stub in client code, the client blocks until the operation is successfully processed by the server. If an error occurs on the server, then the custom fault is raised and an exception is thrown on the client side.
But, we want to make this invocation via the ESB. Setting up a simple, basic proxy server will not work. When invoking the service via the ESB, the client code blocks indefinitely even though the remote service was successfully invoked.
I read somewhere that this can be fixed by adding the following to my inSequence:
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
This does the trick in the case that the remote service successfully processes the response. The client code no longer blocks.
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error.
This is no doubt because there is no call-back handler registered for the operation because of the OUT_ONLY setting. Search for OUT_ONLY in the link below for more info:
http://techfeast-hiranya.blogspot.ca/2009/12/wso2-esb-tips-tricks-03-transport.html
The FORCE_SC_ACCEPTED setting seems to be the thing that will keep the client from blocking on the success condition, presumably because that forces a 202 http response to the client so it stops waiting for a response.
Since the client operates as it should against the service for both success and error conditions but I am unable to configure a proxy service that yields the same behavior, in my opinion, the ESB is deficient in this way and that is a bug.
Of course, if there is a way I can configure it so that it does what I want, then I'd love to hear it.
But as near as I can tell, I think not registering a call-back is the wrong thing to do here, even if there is no response. I do not wish to implement a fire and forget here. Executions should still happen synchronously from the client side. My client is expecting an HTTP 200 response but with no body for success.
By examining the WSDL, the ESB should realize that the service has no response message but still register a call back. When the 200 OK is received on success, it should propagate this back to the client and unregister the call-back. When a Fault occurs, it should also relay that back to the client.
So, is there a way to accomplish what I want with the ESB or is it deficient in this way?
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error
What is happening to your client if you define a fault sequence for your proxy in this case?
If we register a call-back fro an outonly operation, what will happen is ESB will wait forever for the response and will run out of threads..
In oneway message;
If it is a successcase use these two properties;
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
For a failure case handle that in the fault sequence. I would like to know, what is happens in the fault scenario.
We are using WSO2 ESB 4.0.3 with Data services feature on MAC OSX 10.7.4.
I have proxy service which forwards the message to Data Service. When there is any fault in Data service the fault is returned to calling proxy service in OUTSEQUENCE. Now if there is any error I forward this to common error handler from proxy service which happens in OUTSEQUENCE. This common error handler is another proxy service only.
Now when the Error handling is completed the control returns back to original proxy service which called the error handling proxy service. But what happens is when the control returns to original proxy service from error handler it AGAIN starts executing the OUTSEQUENCE of proxy service.
So for me it is executing the OUTSEQUENCE of proxy service twice in case of fault from Data Service.
Is it standard behavior? I used to Java kind of executing where when the call from method returns it starts executing the next line. But here looks like it again starts executing the OUTSEQUENCE from beginning.
To avert executing the OUTSEQUENCE from beginning again I populate the value at "transport" scope in Error hanlder proxy which will used in filter mediator to avoid executing the logic in OUTSEQUENCE twice.
I am trying to find if there are any SOAP headers I can use instead of setting the property. I see no SOAP headers being set like "From" or "ReplyTo" and I believe message co-ordination happens with MessageId. How can we use these SOAP headers instead of property to divert the flow logic.
Please help.
thanks
Abhijit
In this case instead of using send mediator to invoke the web service you can use the call out mediator. Which makes a blocking call to error handling service and returns to the same place.
And also with esb 4.0.3 you can specify the receive sequence at the send mediator level. By default the response is received at the outsequence level.
eg. <send receive="fundTransferSequence">
<endpoint>
<address encoding="UTF-8" statistics="disable"
uri="http://10.1.23.11:8888/EgateValidWS/EgateValidWSSoapHttpPort" >
</address>
</endpoint>
</send>