We have spring-boot Rest service working for fine for last couple of month. We are packaging default jar file with embedded tomcat engine. New problem has started, where it echo back every other request.
Request 1 Verb POST- get valid response back
request 2 POST- response is echo of request 2!
Request 3 POST- get valid response
Request 4 POST - gets echo....
How to resolve this issue?
we tried rebuilding jar, deploying to multiple machine, with and without hardware load balancer.
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
I am creating a web API that returns JSON. Currently I am able to call the endpoint with jquery and php curl but I am not able to do so using JSP HttpsURLConnection.
It gives me a handshake_failure exception. Is there anyway that this can be solved without having to install a file in the jsp server ? I am doing a REST service so it doesn't make sense for all my users to install a file to call it.
Will this also affect the calling ?
we have created one api to export patient details in csv file, this export request takes 2.5 min to execute.
we are using below technology for this app: Scala, akka, nginx and react/node js as front end.
when i will hit on export link, request got executed and able to see in logs.
but immediately after 30sec got error on browser console GET /export/request 503 (service unavailable ) with java script error in promise block.
after refering akka documentation i have increased ideal-timeout setting to 240s.
application.conf
http {
server {
request-timeout: 240s
idle-timeout: 240s
}
}
and it works on my local/development env. /export/ request was executed in 2 min.
after deploying this change at TEST env. issue is still there getting 503 after 30 sec.
on TEST env. application is running with docker env.
request flow/application setup:
Internal AWS load balancer => EC2 instance => nginx proxy (listing :80) => front end app (react js app) => backend (scala and akka)
i have not found any configuration key which has set to 30s.
Could you please help me with this ?
Many thanks
It seems your problem is on any intermediary proxy. You can perform your request with curl and check the response header Server:
curl -v -s -o /dev/null your_hostname/export/request
If it were akka you'd see a line as follows:
< Server: akka-http/10.2.4
Hopefully you can get more insights on your issue with this technique
I am using jbpm version 6.5.0. I have requirement to call process through REST API and I am successful to start process with parameters.
I am testing it with postman. The thing is that there is also requirement of document attachments on starting by REST API, for that I have followed link (https://access.redhat.com/solutions/2567701 ) but unsuccessful to attach document in same process. The REST API URI provided in followed link is
http://server:port/kie-server/services/rest/server/containers/{containerName}/processes/{processId}/instances this is not working . I am stuck with containerName in the link .
Secondly, I have confusion i.e. there are 2 uri which starts process on is for sending parameters on RESTAPI and other is for document attachment RESTAPI. Will both of the REST API called by the application which want to start process .
I have check following to check containerName but unsuccessful.
http://localhost:8080/kie-server/services/rest/server/containers running successfully with out containers list
http://localhost:8080/kie-server/services/rest/server running successfully
http://localhost:8080/kie-server/services/rest/server/containers/%7Bid%7D Failure with msg Container id is not instantiated
Kindly provide me solution or steps any tutorial which have clear steps to achieve the task .
I am not sure whether it is too late to answer now. Here it is anyway.
For the classic employee evaluation process example of jBPM documentation, the HTTP request to create a process instance looks like the following. "evaluation_1.0" is the process container id and "evaluation" is the process id/name.
POST /kie-server/services/rest/server/containers/evaluation_1.0/processes/evaluation/instances HTTP/1.1
Host: localhost:8080
Authorization: Basic {basic auth token}
Content-Type: application/json
Content-Length: 43
{"initiator": "<jbpm user name>", "employee":"<employee name>"}
`
I've created a simple web service using JRuby 1.7.4, Sinatra 1.4.4 and Rack 1.5.2. This web service responds to GET, POST, PATCH and DELETE requests with a simple message "Hello world using [request-type]".
I started Rack and tested all the request types. All four worked.
I used Warbler to create a war file of the application and deployed it to Tomcat 7.0.47. When I tested with Tomcat PATCH failed with a "HTTP Status 501 - Method PATCH is not is not implemented by this servlet for this URI". (Yes, 'is not' is repeated. But this is the response I get from Tomcat.) GET, POST and DELETE worked fine.
I then tried using Jetty 9.1.0. Same result. GET, POST and DELETE work but PATCH fails.
Why are PATCH requests failing and how do I get them to work with this set up?
According to Tomcat documentation HttpServlet can handle only GET, POST, PUT, DELETE requests
public abstract class HttpServlet
extends GenericServlet
Provides an abstract class to be subclassed to create an HTTP servlet
suitable for a Web site. A subclass of HttpServlet must override at
least one method, usually one of these:
doGet, if the servlet supports HTTP GET requests doPost, for HTTP POST
requests doPut, for HTTP PUT requests doDelete, for HTTP DELETE
requests
But you can find this useful:
If you use an HTTP library that doesn't allow overriding or setting an
arbitrary HTTP method name, you can send a POST request and provide an
override to the HTTP method via the query string parameter
_HttpMethod.
For example, to update an Account, this will work with an actual POST request:
.../services/data/v23.0/sobjects/Account/0016000000eEhmxAAC?_HttpMethod=PATCH