79198412 Search does not complete: user returned to search page - Website Problem (Kay Brown)

[FreeUKGenIssues]

Issue reported by Kay Brown at 2017-07-05 15:33:32 UTC Time: 2017-07-05T15:31:55+00:00 Session ID: 21090e5ffc3d19967ffd4bb097af417b Problem Page URL: []() Previous Page URL: https://www.freereg.org.uk/contacts/new Reported Issue: Please can you tell me why the search page keeps resetting? I put the search information in and when I press search it clears the data so I have to put it all in again!

[ghost]

This is the second report so far today of this issue type, along with problems of searches going straight to blank screens.

[edickens]

It doesn't happen for me. We need to reproduce the search that they are trying to do. For example are they using Wildcard?

[ghost]

I will query this will the contact now.​

Kind regards The Communications Team

On Thu, Jul 6, 2017 at 11:40 AM, Eric Dickens notifications@github.com wrote:

It doesn't happen for me. We need to reproduce the search that they are trying to do. For example are they using Wildcard?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-313361235, or mute the thread https://github.com/notifications/unsubscribe-auth/ATmwDiPNNvfoiXDFVA25Rtg39HjOHQhUks5sLLmbgaJpZM4OPZl3 .

[ghost]

Had this from contact this morning:

"It has happened with and without Soundex but it has jumped straight back to an empty form at other time I did wonder if it was because of there being too many results but it doesn’t even pop up that it produces too many results as it normally does I don’t use the wildcard

The widest search I ever do is on surname and county and/or town but I have noticed that it is worse if it pops up asking if you want to display non secure items"

[ghost]

Two more reports of site problems today:

Reference 78942176: When search activated, no finds are returned (when I know there are)just returns back to search box to be filled in again.

Reference 79018779: Do you an issue? I have found over the past few days I put in an entry and it bombs out

Seems like this is a slightly bigger issue than we thought.

[ghost]

Another reference: 78745813: Helloo, For the last few days I have entered the details and pressed 'Search'. The screen has changed, as usual, then it has flipped back to a blank search screen. Is this something I am doing wrong or a current issue you have? Oh, and thank you for providing a very good the website for family history researchers.

Various screenshots have been provided if needed.

[DeniseColbert]

We've also had a Facebook message echoing this issue

[ghost]

Two more reports today

[ghost]

Two report through Comms today

[SteveBiggs]

I have tried several searches with various different options selected and cannot reproduce this problem.

[helhyde]

Can we check browser. Also, if they can try and replicate, but take a screenshot before pressing "search", that would help enormously

Pat Reynolds Executive Director, Free UK Genealogy

On 14 Jul 2017 4:58 p.m., "Stephen Biggs" notifications@github.com wrote:

I have tried several searches with various different options selected and cannot reproduce this problem.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-315396903, or mute the thread https://github.com/notifications/unsubscribe-auth/ANXTHXeCY0pigvr5nsaSfJKpcRozeoyQks5sN5AGgaJpZM4OPZl3 .

[ghost]

I can email a few of the contacts to see about the browser. I went looking back through the emails and did fine one in which the contact did take a screen shot but it was so blurry you cannot make out the specific details that were entered. However I could see that details had been entered for forename, surname, date range, county and place, marriage was selected and also the nearby places and Name Soundex boxes had been ticked.

[ghost]

A few of our contacts have come back and a variety of browsers have been used, such as IE 11, Chrome and Firefox

[Sherlock21]

I have tried a search ( without logging on) and it works fine for me ( on iMac with Safari) And also with Opera.

I have Plusnet fibre broadband as my ISP & everything is old fashioned cable equipment - i.e. no wireless connections anywhere.

[edickens]

Until we can reproduce it we are getting nowhere. We need to know what search the contact was doing when the fault occurs and also if it happens every time. Can they reproduce it? ED

[ghost]

So far no one seems to be able to reproduce on any browser. I would tend to think it is an issue on there end. We all seem to have no issue. Could it be something blocking them?

On 15 Jul 2017 16:31, "Eric Dickens" notifications@github.com wrote:

Until we can reproduce it we are getting nowhere. We need to know what search the contact was doing when the fault occurs and also if it happens every time. Can they reproduce it? ED

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-315541814, or mute the thread https://github.com/notifications/unsubscribe-auth/ATmwDtwgwbR9UkXtOmQD_gK0oXVe2HTiks5sONsygaJpZM4OPZl3 .

[suffolkroots]

This happened to me last week. At the time I assumed it was my mistake. Can't reproduce it---sorry

[ghost]

Have had more reports today.

Would it be helpful if I devised a small questionnaire to send out to those who have reported on the issue to see what info we can drag up? Questions such as the browser they used, time of day, dates (if multiple occasions), and whatever else you all might think appropriate?​

Kind regards The Communications Team

On Sun, Jul 16, 2017 at 4:29 PM, suffolkroots notifications@github.com wrote:

This happened to me last week. At the time I assumed it was my mistake. Can't reproduce it---sorry

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-315616672, or mute the thread https://github.com/notifications/unsubscribe-auth/ATmwDq1vw3Hb4mqSYOvFLD0828CoPFHrks5sOixRgaJpZM4OPZl3 .

[ghost]

This contact I have just looked at and think this may provide more info:

