I use SSLEngines together with NIO to provide nonblocking SSL connections to my application. At some point during the handshake (probably after receiving ServerHelloDone) the SSLEngine requires me to process a delegated task.
So I call getDelegatedTask and call it's run method. The task itself calls X509ExtendedKeyManager.getCertificateChain, which in turn throws an NullPointerException. That exception is caught by the Handshaker and stored for later reporting.
However reporting works by calling the private checkTaskThrown method that is only called when a message was received or a message is to be sent.
But without getCertificateChain to complete correctly, there is nothing to send and the other side sends nothing as well, so there is nothing to receive. Hence the exception stays hidden.
As no side proceeds, we have a livelock.
And I found no way to prevent or detect that, except for
Using reflection to call checkTaskThrown
Use some task / timer for a timeout
Neither of which is the route I want to go...
When the task completes you should retry the operation that returned NEED_TASK.
You need to find and fix the NPE in your KeyManager.
Related
I currently try to call a bunch of webservices in parallel. In the end I want to evaluate all the responses. Therefore I use Promise.sequence. Unfortunately the whole method fails if one of the web calls failed. I would be satisfied if I just get the response of the succeeded calls.
Is there some way to perform the Promise.sequence and just retrieve the succeeded calls? After that it would be nice to handle the failed calls in any separate way.
I found a solution for now. For each Promise i create via ws.url("http://...").get() i define a recover method, e.g.
ws.url(theUrl).get().recover((t) -> null)
So when these Promises are processed via Promise.sequence no error is thrown (because it was already catched by the recover of the particular WS call promise).
Later on I just have to check if a result is null and then drop it from further processing.
I'm programming in java and am using XML-RPC to submit data from a client to a server. My problem is that when I XmlRpcClient.execute code but whenever I have a connection error, the application gets stuck until I eventually get a Timeout exception (which I want). I placed this whole process in a new thread and wanted the ability to stop/cancel the process if I didn't want to wait for the timeout.
I learned how to stop Threads but idk if I can interrupt the XmlRpcClient.execute code.
any ideas?
The default execute method is, by nature, synchronous, that is, blocking.
If you are using Jakarta Commons HttpClient, you could set the socket timeout to a shorter value (the default is 0 meaning no timeout) with the transport's setConnectionTimeout method.
I believe, though, that the proper handling would be to use the executeAsync method and providing a callback to it in order to continue.
Hi guys am getting following error am using Websocket and Tomcat8.
java.lang.IllegalStateException: The remote endpoint was in state [TEXT_FULL_WRITING] which is an invalid state for called method
at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1092)
at org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.textStart(WsRemoteEndpointImplBase.java:1055)
at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:186)
at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37)
at com.iri.monitor.webSocket.IRIMonitorSocketServlet.broadcastData(IRIMonitorSocketServlet.java:369)
at com.iri.monitor.webSocket.IRIMonitorSocketServlet.access$0(IRIMonitorSocketServlet.java:356)
at com.iri.monitor.webSocket.IRIMonitorSocketServlet$5.run(IRIMonitorSocketServlet.java:279)
You are trying to write to a websocket that is not in a ready state. The websocket is currently in writing mode and you are trying to write another message to that websocket which raises an error. Using an async write or as not such good practice a sleep can prevent this from happening. This error is also normally raised when a websocket program is not thread safe.
Neither async or sleep can help.
The key problem is the send-method can not be called concurrently.
So it's just about concurrency, you can use locks or some other thing. Here is how I handle it.
In fact, I write a actor to wrap the socketSession. It will produce an event when the send-method is called. Each actor will be registered in an Looper which contains a work thread and an event queue. Meanwhile the work thread keeps sending message.
So, I will use the sync-send method inside, the actor model will make sure about the concurrency.
The key problem now is about the number of Looper. You know, you can't make neither too much or too few threads. But you can still estimate a number by your business cases, and keep adjusting it.
it is actually not a concurrency issue, you will have the same error in a single-threaded environment. It is about asynchronous calls that must not overlap.
You should use session.get**Basic**Remote().sendText instead of session.get**Async**Remote().sendText() to avoid this problem. Should not be an issue as long as the amount of data you are writing stays reasonable small.
I am writing an application in Java to make calls and view when people are in calls, their phone is ringing or are idle, using the library Jain-Sip and at the moment am trying to correctly implement presence with SUBSCRIBE and NOTIFY messages. I am able to get presence data to be received, but after a while the presence data stops being displayed by my program.
I believe this is because the overridden method "processRequest" is not being called. This is the earliest point in the program where NOTIFY messages are being handled and not even the print statements are being output.
The bizarre thing about this is that the notify messages are being sent when I make calls, and the presence data is there. I know this because I have done Wireshark traces when running the program.
Note: No exceptions are occurring during execution of the program, to cause erroneous behaviour.
If anybody has any insight into why this is happening, I would be very grateful.
Thanks a lot,
Adam
Make sure you add your listener class correctly. The only other possible cause would be if the NOTIFY is unsolicited, which should not be the case but it happens. Try to enable this flag gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY. See more about it here https://jsip.ci.cloudbees.com/job/jsip/javadoc/gov/nist/javax/sip/SipStackImpl.html
Otherwise you will need to attach DEBUG logs to figure it out, could be malformed request or something of the sort.
While the Servlet 3.0 spec has request.startAsync() and asyncContext.start(),
why has it not provided a asyncContext.stop() or asyncContext.cancel() to initiate necessary clean-up on the server-side ?
Pls view this in the context of this other question to understand where I am coming from.
One HTTP request starts the Async processing and returns a
.../outstandingRequests/requestId link to the client.
Another HTTP request calls DELETE on that link to cancel the request
In this case, if I had a way to clean-up the server-side (servlet container stuff like AsyncListeners), instead of having to call asyncContext.complete() which will probably try and send a response back to the client, it will make sense. Doesnt it ?
In this scenario, call 1 is still hanging there, waiting for its response when call 2 comes in and wants to kill it. In this scenario, why would you not want to call complete() on call 1, thus finishing that call so that client stops waiting? You would probably want to set the status code to something other than 200 in this type of situation, but complete seems too be the best option given any scenario because it returns control back to the original caller and performs any request related cleanup work.
When a timeout happens, which is an error, the container calls complete (with a non-200 response code I imagine). The scenario you describe is similar to a timeout (albeit a forced timeout), so why not do the same thing the container does. Just call something like this before calling complete:
ac.getResponse().setStatus(500);
Any maybe write something to the output stream describing what caused this error.