AtmosphereResponse.getWriter().print(int) doesn't work with non-servlet frameworks

[flowersinthesand]

The chars used to call PrintWriter.print(int) can be printed in practice only if its flush method is called. Since AtmosphereResponse delegate HttpServletResponse, those methods depending on the flush method work correctly with servlet container.

But, with non-servlet frameworks like atmosphere-vertx and atmosphere-play (maybe), because VertxAsyncIOWriter and PlayAsyncIOWriter extend AtmosphereInterceptorWriter whose flush method delegates to AtmosphereResponse.flushBuffer and HttpServletResponse.flushBuffer and there is no real HttpServletResponse instance, it seems that chars seem to be vanished in somewhere.

Not relying on servlet api or at least wrappers may be an essential approach, but anyway I couldn't find fallbacks for now.

[jfarcand]

Will fix in Atmosphere 2.0.1 most probably.

[jdahlstrom]

Hi, one of our clients seems to be this same or extremely similar problem with Equinox-Jetty. It appears that flushing the AtmosphereResource.getWriter() doesn't end up flushing the correct Writer instance.

Could you take a look at http://dev.vaadin.com/ticket/12529 (comment no. 11 onward is actually relevant)? I'd like some feedback.

[jfarcand]

@jdahlstrom Since you forked Atmosphere and since your don't use Github for fork, it is quite hard for me to help to be honest. Have you changed something to the core Atmosphere? I strongly recommend you fork on Github so I can easily follow using git downstream/upstream functionality. Your team can also donate to the project like other Open Source Framework that makes money are doing :-) It help motivate me to help ;-) Hope you understand :-)

[jdahlstrom]

Yes, I understand. I wouldn't bother you if I thought it's caused by something we have done. I've been working on this issue for quite long without getting forward.

I've also strongly suggested within Vaadin that we buy support time from you - I'll have to see why it hasn't happened yet.

We're sorry that we haven't gotten our fork to github yet. This is mostly for two reasons: first, all the changes we've made have been quite superficial hacks that are not worth pulling back to core Atmosphere, so it hasn't been a priority and second, automatically keeping the GitHub fork up to date would be a bit tricky given the way our own code review system (gerrit) works. However, I think that forking on github, cloning the github fork to gerrit, patching our modifications on top of the clone and then killing the original clone should work, I think.

[jfarcand]

@jdahlstrom I do have user on Equinox so I'm not sure if the issue is the same or not. If someone can share a test case in your team, that will help.

[jdahlstrom]

@jfarcand Unfortunately, it seems to be some sort of a corner case in our client's large application and we've not been able to reproduce it or reduce it to a small test case. So I just wondered if/hoped this might have something to do with it. Oh well, I'm not sure anything can be done about it until we can come up with a sensible test case somehow.