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
Related
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.
We have recently added a Silverlight based plugin (Plupload) that works great except for one issue:
If you try to use it in Chrome your browser will popup with the message "Silverlight was blocked because it is out of date".
I appreciate Google trying to force users to update (which they otherwise never ever do) but this has single handedly tripled our customer support load. Does anybody know of a way to force it to run in Chrome via Javascript/Html code?
We have seen the same issue with many sites using Java applets. As Oracle constantly has minor updates it seems near impossible to stay "up to date" so effectively you asked to upgrade 9/10 times.
To clarify: There are several problems I'm facing here, the most annoying of which is that my app engine logs appear very late in the admin console. I think that they may be related, which is why I'm grouping them together.
I was testing my app after uploading to Google App Engine about two hours ago, and I was tweaking the code and re-deploying. I use the Eclipse plugin and it says deployed successfully. I did not change the version number at first, and apparently all my changes were not being reflected on the server at all. I found out because my logs showed the old build number.
At this point in time, my logs were being updated real-time, and I could see logs from requests that took place seconds ago.
Anyway, I figured that I needed to change version numbers, so I did that and re-deployed, and made the new version default. After this my logs remained empty, even though I was testing my app continuously. And none of the logs of any of the versions showed the latest requests.
I checked my logs about half an hour back, and now it shows me the logs for the requests I was making then. Any requests I made at that point in time didn't show either - apparently I'll have to wait another hour for them to show.
Am I doing something wrong, or is there something about the App Engine mechanism I don't understand?
This sounds odd, I know. And I couldn't find anything about it on Google.
Problem 1: Described above.
Problem 2: Do I need to change version numbers anytime I make even a tiny change?
Problem 3: When I make changes to a servlet while testing on the local dev server, it takes approximately 3-4 minutes to reflect those changes when I test the app, even if I stop and restart the server. JSP changes reflect immediately.
I see the same behavior: On the initial deployment of an app, log messages seemed to appear real-time, but after a couple of days and lots of deployments, I see delays of up to 30 minutes. Known issue, apparently: http://code.google.com/p/googleappengine/issues/detail?id=3338.
Not required. After deployment, changed code without changes to the version number is immediately available on AppEngine.
Item 3 sounds like a browser caching issue. Does a forced reload (ctrl-shift-r on firefox) refresh your stale servlet pages?
I have problems in production mode. While developing my application I am using development mode and while testing everything is working right. When I compile my application to deploy on server there are some features that does not work. For example I have problems with some ComboBox or not all textfields save it state to database, or data is not populated to tables. It seems like not all code was compiled for production mode and I do not know why.I do not have any errors in logs on server. Probably it is some problem with cross-compilation. Of course when I switch back to development mode, everything is working.
I am using ExtGWT(GXT) with Spring.
Any one had similar problem?
Thanks for help.
In some schenario's it happens. Especially when you work with regex it works well in hosted mode and not in compiled mode.
1) Have you debugged the values coming in the client side service layer? All the values are appearing?
2) After compilation while testing are you sure that you have latest javascript downloaded into your browser? Sometimes due to browser cache you may have old code.
Can you please try find the place where the data is exactly missing? If you are sure the problem is happening from gxt side then you can post your queries in gxt forum.
I'm trying to implement a Cometd/Bayeux server on Android using iJetty. The Jetty implementation itself works just fine serving static pages along with servlets. I am trying to up the ante a bit and create a Bayeux application on the phone but I'm having some trouble. I can hit the page that has the dojo cometd scripts on it, but I am unable to subscribe to the channel. When I view firebug/chome developer tools, I see a series of posts/gets that last a couple of milliseconds (~14). However, when I run a cometd application on a normal machine, the posts/gets last several seconds (~14 seconds) before timing out and reopening the connection. This second scenario makes sense to me with my understanding of how continuation in HTTP works. So I'm thinking that something is not allowing those connections to hang open and prematurely returning a value and consequently closing the connection. I would post my source but I'm not sure what to post short of posting everything...(it is open source though so if you want to have a look it's at http://webtext-android.googlecode.com).
So my question is, does anybody think that there could be some underlying limitation imposed by the Android system that is preventing these servlets from working? Are there assumptions that are made by the Jetty Bayeux implementation with regards to the underlying system? Or is it more likely that somehow I have a bad implementation of the ContinuationCometdServelt? I should note that all of the posts/gets from the client return 200 OK messages so I'm not inclined to think that the Android system is simply terminating the connection.
I know this is a bit off the wall and I'm definitely trying to do something a bit out of the ordinary but any suggestions or tips would be greatly appreciated.
In case anybody discovers this and has similar problems (this applies to all cometd implementations regardless of host), I discovered that the issue was with using the Google js library. For some reason, the dojo scripts I was loading from Google (1.4) didn't have a valid implementation of cometd. I switched my dojo script to the one that was used by the jetty-1.6.23 example and it works perfectly.