0

I have a delivery report page in my application. My customers are always interested to know the latest status of delivery of goods.

I need to add an ‘auto-refresh’ functionality so that customers can get the latest status with out doing a manual refresh. The challenge with this requirement is hundreds of request will start hitting the server, whereas only a very minor % will have some update in the delivery status. I am not interested to go with a hundreds [in future it can grow] of irrelevant hits in a minute on my application server.

Solutions tried to satisfy the requirement: I used a websocket, it was all good in my non-cluster environment, however in cluster it started failing due to Wildfly cluster architecture challenges[AJP will not get upgraded]

Solution I am planning to implement: I can push the latest delivery status in a file to my webserver and let the request from the browser use static file. In this case my application server does not need to handle all those irrelevant requests.

Question: Is there any other better solutions to handle this?

Additional points:

I use ehcache to handle the cache in my application. There is a replication of those cache objects between server nodes. So this cache I can use incase need to share some data between server nodes.

This is a JSF-Spring integrated application.

I used Richface's a4j:push component for websocket which is not a suitable solution in wildfly cluster.

Sam
  • 554
  • 1
  • 12
  • 23

1 Answers1

0

Have you tried looking out for poll component from PrimeFaces?

UPDATE: Based on comment below, I think what you need is COMET (or any implement of reverse ajax)

Optional
  • 4,387
  • 4
  • 27
  • 45
  • It seems the poll component enables doing periodic requests in a specified interval. This again will result in too many hit on app server. Thank you for your comment. – Sam Nov 27 '15 at 09:00
  • @Sam I have updated the answer with information on COMET. Please check if that helps – Optional Nov 27 '15 at 09:03
  • https://en.wikipedia.org/wiki/WebSocket "Before WebSocket, port 80 full-duplex communication was attainable using Comet channels; however, Comet implementation is nontrivial, and due to the TCP handshake and HTTP header overhead, it is inefficient for small messages. WebSocket protocol aims to solve these problems without compromising security assumptions of the web". Is COMET going to be a heavy solution? I will do some more research on it. – Sam Nov 27 '15 at 09:37
  • 1
    Comet is soo 2000. Crawl out your cave. These days we have SSE and WS. – BalusC Nov 30 '15 at 11:02