[MGNLPER-114] Testing orchestration of search results Created: 10/Sep/19  Updated: 02/Jan/20  Resolved: 20/Dec/19

Status: Closed
Project: Periscope
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Jorge Franco
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split from MGNLRESTUI-9 Findbar Search-results-supplier: Use ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Declarative REST clients
Sprint: Declarative REST 13
Story Points: 2

 Description   

Timebox for testing with 2-3 REST Client-based search suppliers.

With MGNLPER-93, search results will be a mix of content including external sources. The aim of this ticket is to orchestrate the different suppliers in a way that e.g. the user experience is not affected by slow response times of a REST service.

Some mechanisms are in place, app-loading bar might get stuck at times, though I can't say whether it's blocking at all.
Also, Vaadin Push finally landed in 6.2, this ticket is expected to:

  • revisit the existing 6.0 solutions (hopefully simplify that semaphore
  • leverage Vaadin Push
  • consider fault tolerance APIs such as resilience4j


 Comments   
Comment by Christopher Zimmermann [ 11/Sep/19 ]

slutz I think you created this during the review, but I guess meant to change the description? Was it something about additional refinement such as performance optimizations based on our previous difficulties with Rest based providers?

Comment by Mikaël Geljić [ 17/Sep/19 ]

Yes, some mechanisms are in place, app-loading bar might get stuck at times, though I can't say whether it's blocking at all.
Also, Vaadin Push finally landed in 6.2, this ticket is expected to:

  • revisit the existing 6.0 solutions (hopefully simplify that semaphore)
  • leverage Vaadin Push
  • consider fault tolerance APIs such as resilience4j
Comment by Jorge Franco [ 20/Dec/19 ]

The experience with 4-5 rest supplier is very good, you get local results and after you get remote results async all together. Even when you have some api returning fails the experience is the same, no delays. Also no problems when you type fast or a lot of things.

Generated at Mon Feb 12 10:28:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.