"The last few days I have been experiencing lots of search problems with your website to the point that it is now unusable. Previously I was permitted to perform one search but after returning to the search page using the browser back button or revise link, all subsequent searches would fail with me again being presented with the search page with all fields emptied. Today this is happening with my initial search so I am not getting any results whatsoever. I know this is not a problem at my end as a fellow researcher has reported the exact same symptoms to you. I am using Chrome Version 59.0.3071.115 (Official Build) (64-bit) running on Windows 7 although I have also experienced the same issue in Firefox and Opera "

Surely there is something to this, or we would not be getting so many reports.

[SteveBiggs]

There is something to it. It's just a question of being able to reproduce the problem.

So I have carried on testing and have found a case that fails. I searched for: John Biggs in Bedfordshire (no dates and all types) and find 16 results. I then revised the county to Sussex and get bounced back to the blank search page.

This test seems to suggest that if you search for surname, forename and county only in a county with no results, you get bounced back. It could give us something to go on.

[SteveBiggs]

Further testing of various different counties suggests the problem is random.

[Captainkirkdawson]

Believe I know the cause. If the search is being conducted on a slave server. The results have to be written by the primary and then replicated to the slave. If there is a delay in the replication then the slave will not find the search query. Under those situations it goes to a new search page. Will have to think about the best solution.

[Captainkirkdawson]

Ben and others

It appears that our current configuration has a problem.

Over the past 2 weeks there have been a number of reports in story 980 under the heading of "Search does not complete"

A review of the logs shows that the issue is not that the search does not complete but we fail to find the search query for a search (There is an error message generated for this situation)

I believe that the issue is caused by having an application server connect to a secondary. The write of the search query has to be done by the primary and them replicated to the secondary. The configuration as currently set up has a default write concern hence processing continues when the primary has written the record thus it is possible that the write to the secondary is not complete by the time the app asks for the results of the search from the secondary. Remember that the search query collection is not sharded and exists only on the main replica set. Hence just 2 copies

There are several approaches to resolving this issue if the diagnosis is correct.

1. Have the apps only connect to the primaries. This will mean that there are only 3 search record servers. The secondaries will only function as real time availability servers. Taking over when a primary fails. Easy to do at the configuration level. May slow search response

2. Use a write concern of majority for the database. Easy to do at the configuration level. This will slow the database updates. It may slow search response time

3. Use a write concern of majority for just the search query collection. More complex to implement as will have to be coded into the search query model Searches will run on all 6 servers.

4. Other solutions?

Comments please

[Captainkirkdawson]

It appears that 5% of searches that use a secondary are failing by accessing the search_query before it has been replicated. It will be random and dependant solely on load at that time. Searches done on a primary (Currently only colobus as brazza is still unavailable) do not show any such issue

[richpomfret]

@benwbrum @Vino-S What do you think?

[Captainkirkdawson]

While awaiting any comments I have switched saki to primary preferred the same as brazza and colobus. That leaves drill and howler as secondary preferred. Will oberve impact if any. Prior to change the average server response time for a search was 469ms

[Captainkirkdawson]

There have been no issues with missing search queries on saki since the change. The average server response time for a search is now 537ms. Propose to change both drill and howler

[SteveBiggs]

Kirk, is there likely to be any/much impact on performance in the member's management activities with this change? (I haven't noticed any)

[Captainkirkdawson]

All app servers are now connecting to primary mongodb servers. Server search response time is 560 ms. Prior to sharding it was 3500ms, So the change has added 100ms to a search response and that will be hardly visible to the end user. There is no impact on member management functions; they have always been conducted on a primary mongodb server. Will now pursue option 3. Could @CommsCoord inform those users that appeared to be impacted that issue has been resolved.

[ghost]

Will do. May I close this down now?

Thank you.​

On Fri, Jul 21, 2017 at 1:38 PM, Kirk Dawson notifications@github.com wrote:

All app servers are now connecting to primary mongodb servers. Server search response time is 560 ms. Prior to sharding it was 3500ms, So the change has added 100ms to a search response and that will be hardly visible to the end user. There is no impact on member management functions; they have always been conducted on a primary mongodb server. Will now pursue option 3. Could @CommsCoord https://github.com/commscoord inform those users that appeared to be impacted that issue has been resolved.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-316989930, or mute the thread https://github.com/notifications/unsubscribe-auth/ATmwDus2tqINaH1zZvKroI7dXjU5CsURks5sQJuzgaJpZM4OPZl3 .

[Captainkirkdawson]

There is still work to do will raise new story

On Jul 22, 2017 2:27 AM, "CommsTeam" notifications@github.com wrote:

Will do. May I close this down now?

Thank you.​

On Fri, Jul 21, 2017 at 1:38 PM, Kirk Dawson notifications@github.com wrote:

All app servers are now connecting to primary mongodb servers. Server search response time is 560 ms. Prior to sharding it was 3500ms, So the change has added 100ms to a search response and that will be hardly visible to the end user. There is no impact on member management functions; they have always been conducted on a primary mongodb server. Will now pursue option 3. Could @CommsCoord https://github.com/commscoord inform those users that appeared to be impacted that issue has been resolved.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/ 980#issuecomment-316989930, or mute the thread https://github.com/notifications/unsubscribe-auth/ ATmwDus2tqINaH1zZvKroI7dXjU5CsURks5sQJuzgaJpZM4OPZl3 .

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeUKRegProductIssues/issues/980#issuecomment-317166699, or mute the thread https://github.com/notifications/unsubscribe-auth/ACvdRi-m8U944N65XQkahKpYtTh4vu_tks5sQbJ1gaJpZM4OPZl3 .