Question

Photo of Michael Garrison

0

Inconsistent behaviors during check-in after 4.x upgrade

Our church has one Saturday night service and two Sunday morning services (9am and 10:45). Saturday night everything went well (except for the parent pickup label as noted).

Sunday morning however, was a different story. Our two check-in kiosks would get as far as allowing a family to be selected and then upon selection would report that "nobody in this family is eligible for check-in". Unless one of the parents was a children's ministry volunteer (configured for check-in), in which case it would just check the volunteer in immediately- meaning that the kids were not recognized as eligible).

I came in and attempted check-in from my phone, identifying my phone as the "left kiosk" in our setup. I was able to sucessfully check-in a family from my phone, and once that was done, I tried again from the actual left kiosk (without even refreshing the page) and it worked. And continued working for that service.

Upon reflection I should have repeated the process with the right kiosk, but I just took that an an indication that the kiosks "should" be working. So I restarted the right kiosk, reloaded the check-in page, changed the check-in group configuration, changed it back... but nothing I did could get it to check-in kids.

Then at the 10:45 service, volunteers started coming in and the left kiosk wouldn't check them into the 10:45 service- they were given the option of checking into the Saturday night service or the 9am Sunday service. Unfortunately, we did not try the right kiosk so I can't report how it was behaving. The left kiosk continued working to check kids into the 10:45 service.

Midway through the 10:45 service, and after some reflection on the problem, I logged into the checkin page from another computer from another part of the church where I was, posing as the right kiosk. I got as far as being able to select which of my children I was checking in (which was after I'd have gotten the error message) but didn't complete the check-in since I wasn't there to explain to our volunteers why the printer just spit out labels for my kids. After service however (after the normal service check-ins were closed), I went back and configured the actual right kiosk to have it check in on the built-in "test 24x7" group, and was able to check my kids in sucessfully to that "service".

So here's where this leaves me:

It seems that for some reason our kiosks were having communication issues -or something- with Rock until another device posed as each of them in turn and sucessfully logged a check-in. I have hopes that the right kiosk works now, although there's no "real" way of testing that until next weekend. It could be pertinent that our kiosks are touchscreen Windows Embedded thin clients - still updated/supported due to being "embedded" SKU, but running Chrome which has recently started warning that Chrome will stop receiving updates soon. We are using the check-in website directly, not the app, since the app will not load without a newer version of .net, which I can't get loaded on these old machines.

But I have no idea why the volunteers were unable to check into the 10:45 service. Perhaps I need to do that from another device once as well

But none of this explains why Saturday night worked. I've gone over and over our check-in configuration and everything seems to be in order. And obviously worked before 4.0.

I can't figure out what issue these symptoms point to. Does this seem consistent with anything that anyone else can identify? Are there configuration details I can provide to help verify our setup? Or can anyone think of any steps I can take to try to make sure next weekend isn't a repeat of this weekend?

Thank you all.

  • Photo of Michael Garrison

    0

    All issues were resolved with (IIRC Rock v4.3). Just closing this request.

  • Photo of David Turner

    1

    One of the changes made to v4.0 regarding check-in was modifying how check-in configuration details are cached. Previously this information would only be cached for a few minutes, but In high-volume check-in scenarios this caused a noticeble delay when recreating the cache. Check-in was updated to cache this configuration information indefinetely or until a configuration change was made in Rock that affected the cached data. In looking into this a bit, it does appear that there is some "next active date/time" information that would be an issue if the cache was created any day previous to the current day of check-in. If the webserver is configured to recycle the application pool every morning, this would not be an issue as cache would then get recreated for the same day. However, if your server is not recycling the app-pool on a regular schedule, or it recycles it at the end of the day (with check-in devices running that would recreate the cache prior to midnight) you could see some issues. We will update Rock so that this cache automatically expires at the end of the day, but in meantime you can configure your webserver to recycle app-pool every morning (early), or manually clear the cache on Sunday morning prior to check-in beginning.

  • Photo of Kelley Langkamp

    0

    I don't have an answer but I'm experiencing something similar. We have childcare groups that are set up for checkin like a small group (because people pay for childcare we don't want people checking in that haven't paid). We've been running into problems this week where the checkin kiosk thinks it's the wrong day. The kiosks are shutdown each night. However, when she logged them in on Tuesday morning, it would only checkin the Sunday night kids. Tonight, it would only checkin the Tuesday morning kids. Restarting Rock seems to clear up the problem however that is obviously not a long term solution.

    • Kelley Langkamp

      Ours are thin clients too but I don't remember what version of Win Embedded they are running. I did update the Rock checkin client on all of them last week.