We Keep Coding

Is it in anyway possible to stop a REST call?

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.

Re-sending MultiPartEmail with apache commons mail

Here's my scenario:
some email sending bean gets called with a bunch of parameters needed for mail construction.
it creates MultiPartEmail and queues it for sending which is done by separate thread on the background, caller doesn't care if it was sent or not.
the delivering thread picks up queued email instance and does email.send() - so off it goes.
when delivery fails, the bean will try re-sending the mail every 5 minutes for three times and then give up.
Question:
I can't figure out how to handle #4. What I've got at hand is previously constructed MultiPartEmail instance which failed to be sent. Apparently doing email.send() again throws this:
java.lang.IllegalStateException: The MimeMessage is already built.
Is there a way to reset this illegal state so that message can be re-used. I don't really have means of creating new instance from scratch - the caller is long gone, and it will make the whole mechanism quite ugly without being able to use already built object. I think I'm missing something very simple here..

I see this is an old question, but I just hit the same problem and I found the solution.
When you create an instance of MultiPartEmail (or HtmlEmail), set its properties, and then invoke the send() method, the object will internally invoke the following methods:
buildMimeMessage()
sendMimeMessage()
It is ok to invoke sendMimeMessage() multiple times, such as a send-with-retry scenario. The problem is that buildMimeMessage() can only be invoked once. When you rely on the send() method of the base Email class, you get the exception found by the original poster.
The solution is to use the two methods I just mentioned when your Email object is a MultiPartEmail. You explicitly invoke buildMimeMessage() once, then invoke sendMimeMessage() one or more times.

Understanding #Oneway annotation in JAX-WS

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.

Java: Communicating data from one thread to another

I am working on creating a chat client based on UDP. The main structure is that there is a server where clients register and where clients can also request to form a connection with another client that is registered with the server. The clients are structures as follows using pseudo code:
public UDPClient() {
// Create datagram socket
// Execute RECEIVE thread using datagram socket above
// Execute SEND thread using datagram socket above
}
The idea is to have the send and receive executing on separate threads so I don't get blocked I/O on the receive. Both of these threads have loops within their run methods that allow you to continually send and receive messages. The problem I have is this. If a message comes in on the RECEIVE thread that changes how my SEND should be executing, how do I communicate this to the SEND thread? Do I have to shoot a datagram off to myself or can I communicate this in the code somehow?

Assuming boths threads have no reference to each other, create a third singleton class, which both read/send threads (classes) reference, that has a volatile member field to store the state data you want shared and which has synchronized access.
The volatile keyword, combined with synchronized access, guarantees that a change made to the field by one thread will be seen by another thread. Without this, changes may not be visible due to the java memory model specification.
Edited:
Following "separation of concerns" design guideline, it would be better to not have the read/send threads know about each other and to use a third class to orchestrate their activities/behaviour. Add methods to your read/send classes to stop(), start() etc and call these from the other class.
Using a separate class would also allow:
Behaviour control by other means, for example a "stop sending" button on an admin web page
Allowing multiple threads of each type, yet still having proper control through a central point, perhaps using a pool of such threads (without a separate class, you would have a many-to-many nightmare and lots of code that has nothing to do with the job at hand: ie ending and receiving)
Easier testing of your worker classes, because they do less and are more focused
porting/embedding them stand-alone for other uses

your SEND thread should have public (accesible) method (synchronized if possible) that you should be able to access from your RECEIVE thread. You could use this method to create a boolean flag, string message, etc. that you should always read before you .send(yourPacket); from your SEND thread.

Have a member variable in your READ method that your code can read from and change the SEND method based on that variable.

Handling Java Interupts

I am making an application that will work much like a real time chat. A user will be constantly writing on lets say a text area and messages will be send to other users. On the communications class I have set up a receiver. When a message from someone reaches the client, the receive method will be invoked and will get the message. What I can't understand is how the code will be executed. What happens if, while the user is typing/sending a message the receive message is invoked ? What do I need to do in order for this to work properly ?
Hope the question is clear enough.
ps : Im still in the design phase thats why I haven't tested it to see what happens.
Also atm I only use a second thread to receive messages which calls the receive method.

There should not be a problem at all.
When a message from someone reaches the client, the receive method
will be invoked and will get the message. What I can't understand is
how the code will be executed?
You should have a Receiver class that will encapsulate a socket (from which your receive data) and keep a set of listeners (see Observer pattern). A GUI can be one of the listeners. When a message is received via the socket, you need to notify all listeners by forwarding the data received. This way, you have a clean and nice way to notify the GUI about new messages arrivals.
What happens if, while the user is typing/sending a message the
receive message is invoked ?
This depends on the type of IP protocol you are using but in general your don't have to worry about this although I suggest you protect your sockets using lock mechanisms.
What do I need to do in order for this to work properly ?
Here is a nice example that can give you some inspiration :)
EDIT: As for your question regarding execution flow, sending and receiving are two different and uncorrelated operations that can happen at the same time. This can be achieved by implementing send and receive operations in two different threads. Here is an article on socket communications and multithreading.

You should either do what traditional Java EE app servers have done, which is assign a separate thread for processing each incoming message, or try a Java NIO solution along the lines of Netty.