Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Getting readLine() to block persistently

 
Roger F. Gay
Ranch Hand
Posts: 408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I set up a push system between an Applet and a Servlet using URLConnection. It actually works, with the following code on the Applet.



The problem I'm having is with the readLine() code. I thought it would stop and wait until it received an end of line character time after time, but it doesn't. So, while this actually works, the while loop is constantly crunching away. Instead of waiting for the next input, readLine() would read null. Because readLine() is supposed to wait for an end of line character, I tried sending a string without one from the servlet after sending complete messages. That didn't work either. The output was exactly what I expected - however - the reason this is a problem is that the loop consumes 40% or more of my CPU capacity. Easily checked, I would simply comment out the loop or let it read once, and my CPU usage was down around 5%. No matter how I played the game, trying to keep the readLine() available for new input put CPU usage up around 50%.

Is there anything I can set to force readLine() to stop and wait for new input (or other method that will work)?

If no; will I do any better using Socket / ServerSocket instead of URLConnection?
 
Roger F. Gay
Ranch Hand
Posts: 408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm still interested in alternative solutions to this, but I've sort of half given up to do something slightly more conventional.

I simply moved the while loop so I'm polling (I think that might be the wrong term here). I do one conventional client request and wait for one single response, close everything, and repeat while(true). The heavy CPU usage disappeared. I stuck in a Thread.sleep() in my - so far - goofy little server that's just handing data back in a loop so that the client didn't constantly have something to read, which makes it more like what I expect. But even before I did that - with numbers changing in my browser so fast they were unreadable - CPU usage was significantly lower.

I can't think of a single reason this won't work for me in the demo I'm building right now, and it'll probably always work - maybe.

But I'm still interested in doing this without ever closing the connection. I always feel it's theoretically possible to miss something. Also, although this solution makes efficient use of the client CPU, I think I read somewhere that the Internet thinks constantly opening and closing connections is a bit rude.

On the other hand, it looks like it will be easier to deal with connection problems.
 
Steve Harney
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I actually prefered your first solution but it just needed a little tweek, inspired by your second solution.



basically, read until you cannot read no more, and if there is nothing available sleep for a little bit and then see what is waiting. It should stop thrashing your cpu and looks closer to your original solution.

Using a ServerSocket/Socket connection will still not give you anything different you still have to wrap it in a stream and you end up with the same issues.
 
Roger F. Gay
Ranch Hand
Posts: 408
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve Harney wrote:

basically, read until you cannot read no more, and if there is nothing available sleep for a little bit and then see what is waiting. It should stop thrashing your cpu and looks closer to your original solution.

Using a ServerSocket/Socket connection will still not give you anything different you still have to wrap it in a stream and you end up with the same issues.


Thanks. I appreciate all responses and your advice re: ServerSocket / Socket is very helpful. Will save me the time of trying it.

I think burying a sleep state in the Applet receiver will create timing problems for a push system. The push system will receive real time data generated by another system. There is no end to the input. The data is not all immediately available and the timing of input is random. So it's really somewhat more like a simple chat system; that I'm trying to implement without requiring any software installed on the recipient computer - or special security requirements: i.e. so someone can go to any computer in the world, fire up a browser to see what's going on in real-time.

It would work great, if for example, there was a way to recognize availability of new input event. But I don't see the possibility of doing that with the event occurring on the server and the need for the event notification on the applet receiver. Or of course, if the stupid readLine() would just always wait for input like it does the first time.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!