We are using Jersey 1.6 on a RESTful Server, when a request is started, but takes to long and the client timesout (can be replicated with postman and cancelling request) the request is only partially completed and some but not all database calls are done, leaving the database in a inconsistant state. I thought REST servers, always complete the calls no matter what happens to the client, but this does not seem to be true here. No exceptions are logged in our logging system, what does Jersey do to a request if the client timesout?
I thought REST servers, always complete the calls no matter what happens to the client, but this does not seem to be true here.
This is incorrect assumption. REST describes just the way of
interaction, it is still under service developer's responsibility to
make the database changes consistent(transactional) if needed.
No exceptions are logged in our logging system, what does Jersey do to a request if the client timesout?
It will still send the response, but the client will ignore it due to timeout.
Related
We have a heavy processing which we decided to put it in an asynchronous mode.
In fact, the client will do a POST request and the server will respond with an Http code OK (200) and the request id (i.e. uuid).
In order to inform the client of the processing status, there are several ways:
A bad solution: The client does a dirty check by polling on a getStatus() endpoint in order to verify the processing status, so he can retrieve results.
Nice to have solution: Using a publish/subscribe over an EAI. The client will subscribe to some notification flow type and he will be notified over the EAI by the server once processing is done. However, the EAIs such Apache Camel does more than our need. In fact, Client and server are in the same company, they will communicate using the same protocol basically HTTP, hence, no need for language/protocol transforming.
A cleaner and light solution (In my point of view): In addition to the request id rendered after the client POST request, we include a callback endpoint that the client should expose dynamically. This endpoint will be invoked once the heavy processing is done.
Question:
Have you experienced a such requirement? How did you solve it?
Are there any drawbacks to the third solution? (other than the constraint imposed to the client of being coupled to the server)
Thanks for your tips.
We have a legacy app that uses Java Web Services (JAX-WS) and runs on Glassfish 4.1.1. We want to implement compression of both the response and request. (We know that compressed requests can be a security risk but we are willing to accept this because the clients are all internal.) Turning on the GF setting for compression only compresses the response. If I send a compressed request body I get an error that indicates the SOAP message contained an invalid character, which tells me that GF did not decompress the request body.
Since GF won't automatically decompress the request I have been trying to modify the legacy app itself to do the decompression. I have tried the following:
A SOAP message handler. This does not work because the handler is invoked too late; at that point the unmarshalling of the SOAP message has already failed, because the unmarshaller received binary data.
A servlet filter. I tried setting up one that was invoked on any URL, but it never trips for the web service calls. I am not too familiar with the plumbing here, but it does not appear that the web service is implemented as a servlet.
My next option is to try setting up a proxy server that takes the raw request, unzips it, and forwards it to the web service.
Before I go down that path, does anyone have a simpler recommendations? Is what I'm try to do even possible? Much thanks in advance!
I am working on this for 3 weeks now without a real solution and I really hope you can help me out.
A bit project background:
Webapp with a JavaScript/PHP based Client sends via SocksJS and Stomp a message to a "gate"
The gate is written in Java/Spring and uses #SendTo and #MessageMapping to send and recieve messages
The messages from the gate are sent to RabbitMQ and back to the client via "messageBrokerRegistry.enableStompBrokerRelay"
So far it works, messages being sent are coming back.
Now the advanced SECURITY part:
The messages should be secured via cookies containing a user and stuff...
WebSockets themselves dont support security as far as I understood. You have to secure your webapp just like a "common" webapp with BASIC auth or some like that. So I added a servlet filter with a class extending GenericFilterBean. If the user sent the correct cookie the page loads, else he gets a 403 error.
Now comes the PROBLEM:
Due to the fact that #SendTo sends messages to all subscribers and #SendToUser seems to send it just to one session I tend to use #SendToUser. BUT there seems no way to chose a rabbitMQ queue to be created. I want some like "/myqueue-user-123". This is not possible with #SendToUser, because the generated queue is random and based on the SessionID, which I could not override.
So what I tried (and i tried LOADS of stuff besides interceptors, events and so on), is using #SendTo without a value so that the client can decide the queue it has to send to.
What I need now is to evaluate that the user from the cookie correlates with "/myqueue/user-123". And if NOT, DO NOT SEND the message to him. Stop him from subscribing. Disconnect him, whatever.
But it seems to me that you can in no way
- stop messages from being sent, just "intercept" to log them not alter
- disconnect a websocket because it automatically tries reconnecting
- throw exceptions because the subscribe suceeds anyways (events are just events, not something to interfere).
I would be really thankful for any advice or tip. Because I am totally stuck here...
I understand your pain, i spend two days trying to understand the spring security mess concerning WebSocket.
Websocket dont officially support a way to authenticate, however, spring-security does (more or less).
I would advice you to authenticate at WebSocket level, not at HTTP, most of JavaScripts library for WebSocket (and stomp) don't sends headers along with the HTTP handshake.
You'll find a detailed guide on how to authenticate at the WebSocket level here. In the above example, i used Websocket Headers values to authenticate my clients, you can put your cookie value in these headers, or replace the cookie by localstorage.
Using this method you'll have access to the Principal in your controllers, this should solve the SendToUser issue.
I've got an application on App Engine (Java) with a Cloud SQL db behind it. My mobile app connects with it via Google Cloud Endpoints.
The issue is, that when I leave an instance idle for a long time, the next time I do a request on an endpoint (even with a simple GET request in the browser/Postman in Chrome), I almost always get a 204 No Content back. The app engine logs just seems normal. However, once I shutdown the instance, and do the request again, I always get the response JSON i need.
Furthermore, once it DOES respond, it keeps responding until I leave it idle for a longer period. Then again I often get a HTTP 204.
Any advice?
Please take a look at this FAQ - https://developers.google.com/cloud-sql/faq#sometimes_slow
I am trying to consume IBM BPEL web service, which is published on a live server and consumer using core java, working fine but the code have a warning message:
Dec 10, 2013 10:18:31 AM
com.sun.xml.internal.messaging.saaj.client.p2p.HttpSOAPConnection post
WARNING: SAAJ0014: Invalid reply message. Content length of reply was
zero.
NOTE: As designed this web service does not reply anything (response is empty). How can I disable calling party SAAJ client not to expecting a reply from the web service response?
I suppose that BPEL has nothing to do with the web service part. From your message I understand that when you call the web service from your client, the response is empty. Therefore, the probable cause could be in the following points:
The specific web service function gets nothing from the business logic layer to return.
You have to debug using breakpoints to find if this is true.
The web service function gets something from the business logic layer but it returns nothing due to an error in the specific function. You have to debug using breakpoints to find if this is true. Maybe the flow control of the function has a bug. Or maybe a data serialization exception throws and gets lost.
The web service endpoint is not configured properly. Double check the web service endpoint configuration. IP, port, credentials, authorization. Perhaps the web service is configured to return nothing when an anonymous user is calling it.
The client calls another endpoint. Double check that the client executes the correct request. Try using another client (eg SOAP UI) to see if it gets the same response. If the response is not the same, then the problem is on the client side.
You have the setup and the code, so you have to find out what is going wrong.
Hope I helped!