Support Request: Using Amazon ElastiCache Serverless for Redis in Tsugi for Session Caching

[Zohaib Akram]

Dear Chuck and Tsugi Developers,

I hope this email finds you well.

I am currently working on integrating session caching in my Tsugi implementation using Amazon ElastiCache Serverless for Redis. However, I have encountered an issue that I hope you can assist with.

I have configured Tsugi to use Redis for session caching by connecting it to an Amazon ElastiCache Serverless for Redis instance. Unfortunately, when attempting to start a session, I receive the following error:

Fatal error: Uncaught RedisException: read error on connection to tcp://127.0.0.1:35012 in C:\xampp\htdocs\sc-lti\index.php:405 Stack trace: #0 C:\xampp\htdocs\sc-lti\index.php(405): session_start() #1 C:\xampp\htdocs\sc-lti\index.php(97): initiate_google_login() #2 {main} thrown in C:\xampp\htdocs\sc-lti\index.php on line 405

I suspect the problem might be related to the TLS connection, as encryption in transit is enabled for this ElastiCache instance. Despite this, I am unsure how to properly configure Tsugi to handle the TLS connection with Redis.

Could you please provide guidance on how to resolve this issue? Specifically, any necessary configuration changes or additional steps required to enable secure communication with Amazon ElastiCache Serverless for Redis would be greatly appreciated.

Thank you for your assistance and continued support.

Best regards,
Zohaib

[Chuck Severance]

Zohaib,

I am not an espert on redis in Tsugi - I use memcache - others may use redis.  However in the message below - it certainly looks like it is trying to find a redis server on “127.0.0.1” (a.k.a localhost...

What does the redis part of your config.php look like?  Change any IP addresses or passwords before posting so as not to reveal sensitive data.

/CHuck

--
You received this message because you are subscribed to the Google Groups "Tsugi Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsugi-dev+...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/tsugi-dev/3d24fc0c-70e4-4a38-9a8b-a1430a63d155n%40apereo.org.

[Charles Severance]

Zohaib,

As you are working through using redis for sessions in Tsugi,  make sure not to get confused by some memcache code in LTIX.php - you do not and should not try to imitate that code.

As a matter of fact, I wil lbe deleting that code - it was a weird experiment where I tried to deal with a race condition that I *imagined* *might* be a problem.   

As you run a Tsugi server, sometimes sessions just get lost.  The time out, folks close their laptos and the “heartbeat” to extend sessions does not run - and they come back and the session has timed out.  It cannot be fixed unless you make sessions hours long (a bad idea in my opinion).  I saw those “no session” errors for a while and tried to have a secondary recovery approach - which to my knowledge never found a session that was lost.

So I am going to take it out and just rely on the folks that write the memcache session library (and redis session library).

So in general for memcache, the only code that matters is in config.php - it both configures and sets up the session save handler.

I doubt you need any other code anywhere else in Tsugi to make it work.

Folks are welcome to share different experiences in terms of session timeout / loss on their servers - perhaps forlk leave sessions around for more than 18 minutes - especially with something like redis - that might be more practical than I think.

Make sure to ready my first message below about 127.0.0.1 - an obvious reason (I think) that you can’t find your redis server.

/Chuck

[Zohaib Akram]

Dear Chuck and Tsugi Developers,

Thank you for your prompt response.
I also tried Amazon ElastiCache Serverless for Memcached with encryption in transit enabled. Unfortunately, I encountered a similar issue where the process hangs indefinitely on session_start().

Both configurations are not working as expected, possibly due to the TLS connections required for encryption in transit. I would greatly appreciate any insights or guidance on how to configure Tsugi to work with Amazon ElastiCache Serverless Memcached, especially with TLS enabled.

Thank you again for your assistance.

Best regards,
Zohaib