I'm getting a Connect timeout exception when I try to run a simple mule flow:
Message : Error sending HTTP request. Payload
: {NullPayload} Payload Type : org.mule.transport.NullPayload
Element : /getunitedflightsFlow/processors/0 #
getunitedflights:getunitedflights.xml:15 (Get Flights Requests)
Element XML :
Root Exception stack trace: java.net.ConnectException: Connect timeout
at
org.glassfish.grizzly.connectionpool.SingleEndpointPool$ConnectCompletionHandler.cancelled(SingleEndpointPool.java:1284)
at
org.glassfish.grizzly.impl.SafeFutureImpl.notifyCompletionHandlers(SafeFutureImpl.java:185)
at
org.glassfish.grizzly.impl.SafeFutureImpl.done(SafeFutureImpl.java:277)
at
org.glassfish.grizzly.impl.SafeFutureImpl$Sync.innerCancel(SafeFutureImpl.java:389)
at
org.glassfish.grizzly.impl.SafeFutureImpl.cancel(SafeFutureImpl.java:247)
at
org.glassfish.grizzly.connectionpool.SingleEndpointPool$ConnectTimeoutWorker.doWork(SingleEndpointPool.java:1352)
at
org.glassfish.grizzly.connectionpool.SingleEndpointPool$ConnectTimeoutWorker.doWork(SingleEndpointPool.java:1344)
at
org.glassfish.grizzly.utils.DelayedExecutor$DelayedRunnable.run(DelayedExecutor.java:158)
at
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at
org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:748)
Here is the Mule flow:
<flow name="getunitedflightsFlow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/home" doc:name="HTTP"/>
<http:request config-ref="HTTP_Request_Configuration" path="/essentials/united/flights" method="GET" doc:name="Get Flights Requests"/>
</flow>
I did some googling and it looks like a proxy/firewall issue, I tried adding the proxy settings under preferences and all Native/Direct/Manual options won't work. I also added the following properties/args:
-XX:PermSize=128M -XX:MaxPermSize=256M -Dhttps.proxyHost=proxy.xxxx.com -Dhttps.proxyPort=8080 -Dhttps.proxyUsername=myfirst.mylast -Dhttps.proxyPassword=xxxxxxxxx
it doesn't work, also tried changing the proxy settings in the Http request connector itself but this doesn't work either.
Does anyone know what's going on here,
your help is appreciated!
Related
If backend system(REST API) is not closed the connection when they send the response payload as response then how can we close the connection intentionally from mule side(http request) ?
actually we found that backend system is not closing the connection so that mule is throwing 'Remotely Closed' error.
Could anyone suggest how to close the connection in Mule side(HTTP Request connector) after JUST receiving response from backend ?
And below is the HTTP configuration :
<http:request-config name="HTTP_Request_configuration" doc:name="HTTP Request configuration" doc:id="bed9482f-2a7c-4db5-91b5-6410fac08f8e" >
<http:request-connection host="test.com" port="81" /> </http:request-config>
<http:request method="POST" doc:name="Request" doc:id="823ec599-3f8d-4ffa-ba03-72f33f0bc1b8" config-ref="HTTP_Request_configuration" path="/">
</http:request>
I am trying to pass the multiple URI params in the http request as follows:
<http:listener-config name="HTTP_Listener_Configuration"
host="localhost" port="8081" doc:name="HTTP Listener Configuration"
connectionIdleTimeout="40000" />
<http:request-config name="HTTP_Request_Configuration1" protocol="HTTPS" host="" port="443" doc:name="HTTP Request Configuration" connectionIdleTimeout="300000" responseTimeout="50000">
<http:basic-authentication username="user" password="123"/>
</http:request-config>
<flow name="testFlow">
<http:listener config-ref="HTTP_Listener_Configuration"
path="/paypal" allowedMethods="GET" doc:name="HTTP" />
<set-variable variableName="config" value="#[{'p1':'3054', 'p2':'child/Lines'}]" doc:name="Variable"/>
<http:request config-ref="HTTP_Request_Configuration1" path="/resources/shipment/{p1}/{p2}" method="GET" doc:name="HTTP">
<http:request-builder>
<http:uri-params expression="#[flowVars.config]"/>
</http:request-builder>
</http:request>
</flow>
But this is giving me error as below:
Response code 404 mapped as failure.
ERROR 2019-01-04 18:46:34,526
[[paypaltest].HTTP_Listener_Configuration.worker.01]
org.mule.exception.DefaultMessagingExceptionStrategy:
********************************************************************************
Message : Response code 404 mapped as failure.
Payload : org.glassfish.grizzly.utils.BufferInputStream#b473ec2
Element : /testFlow/processors/1 # test:test.xml:29 (HTTP)
Element XML : <http:request config-ref="HTTP_Request_Configuration1" path="/resources/shipments/{p1}/{p2}" method="GET" doc:name="HTTP">
<http:request-builder>
<http:uri-params expression="#[flowVars.config]"></http:uri-params>
</http:request-builder>
</http:request>
--------------------------------------------------------------------------------
Root Exception stack trace:
org.mule.module.http.internal.request.ResponseValidatorException: Response code 404 mapped as failure.
Please let me know if any help can be provide!
It means that the url doesn't exist. Try to hit the url directly in postman before implementing in Mule. Since you wiped out the host="", I'll pretend it's example.com. My guess is that it's having an issue with p2. If you'd like to send the actual string, you'll need to URL encode the "/", which is %2F
So to test hit https://www.example.com/resources/shipments/3054/child%2FLines, with the Basic Auth for Authorization.
Postman: https://www.getpostman.com/apps
The issue i faced was unique to me, i tried this REST api call from SOAPUI and there it gave me the same error i.e. 404 not found so i compared it with POSTMAN request and found that Authorization header was the missing piece for this.
After adding this to http header it worked perfectly.
Please refer
https://docs.mulesoft.com/connectors/http/http-authentication
here are two solutions :
1. Add preemptive="true" in basic authentication configuration
The pre-emptive option passes the user name and password without waiting for a prompt from the server.
Add Authorization in the http:header value ="Basic dXNlcjoxMjM="
I have to use a Mule Requester Inside MUnit test case to read a file under src/test/resources so that i can assert the payload . With the current implementation I have Ftp connector inside MUnits xml which I am referring from mule requester . I clearly see that mule requester is trying to access the connector even before it it initialized . Is there any way i can tell mule to early intialize ftp connector ?
Exception :
********************************************************************************
Message : Cannot perform an action on a connector when it is not started. Connector "no-delete-file-connector-test" is currently in lifecycle phase "initialise"
Element : /no-delete-file-connector-test # app:haz001-test-suite.xml:33 (File)
--------------------------------------------------------------------------------
Exception stack is:
Cannot perform an action on a connector when it is not started. Connector "no-delete-file-connector-test" is currently in lifecycle phase "initialise" (org.mule.api.lifecycle.LifecycleException)
org.mule.transport.AbstractConnector.getRequester(AbstractConnector.java:1178)
org.mule.transport.AbstractConnector.request(AbstractConnector.java:2269)
org.mule.transport.file.FileConnector$$EnhancerByCGLIB$$d6c65eff.CGLIB$request$75(<generated>:-1)
(97 more...)
(set debug level logging or '-Dmule.verbose.exceptions=true' for everything)
********************************************************************************
Following is my configuration :
<flow-ref name="processMainFlow" doc:name="processMainFlow" />
<mulerequester:request resource="file://src/test/resources/expected-discrete.csv?connector=no-delete-file-connector-test" doc:name="Mule Requester" returnClass="java.lang.String"/>
<munit:assert-payload-equals expectedValue="#[flowVars.outputCSV]" doc:name="Assert Payload"/>
<logger message="response for test #[payload] actual data : #[flowVars.outputCSV]" level="INFO"
doc:name="Logger" />
To load a file in your Munit test, you don't need the file connector, use a Set Payload or Set Message, eg:
<set-payload value="#[getResource('expected-discrete.csv').asStream()]" doc:name="Set Payload"/>
The path inside getResource is relative to testResources specified in your pom file (defaults to src/test/munit and src/test/resources).
The file connector is stopped because that is the default behaviour of connectors in Munit tests. There is more info about this in the Mulesoft forums: https://forums.mulesoft.com/questions/44649/munit-config-mock-inbounds-mock-connectors.html
Try to mock the component instead of calling it. If mocked it can avoid this error since FTP requires initiation which is not possible in munit.
I use the new HTTP Connector as mentioned in the online documentation:
<http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081"/>
<flow name="test_flow">
<http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="NEW HTTP Connector"/>
<...>
</flow>
Yet, when deploying in DEV on Cloudhub, I still get the message:
HTTP transport is deprecated and will be removed in Mule 4.0. Use HTTP
module instead.
I'm not sure what to look for. Is this a known issue?
While deploying to mule cloudhub, please change the host in listener config from local host to the default All interfaces [0.0.0.0].
Change your HTTP Connector to use "0.0.0.0" instead of your CloudHub domain name and redeploy.
I have a Mule application that is calling an external API over HTTPS using the <http:request connector. When I build and deploy my application locally, the call works fine. When I make a Postman call to the same external API using the exact same payload my Mule app sends, the call works fine. However, when I deploy the Mule app to Cloudhub and make the request - I get a 400 response from the external API.
Here's my flow:
<http:request-config name="mambuRequestConfiguration" protocol="HTTPS" doc:name="HTTP Request Configuration">
<http:basic-authentication username="${mambu.username}" password="${mambu.password}" preemptive="true" />
<tls:context>
<tls:key-store type="jks" path="keystore.jks" alias="${keystore.alias}" keyPassword="${keystore.keypassword}" password="${keystore.password}" />
</tls:context>
</http:request-config>
<flow name="createClientDepositAccount">
<dw:transform-message metadata:id="412fd434-12bb-47a3-9605-9bfc1d9fec46" doc:name="Transform Message">
<dw:set-payload><![CDATA[%dw 1.0
%output application/json
---
{
savingsAccount: {
accountHolderKey: payload.clientKey,
accountHolderType: "CLIENT",
productTypeKey: payload.productKey,
name: payload.clientProductName,
accountType: payload.accountType,
accountState: payload.accountState,
interestRate: payload.interestRate
}
}]]></dw:set-payload>
</dw:transform-message>
<http:request config-ref="mambuRequestConfiguration" path="${mambu.deposit.path}" method="POST" host="${mambu.host}" port="${mambu.port}" doc:name="Mambu: Create Client Deposit Account">
<http:success-status-code-validator values="0..599"/>
</http:request>
<dw:transform-message metadata:id="49f1231f-485f-433c-82c4-3d83856ac442" doc:name="Transform Message">
<dw:set-payload><![CDATA[%dw 1.0
%output application/json
---
{
message: "Account created successfully",
key: payload.savingsAccount.encodedKey
}]]></dw:set-payload>
</dw:transform-message>
</flow>
The external service I'm calling is Mambu, a cloud banking platform. I have a number of other flows in my application all making GET requests to various other Mambu APIs - all work fine (all GET requests are also over HTTPS). The response I'm getting from Mambu is a 400 with the payload:
{"returnCode":3,"returnStatus":"INVALID_API_OPERATION"}
Relevant links to the Mambu documentation are here and here.
I'm unable to replicate the behaviour I'm seeing in Cloudhub on my local instance. The only thing that differs about this call to the others I'm making is that it's a POST request.
In most cases this error is related to the API auto-discovery being improperly configured or corrupt. If API auto-discovery is configured on the Mule application, the best solution is to remove the setting from the Mule application, check if the error is resolved by starting the process again, then reconfigure the auto-discovery.
Bizarrely, the resolution to this was "turn it off and on again" as suggested on a question I posted on the Mulesoft forum. I simply deleted the app from Cloudhub and redeployed it and everything worked as expected. Very strange issue within Cloudhub by the looks of things. Hopefully Mulesoft will resolve...