Per the javadoc:
Indicates that the given #WebMethod has only an input message and no output. Typically, a oneway method returns the thread of control to the calling application prior to executing the actual business method. A 181 processor should report an error if an operation marked #Oneway has a return value or Holder parameters, or declares any checked exceptions.
Can I assume then, that if I need exception handling (checked or unchecked) that this annotation is not recommended ? I don't return anything from the business logic, however I still have an interest in being aware of timeouts and other various errors specific to act of calling a SOAP method. Does this annotation mean I don't have access to HTTP return codes or thrown exceptions ?
Question: Am I better off threading this out on my own to get a truly asynchronous call, and removing the #Oneway annotation ?
#Oneway means nothing will ever escape your method, neither response nor exception. This is for two reasons:
technically exception is just another type of response (SOAP fault), thus it cannot be returned from a one-way method (which can't return anything)
often one-way methods are executed asynchronously by the web service framework (I know apache-cxf odes that). The framework returns immediately, so your customer might have received an empty response even before the handling of one-way method even started. When the exception is thrown, the original HTTP connection is long gone.
So if you want to propagate exceptions or timeouts, use standard SOAP method with empty response* and few faults declared explicitly. If you want to timeout your call after some time, you'll need separate thread pool and blocking waiting for response gor a given period of time.
* please do not confuse empty SOAP response (an XML document with no content, just root tag, wrapped in a SOAP envelope) with empty HTTP response (nothing was sent back). Remember that SOAP is not limited to HTTP. For example if you use JMS or e-mail transport, empty response (or fault) of ordinary two-way function is yet another message being sent from server to client. one-way method is just one reauest message and nothing sent back.
Related
How could the PUT method be idempotent but not safe? Can someone explain it out?
HTTP Method Idempotent Safe
OPTIONS yes yes
GET yes yes
HEAD yes yes
PUT yes no
POST no no
DELETE yes no
PATCH no no
Safe method doesn't change anything internally (resources)
Safe methods are methods that can be cached, prefetched without any repercussions to the resource.
Idempotent method doesn't change anything externally (response)
idempotent HTTP method is a HTTP method that can be called many times without different outcomes.
It's all in the specification:
4.2.2. Idempotent Methods
A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the same
as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods
are idempotent.
Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement
other non-idempotent side effects for each idempotent request.
Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a client
sends a PUT request and the underlying connection is closed before any
response is received, then the client can establish a new connection
and retry the idempotent request. It knows that repeating the request
will have the same intended effect, even if the original request
succeeded, though the response might differ.
(https://greenbytes.de/tech/webdav/rfc7231.html#idempotent.methods)
I was reading JMS 2.0 specs and it is mentioned that (below relevant excerpt) if client tries modify the Message object then JMS provider may throw an exception.
My question is how a JMS provider would know if client is trying to modify the Message object, because Message object would be transmitted over the wire and at JMS provider end it is not the same heap object so even if client modifies that Message object, JMS provider has no way to detect the change.
Am I missing something?
7.3.9. Restrictions on the use of the Message object
Applications which perform an asynchronous send must take account of the
restriction that a Message object is designed to be accessed by one
logical thread of control at a time and does not support concurrent
use. See section 2.14 “Multi-threading”.
After the send method has
returned, the application must not attempt to read the headers,
properties or body of the Message object until the
CompletionListener’s onCompletion or onException method has been
called. This is because the JMS provider may be modifying the Message
object in another thread during this time.
A JMS provider may throw a
JMSException if the application attempts to access or modify the
Message object after the send method has returned and before the
CompletionListener has been invoked. If the JMS provider does not
throw an exception then the behaviour is undefined.
This excerpt is referring to the JMS client implementation as the JMS Provider here and it is telling you that once you call send using the asynchronous API you no longer control the Message until such time as the asynchronous completion is notified either with a success or fail event.
The client will often times use an internal "read-only" flag on the send call to tag that the message is now not to be touched by the client code and will reset the read-only state back to read / write after the send call completes one way or another.
This text is referrent to your provider's implementation of the JMS Message object. When received from the JMS consumer, this message usually has a read-only flag turned on, also to make improved performance possible, that will be checked in the implementation of 'Message' when you use methods that would modify the message. For example TextMessage.setText() would throw an Unmodifiable exception
From Javascript, I am calling a REST method which is computationally intensive. Would it be possible to stop that REST call, if you are no longer interested in what it returns.
I understand, it is possible to abort a request in JS. But it won't stop the thread which gets triggered due to the REST call. This is how I am aborting the ajax call in JS.
Abort Ajax requests using jQuery
The REST interface is written in Java. And internally this thread may create multiple threads also.
I would like to stop a Java thread. But from the caller. From JS, where I have triggered it.
How to properly stop the Thread in Java?
As Chris mentioned in the comments above, REST calls should be quick, definitely not an hour long. If the server needs to do a lot of work which takes considerably amount of time, you should modify your design to async. Either provide a callback that the server will use once it's done (also called push approach), or pull every few minutes, by sending a new request to the server to see if it's done.
In order to implement it you'll need the server to return a unique-id for each request in order to be able to identify in the callback/check-call what's the status of that specific request.
The unique-id should be implemented on the server-side in order to avoid two clients send the same ID - overriding each other.
In the link that I posted above you can see an example of how to implement a "stop thread" mechanism which can be implemented on the server-side and called by the client whenever is needed.
You could send a unique identifier along with your request, and then make another request that instructs the server to abort the operation started for that ID.
I am trying to work out if javax.websocket.Endpoint.onError (and thus the resulting methods in say Spring) can be called during a call to any of the websocket send methods (e.g. javax.websocket.RemoteEndpoint.Async.sendText or thin wrappers in say Spring), at least for the specific javax.websocket.Session, since if it can I need to make sure my server implementation regarding state associated with that socket is re-entrant, which complicates it.
The method is documented here:
https://javaee-spec.java.net/nonav/javadocs/javax/websocket/Endpoint.html#onError%28javax.websocket.Session,%20java.lang.Throwable%29
It only mentions errors regarding incoming data. So I think it is safe to say the send will never itself cause it to be called (rather than passing an Exception to the send handler, or throwing an IOException from the basic remotes), but is incoming data processed while a send is in progress, and can that result in the method being called (presumably from another thread, threading details seem a bit thin as well...).
I wanna build server socket emulator, but I want implement some design pattern there.
I will described my case study that I have simplified like these:
My Server Socket will always listen client socket. While some request message come from the client socket, the server emulator will response the client through the socket.
the response is response code. '00' will describe request message processed successfully, and another response code expect '00' will describe there are some error while processing the message request.
IN the server there are some UI, this UI contain check response parameter such as.
response code
timeout interval
While the server want to response the client message,
the response code taken from input parameter response form UI
check the timeout interval, it will create sleep thread and the interval taken from timeout interval input from UI.
I have implement the function, but I create it in one class. I feel it so sucks.
Can you suggest me what class / interface that I must create to refactor my code.
The need to refactor the code really depends on what task your server is performing based on the client request. If it is something simple then a single class may very well be the best design. If it is doing something more complicated then you may want to move the various operations that can be performed to various service classes. If your results are standard you could create an object (maybe enum?) to describe them.
This is the approach I have taken in one of my own applications. The server handles essentially only the IO between itself and the client. When the client sends a message the server parses it into a standard format "operation" object. This object is then passed to manager object which finds an appropriate "request servicing object". This object then does the actual work. When it is finished it generates a return object that describes the status/ results of the object. This is then taken by the server and formatted in an appropriate manner to send across the wire to the client.
Hopefully this can give you some ideas as to what might be appropriate for your application.