> On Sept. 1, 2012, 8:11 p.m., Yuri Zelikov wrote: > > Can we maybe do this kind of logic on the server side? It seems like the > > responsibility of the server to buffer requests in case of latency. Then it > > will also work for other - API based clients like micro-box. > > Vicente J. Ruiz Jurado wrote: > I just updated the bug with a screenshot to show the effect. > > I don't see clearly how to do this in the server side. A small example: > For some users is normal to open several clients with different waves in the > same browser in different tabs/windows (currently I see three users doing > that in one of our servers), so the server will see all of them with the same > session cookie and should answer all the search queries. > > Probably we have to make some work to avoid request misuses in the server > side, but IMHO this is independent to fix this issue with the client search > code. > > > > > > > > > Yuri Zelikov wrote: > But what about API clients? The patch only solves the issue for the Wave > client. I was thinking about server caching the requests. Like it will check > the request and if there's already identical request on the fly - it will not > issue a new call to SearchService, but instead will wait till the first > request returns and then return the same response for the both requests. > > Vicente J. Ruiz Jurado wrote: > This patch addresses WAVE-367 that is a webclient issue. This avoid to > much http connections for instance if our wifi connection fails (or similar > things), something very typical, or in server restarts. > > https://issues.apache.org/jira/secure/attachment/12543448/search-queries.png > > We can add a new issue to server/API side to add some cache capability to > petitions.
Ok, I guess we can add server side handling later. - Yuri ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6885/#review10975 ----------------------------------------------------------- On Sept. 1, 2012, 3:33 p.m., Vicente J. Ruiz Jurado wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/6885/ > ----------------------------------------------------------- > > (Updated Sept. 1, 2012, 3:33 p.m.) > > > Review request for wave, Michael MacFadden, Yuri Zelikov, and Ali Lown. > > > Description > ------- > > This patch sets the same timeout to search queries that the search polling > interval, so if the server does not respond in time, the query is aborted. > > > This addresses bug WAVE-367. > https://issues.apache.org/jira/browse/WAVE-367 > > > Diffs > ----- > > src/org/waveprotocol/box/webclient/search/JsoSearchBuilderImpl.java df37aa3 > src/org/waveprotocol/box/webclient/search/RemoteSearchService.java 69374b5 > src/org/waveprotocol/box/webclient/search/SearchBuilder.java c0f20fe > src/org/waveprotocol/box/webclient/search/SearchService.java 8d6c432 > src/org/waveprotocol/box/webclient/search/SearchServiceImpl.java 12bb791 > src/org/waveprotocol/box/webclient/search/SimpleSearch.java 5240554 > src/org/waveprotocol/box/webclient/search/testing/FakeSearchService.java > 4d2af4b > > Diff: https://reviews.apache.org/r/6885/diff/ > > > Testing > ------- > > I was running the server with --debug and with a breakpoint in > SearchServlet.doGet so I see that client abort the query (with firebug) if > the server does not respond in time. > > > Thanks, > > Vicente J. Ruiz Jurado > >
