I'm working on a small java app that requests json data from an open online db, and I've run into the problem that the first URL has no issues having its stream opened (doesn't matter which URL I start with), but as soon as I try to use a second one I get "javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure".
I can't seem to find anything mentioning this on the internet, which seems kinda weird to me, so I wanted to actually ask how to do this properly, because I use Jackson to handle the incoming Json data, and while it has a method to just handle URLs, all that does is call openStream() which causes this problem. I'm using Java 11 for the record.
EDIT: Also forgot to mention it's a JavaFX application, if that could possibly be an issue
Thanks to #dave_thompson_085, I found out that it was an issue with Java 11.0.1 specifically, updating (to 11.0.11 in my case) solved the problem
Related
we are having problems downloading a file from a remote server. We have a very high chance of getting a connection reset exception, although the same code works fine with other files we download from different servers.
We already tried using BufferedInputStream, but had the same problem there. That's why we switched to FileUtils copyURLToFile() method in hope that this will be a bit more robust. But that didn't improve the problem.
It seems like browsers don't have a problem downloading the file (at least it worked every time we tried), we just have the problem in Java (or Lucee using Java to be precise). Lucee's (and Railo's before that) built in functions had the same problem, that's why we started using Java in the first place. So far with no success.
Are there any ways to make this download more robust?
We also have little to no influence on the server that hosts the file, so ideally we should fix the problem on our side.
Thanks a lot!
I am trying to elaborate SIP messages coming to an Asterisk server and edit them on the fly using Java.
AMI is supposed to work fine with that. Although I can't send any SIP messages though the socket, cause every-time I tried to edit chan_sip.c the server breaks down. So I haven't find a way to access this information from other classes of the manager. I don't want to save those information to a file or database cause this will delay the whole process.
Using Kamailio is not an option cause I want to make a comparison of both solutions so I need Asterisk.
Is there any path I should follow to get this done? I can't figure why editing chan_sip.c bothers Asterisk making him nonfunctional..
Seams like no way with your qualification. Task seams really complex for me(i have more then 10 years experience, including asteirsk internal and c/c++ programming).Try do that using dialplan only
I have tried searching for this strange issue I am facing but could not find anything on web.
Following is what I am trying to do.
Upload File from User browser to Play server running on some different environment
Following is the issue I am facing.
The chunk is getting truncated before reaching to Play server
Observations:
Chunk is created at client side properly from java script and websocket.send() is passing proper chunk to Play.
On Play server, the chunk is coming as a String event object which is truncated.
Very strange thing about this problem is This is happening only from some machines/networks, for all others it is working fine
When tried with different chunk size, it has been observed that for smaller chunks many of initial chunks gets received properly and later one fails
We have tried bypassing Firewalls and Proxies as well on some network to check what happens if there are no such restrictions, but it is still failing
Please give your inputs which can help me debug this and fix this. Any additional things you want I can provide, not pasting code as it is working on majority of machines and networks but failing on a few, so it does not seem to be a code issue
PS. This question can have many answers based on people's views, to all SO users, I just need help on what could be the thing which can go wrong, so please do not flag this as inappropriate
I have figured it out, the issue was with latest update of google chrome. I downloaded the chrome from here (Version 37) and it started working fine.
I came to know after a period of time that this issue was because of the implementation changes in chrome V38 for multiple frames for single message, initially it was getting transferred in a single frame so ultimately the implementation from your server side also need to be changed in order to handling the same.
I was using older version of Play framework which wasn't having this multiple frame handling implementation so it was breaking.
After updating Play to 2.2.3 it started working properly as they have implemented multiframe handling in that version. Some useful links below
Issue With Latest Chrome
Play Changelog
Changes for Continuation frame handling for WebSockets in Play 2.2.3
Basically i am trying to create a websocket based live chat for a few websites i work on.
the server i have up and working no bother running on the javax.websocket package on a glassfish server.
the standard HTML5 websocket interface i also have working no bother.
the problem is that about 10-20% or our users dont use an HTML5 compatible browser so i need a fallback. Do far the best option i can find seems to be running a swf as a middle man between the websocket server and HTML. The problem there being that action script doesnt support websockets as standard so im having to write my own wrapper.
So far i can connect to the server and perform a successful handshake, i can also receive messages from the server with no issues, the problem is sending messages.
I have had a look through https://www.rfc-editor.org/rfc/rfc6455#section-5.2 at the theory of the data frame for a websocket package and written an attempt at this, i have also looked through various other open source library's without any luck. What happens is whenever i send a message to the server i get a response of
RSV bit(s) incorrectly set.
and then the connection closes (as it should with the websocket protocol).
A large part of the problem i suspect is that this is the first time i have ever even looked at action script never mind attempted using it.
i was just wondering if anyone else had been having this problem/response and preferably has found a solution
in an idea world im looking for a tutorial that i could use to actually understand the creation of the frame better but i cant seem to find one :P
thanks
Matt
As it turns out it was just one of those bizarre bugs that happened for basically no reaseon, i ended up re-writing the section of code that manages the creation of websocket frames and frame fragmentation and it just worked.
ive had a few programmers look the the two examples of code including an action script developer and none of them can work out why the one snippet works and the other doesnt.
On the upside going back over the process has given me a better understanding of the protocol. If there is anyone else that has been having a similar problem feel free to get in touch and i will see if i can help you out.
I've been trying to find workarounds to this for nearly 6 straight hours now but to no avail.
I have a simple HttpUnit program that does some sign in to a website. The problem is that I'm getting this error when I finally submit the log in form:
Exception in thread "main" java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:223)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
at com.meterware.httpunit.WebResponse.readFromStream(WebResponse.java:967)
..and so on..
It appears a bug in the way JDK was managing the gzip file was reported back in 2002 (!). It appears Java still has this bug and the only workaround is to tell HttpUnit to not accept gzip encoded data, like so:
WebConversation.getClientProperties().setAcceptGzip(false);
Unfortuantely this I cannot do. For the sign in to be successful, I need to have gzip enabled, otherwise I'm just redirected to the generic home page (without being signed in).
I suspect the only way to make this work would be to change the source code of HttpUnit and handle the EOF excpetion in it's gzip parsing. I desperately need help. Does anyone have a solution to this?
If not, then could you suggest some equivalently simple API in Java, such as HttpUnit, for tasks such as filling forms and signing in.
I suspect the only way to make this work would be to change the source
code of HttpUnit and handle the EOF excpetion in it's gzip parsing.
This is often a solution for developers when there are bugs in third party libraries. If you know what the problem is in HttpUnit, why not fix it locally? You can even push the fix back to the project and hope they adopt it.
If not, then could you suggest some equivalently simple API in Java, such as HttpUnit, for tasks such as filling forms and signing in.
If you mean a library to traverse websites, there are plenty. If you want a "headless" HTTP client, try Apache HttpComponents HttpClient. If you want something that actually uses a browser, try Selenium.
It seems this problem was fixed in HttpUnit 1.7 (I was using 1.6).
Anyways, I'm shifting to HttpComponents as suggested by #ShaggyFrog since now I'm running into bigger, unknown problems with cookies and sessions.
Edit: It seems HttpComponents was overly complicated. At one point I had to manually handle Http 302 redirects. So I decided to shift to HtmlUnit, which is extremely similar to HttpUnit but without any cookie or gzip problems. Worked like a charm.