I’m reporting an experience we’ve recently had running our Vaadin 7 app on an “Akamai’ed” network. (Akamai is a content delivery network, for the uninitiated.) We use server push extensively and, for various compatibility reasons, force Vaadin to use the “long-polling” transport. Our app works well when deployed without Akamai in the picture, but “hangs” on first access when using Akamai. Over the course of a multi-week debugging session with Akamai, it was determined that a change in what they call “metadata” on their edge servers was needed to make our application run properly. It turns out they regularly do
response caching
, holding back sending response data until x bytes have been accumulated. This does not play well with the concept of long polling, where a session is kept open for a while to allow server push to work.
Our application now runs because Akamai disabled the cache, but this was only for our servers. We’ve not determined if Akamai thinks their caching scheme is “a bug” on their part, warranting a fix for all customers. So if other Vaadin / Akamai users experience a similar anomaly, response caching would be one of the first issues to bring up with your Akamai rep.
Hope this helps someone.