I am trying to setup very simple WSO2 ESB Proxy service. While using it, I am getting HTTP 202 response back and WSO2 ESB is not doing anything with the request beside logging it. Here is the background of my setup
My service implementation is using SOAP 1.2 over Http 1.1. When my client opens the connection to the server, it fires first request and asks for keep-alive connection. The ESB passes the request to the actual implementation and sends response back with transfer-encoding as chunked. So far it works as desired.
After the initial request response exchange, my client submits several requests in parallel and I get HTTP 202 responses for all of them. Looking at logs, it seems ESB is not sending the request to the actual implementation ever.
Is there something that I am doing wrong? How do I fix it?
What happens in this scenario is that your subsequent requests are hitting the main sequence of the WSO2 ESB. That is why you can only see a log for those requests. As you have already narrowed down this happens due to the jsessionId attached to the URL. To overcome this issue you can create a REST API with URL pattern to match the correct URL path. Please refer the following documentation.
https://docs.wso2.com/display/ESB481/Creating+APIs
Related
So I am deploying a web service developed using gsoap using mod_gsoap. I wanted to set SOAP_IO_KEEPALIVE and SOAP_IO_CHUNK modes of the soap context object to accept chunked requests. How do I achieve this?
Or is there any other way to accept chunked requests? Right now the server responds as soon as it receives the first chunk without waiting for the rest.
The documentation says:
Warning
Do not use any of the SOAP_IO flags to initialize or set the
context, such as SOAP_IO_KEEPALIVE and SOAP_IO_CHUNK.
The Apache server controls the connection settings and HTTP payload parameters to send and receive HTTP requests. Data is received with ap_get_client_block, which de-chunks the content when chunked.
I have a BPS process that rapidly performs a lot of calls to an ESB proxy. The ESB proxy calls an ESB API, which calls the API of our own product.
Often, the BPS process pauses for exactly 3 minutes while waiting for a response from the ESB. After the 3 minutes, everything continues as if nothing happened. Using Wireshark and some additional Log mediators, I have discovered the following:
The hanging occurs in the ESB proxy, right before the out sequence.
According to Wireshark, the ESB API has already sent its response to the ESB proxy when the hanging occurs.
The fact that this hanging takes exactly 3 minutes should be a hint. I searched the config files for anything specifying 180 seconds, but the only ones are the http socket timeouts and the http transportReceiver's threadKeepAliveTime. If I reduce those, the BPS throws a p2p communication error instead of continuing. To me, this indicates that something somewhere in the background is still causing a 3 minute delay for some calls.
By the way, the hanging does not occur for some specific calls only. I have been testing several times, performing the exact same calls each time, and I cannot predict which call will hang or even if any call will hang at all.
I would suggest you add at least a <send /> mediator in your faultSequence.
Perhaps also add a simple makefault mediator (don't make it too complex just yet - just a static error response will do - at this stage you don't want faults originating within the faultSequence)
I suspect some error from the backend service or in the out sequence or maybe even faultSequence is not being handled - which means instead of sending a response back to your caller, the proxy hangs until time out instead
PS: It really helps if you post the source code of your proxy too
I had the same experience sometimes ago when I tried to call PUT or POST methods without a request body. But, by default, WSO2 ESB expects a message body to send the request to backend server when the http method is POST or PUT.
I had to either send the request with a request body (at least an empty JSON: {}) or use the property FORCE_POST_PUT_NOBODY in your APIs.
Read this post for more details on how to use FORCE_POST_PUT_NOBODY property.
If you enable the wire log in WSO2 you will realize NGIX is using HTTP 1.0 client in the request.
In order to fix that change your NGINX mapping to use "proxy_http_version 1.1;" and the problem will be sorted.
Cheers.
I ended up getting WSO2 support involved in this. Apparently, I was hitting some very rare edge case which was very hard for the WSO2 engineers to reproduce.
In the end, the fix turned out to be adding the following property just before the send mediator in the proxy service:
<property name="NO_KEEPALIVE" value="true" scope="axis2"/>
I'm trying to do some load testing on the WSO2 ESB, and I have a SOAP message with a large payload that I'd like to send (10+MB, sometimes reaching 50 inbound, and sometimes even 300 outbound).
I'm using curl to send the messages, first to the backend SOPAUI service. This goes through fine. However when I send the message via a proxy service on the ESB, curl fails to finish uploading the file, and gets slower and slower as the upload progresses. The logs from the ESB do not seem to be reporting anything useful.
I have set the timeout on this to 20 minutes, and it still does not complete. Turning on MTOM has no effect, and I am using a simple passthrough proxy. The proxy service functions fine with small message sizes.
What else can I look into to get this working? If it is indeed possible.
You could try to configure Message Relay
in repository/conf/axis2.xml, you configure :
org.wso2.carbon.relay.BinaryRelayBuilder as the messageBuilder's class associated with your contentType (text/xml for exemple if soap11 of application/soap+xml with soap12)
org.wso2.carbon.relay.ExpandingMessageFormatter as the messageFormatter's class
Have a look there : https://docs.wso2.com/display/ESB481/Message+Relay
Turned out I had to switch to using the NHTTP transport rather than the Passthrough transport, thanks to this question here for prompting looking into this: WSO2 ESB unknown error code 102511
Requires an edit in carbon.xml, detailed in the accepted answer from the link above.
So currently I managed to reach an existant Web Service and use one of it's functions to alter a database.
However, the Web Service does not respond with a Soap Response, but with just the HTTP Respond Code 200, which I want to use to create a "Success!"-like notification.
Using BusinessWorks I was able to to connect the process with a HTTP Receiver in the Modeler-View, but it doesn't work and gives me the error message
"Process configuration error. The activity [HTTPReceiver] in the process [webservices.module.IWSContract] cannot have an input transition."
My goal is to catch the HTTP Response Code 200 from the Web Service, and optionally display it to the user.
As you mention you use TIBCO BW 6. this should be the "Invoke" activity instead of SOAPRequestreply (Basic Palette -> Invoke)
You need to use a SOAP Request-Reply activity to invoke the web service. Technically, the "HTTP 200" response won't be visible but you will get an empty output in case of a success:
You can then choose to return whatever success message to the user.
We are trying to log all http requests made to our Tomcat server, in particular SOAP requests.
Our server setup is as follows:
Tomcat 7.0.11
Axis 2
Gentoo Linux
So far we have used the RequestDumperFilter class however this only shows us the header information.
What we require is the ability to view the request body containing the SOAP request XML.
I guess you could make use of some request processing components but I'm not sure if there is an easy way to view the request body in Tomcat.
From what I know, the ExtendedAccessLogValve provides the most information about the request but even this is missing the body.
The most simple solution would be to move the logging away from Tomcat and use a proxy server. You place the proxy between the server and it's clients and do the logging in the proxy.
Proxy receives request, logs it, then forwards to Tomcat which generates response, sends it to the proxy which logs it and then sends it to client. The simplest proxy I used (and did its job pretty well) was the Apache TCP Monitor.
Additionally you could look at something like Fiddler and see if that helps.