I’m using the Lucee Redis extension inside a commandbox docker container running lucee-light@5.3.8.206 on Java Eclipse Adoptium 11.0.14.1.
I was using version 3.0.0.32-BETA of the extension but it got auto-upgraded (as I hadn’t locked on to a version) after which the following exception appeared:
"In the OSGi Bundle with the name [redis.extension] was no class with name [lucee.extension.io.cache.redis.simple.RedisCache] found"
I downgraded to 3.0.0.33-BETA which stopped this error, but the following kept coming up in the logs every few seconds:
[ERROR] runwar.context: java.io.IOException: type [lucee.runtime.type.UDFImpl] cannot be converted to BSON yet!
[ERROR] runwar.context: at lucee.extension.io.cache.util.BSON.toBsonValue(BSON.java:344)
[ERROR] runwar.context: at lucee.extension.io.cache.util.BSON._toBsonDocumentStruct(BSON.java:374)
[ERROR] runwar.context: at lucee.extension.io.cache.util.BSON.toBsonDocument(BSON.java:256)
[ERROR] runwar.context: at lucee.extension.io.cache.util.Coder.serialize(Coder.java:123)
[ERROR] runwar.context: at lucee.extension.io.cache.redis.RedisCache.put(RedisCache.java:405)
[ERROR] runwar.context: at lucee.extension.io.cache.redis.RedisCache.access$100(RedisCache.java:37)
[ERROR] runwar.context: at lucee.extension.io.cache.redis.RedisCache$Storage.run(RedisCache.java:995)
Finally I reverted to 3.0.0.32-BETA and these errors stopped being logged.
I guess this is just incompatibility between engine/extension versions?
I believe @micstriit has fixed this with the latest 3.0.0.43-BETA (May 11, 2022)
I spoke too soon, reverting to 3.0.0.32-BETA hasn’t stopped the errors in the logs.
@Zackster Thanks I’ll give 3.0.0.43-BETA a go.
@Zackster will it require 5.3.9.x of the core engine though? My containers are still on 5.3.8.
Tested 3.0.0.43-BETA and it seems to fix the class not found exception, but the logs are still still spewing
[ERROR] runwar.context: java.io.IOException: type [lucee.runtime.type.UDFImpl] cannot be converted to BSON yet!
[ERROR] runwar.context: at lucee.extension.io.cache.util.BSON.toBsonValue(BSON.java:344)
etc
ah, maybe you need to clear the redis cache since the switch to BSON?
Tried that (FLUSHALL on the redis-cli). Tried deleting my entire swarm including the redis and lucee containers and removing the internal docker volume directories in case they were caching anything.
Still getting these BSON errors from my commandbox/lucee containers when they start up.
I should have noted that the redis image I’m using is 6.2.6-alpine, which hasn’t changed (i.e. that was the version in use before these errors started appearing).
It looks like I was wrong to report my initial Redis Extension as 3.0.0.32-BETA. I’ve just gone back to 3.0.0.31-BETA and the BSON errors have now gone away. So that must have been the version I was using before it got auto-upgraded.
check your lucee-server/context/logs/deploy.log, something did go wrong in the installation
Thanks Micha. There’s just one line in the deploy.log:
"ERROR","main","05/12/2022","14:53:02","extract-extension","could not found [/extensions/.index] defined in the index in the lucee.jar"
Which is odd as there 8 extensions installed according to the admin (specified by an ENV), including Redis and I would expect entries for them. All working but still getting these BSON errors in the out.log, I assume triggered every time the healthcheck runs every 20 seconds.
I’ve created another simplified commandbox/Lucee + redis multi-container app to test and the deploy log was filled with the expected entries and there are no BSON errors. So must be a specific glitch with my original setup.
@Julian_Halliwell by default the log level of the deploy log is set to Error, so as long you have no errors, nothing is logged.
About the BSON exception, as you may know, redis can only store strings/byte arrays, so when you store a complex object like a function in that case, the extension has to serialize that object. In previous version the extension did use object serialisation for this, but for performance and size reasons, we switched to bson. But bjson is limited and cannot serialize all kind of object, so if it is not possible to bson an object, the exception falls back to the old ways. What this did fail is not clear to me. @Zackster the extension is also backward compatible, means it can read old records created by older version of the extensions, so that is not the issue. stay tuned the answer follow soon.
1 Like
Issue is solve with 3.0.0.44-RC. Problem was the mixed case, The extension detects a object it can bson, but when doing it it detects an object it cannot, so it fall back to object serialisation. Problem is that it reports this, what is not necessary.
@Julian_Halliwell i would suggest not to store functions into Redis, i cannot see a benefit in doing that and it is expensive. You do not see that right away, the extension uses a Near cache, so the code has not to wait for an object to get stored, but it still eats CPU in the back.
I was even considering adding a flag that when set only allows objects it can bson. @Julian_Halliwell could you please confirm in the ticket when the fix is working for you?
BTW we also switched from BETA to RC.
2 Likes
Thanks, Micha, your fix works! 
But as I’ve noted on the the ticket, we’re not caching functions but CFC instances (quite often in arrays). I guess Lucee sees them as the same kind of thing.