Is there a way to isolate HTTP connections to prevent the following behavior when using the Fluent API from apache httpclient?
I have some junit tests that use the Fluent API to do Gets and Posts.
When I run the junit tests individually I get the expected results.
Test1: Request.Post(https://host:port/xxx") HTTP 200
Test2: Request.Get(https://host:port/yyy") HTTP 200
When I run the junit tests as part of my test suite I get incorrect results.
Test1: Request.Post(https://host:port/xxx") HTTP 200
Test2: Request.Get(https://host:port/yyy") HTTP 404
To fix this I used the HttpClient with an executor for each route.
HttpClientBuilder httpClientBuilder = HttpClientBuilder.create();
Executor xxxExecutor = Executor.newInstance(httpClientBuilder.build());
Executor yyyExecutor = Executor.newInstance(httpClientBuilder.build());
xxxExecutor.execute(Request.Post(https://host:port/xxx"))...
yyyExecutor.execute(Request.Get(https://host:port/yyy"))...
Related
I have an example here: https://github.com/JoeCordingley/spray-marshallersExample where if you run the service then hit localhost:8080 with either application/json or application/myJson in the running service it returns the correct contentType but testing the route using spray testkit it always returns application/json. Am I using the testkit incorrectly or is there a fault in spray testkit?
I am trying to send the mail through jmeter for failed http request, I want to know the sampler details like name of http request?
I have added if controller to check the assertion of previously running request sand send a mail if it fails.It gives me error message
"Message from Jmeter thread # Test failed: code expected to match /200/"
But I want to know the name of http request which has been failed so i can know specifically which request is failing?
You can use JSR223 PreProcessor to get the previous sampler details using the following code:
def sampler = ctx.getPreviousSampler()
Example usage:
def previousSamplerName = ctx.getPreviousSampler().getName()
log.info("Failed sampler name: " + previousSamplerName)
vars.put("SamplerName", previousSamplerName)
Demo:
If everything goes fine you will be able to access previous sampler name as ${SamplerName} in the SMTP Request sampler
ctx is a shorthand to JMeterContext class instance, see the JavaDoc for available methods and fields
vars is a shorthand to JMeterVariables class instance, it provides read/write access to all JMeter Variables in scope.
Also check out Groovy Is the New Black guide to get familiarized with using Groovy in JMeter tests.
Given:
client <-- HTTP --> spray web service <-- HTTP --> other web service
The client receives the following HTTP status code and entity body when hitting the spray web service:
504 Gateway Timeout - Empty
Per this answer, my understanding is that the spray web service is not receiving a timely response from the other web service, and thus sending an HTTP 504 to the client.
Assuming that's reasonable, per https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/StatusCode.scala#L158, I'm guessing that one of these server config values is responsible for the 504 in the spray web service's HTTP response to the client.
What config or implicit would cause the spray web service to reply with a 504 to the client?
I think you are using the default Spray timeouts and perhaps you will need to increase them. If this is the case, there are 2 values you will have to configure to increase the timeouts.
idle-timeout: Time you can have an idle connection to your server before it is disconnected (default 60s).
request-timeout: Time a request from your client (from your server to another) can be idle before it timesout (default 20s).
The first value must be always higher than the second, as the idle-timeout will make pointless the connections from your request client.
So just overwrite your configuration in your application.conf like this:
spray.can {
server {
idle-timeout = 120 s
request-timeout = 20 s
}
}
I am trying to run my JSF project using Apache tomee-1.7.1-plume, JSF 2.1 in netbeans 8.0.2 but its not running with the following error. I don't know what is the problem> thanks in advance for help.
Server returned HTTP response code: 400 for URL: http://localhost:8080/manager/text/deploy?config=file%3A%2FC%3A%2FUsers%2FWindows%2FAppData%2FLocal%2FTemp%2Fcontext7091578542594637291.xml&path=/test
C:\Users\Windows\Documents\NetBeansProjects\test\nbproject\build-impl.xml:1050: The module has not been deployed.
See the server log for details.
BUILD FAILED (total time: 42 seconds)
I have deployed on SMX the following route that proxies all ReST request to the real ReST service provider (Tomcat). All ReST calls to SMX routed successfully however a saveDocument service that uploads PDF files fail.
public void configure() throws Exception {
from("jetty:http://{{smx.host}}:{{smx.rest-proxy-port}}/{{smx.context}}matchOnUriPrefix=true")
.log("ReST call received (Java DSL)")
.to("jetty:http://{{real-server-address}}:{{real-ws-port}}/{{context}}?bridgeEndpoint=true&throwExceptionOnFailure=false")
.log("Rest call proxied (Java DSL)");
}
The following exception is logged in servicemix.log.
19:53:57,065 | WARN | HttpClient-137 | HttpExchange | 111 - org.eclipse.jetty.util - 7.5.4.v20111024 | EXCEPTION JettyContentExchange#188af650=POST//real-server-address...:8080/contextpath.../saveDocument#SENDING(3ms)->
EXCEPTED(0ms)sent=3ms java.lang.IndexOutOfBoundsException
Do I have to perform some additional processing on the base64 before redirect the call to the real ReST service?
UPDATE on my previous post.
This seems to work when I use txt file but fails for pdf or doc.
UPDATE 2: It also fails when txt size exceeds 7KB.
Is it possible to set camel jetty to accept big size files?
This can be solved if Multipart WS is used.
I have implemented a Multipart CXF ReST file upload service for testing the route in case of a multipart WS.
The following route works OK for multipart:
from("jetty:http://.../?matchOnUriPrefix=true&enableMultipartFilter=false")
.noStreamCaching()
.log("Service Proxied")
.to("jetty:http://...:../?bridgeEndpoint=true&throwExceptionOnFailure=false");
Still cannot find what is going wrong with the first WS.
The issue is tracked here also.