Again - Lucee 5 & invalid definition of the attribute taglib

#1

This didn’t really get answered on the last topic that another user had created. Has anyone come up with a solution to this problem? I’ve watched the heap for a bit and it’s not climbing up over 80% when these errors crop up. The machine has 16 gigs of memory and I’ve given Tomcat a minimum of 6 gigs of memory and a max of 8 gigs of memory. This is Apache Tomcat/8.5.28 and Lucee 5.3.2.77 and FarCry 7.0.1.

#2

It seems to me like a Lucee bug, but the ticket has been “rejected” because nobody could work out how to reproduce the issue;

https://luceeserver.atlassian.net/browse/LDEV-1197

My guess is that it’s resource (memory) related, and that somehow the /farcry mapping is going missing which means the tag library path is invalid which results in an error.

I think you have two ways to work around the issue;

  1. Try to find any memory leaks in your app or a way to reduce the memory requirements. This is easier said than done, but at some point it would seem like there is memory pressure in the JVM and the mapping is somehow getting removed and never put back – a restart of the server “fixes” this. If those kinds of code changes aren’t possible then externalising cached objects and sessions into a caching server like memcached or redis might help as well.

  2. To remove the need for a /farcry mapping you can reorganise your directory structure so that the farcry folder sits inside your webroot. This might be your easiest option because if there’s no mapping then it can’t go missing, the files will always be in the correct place on disk :slight_smile:

Hope that helps. Please let us know if you have some success with either of these, in case anyone else runs into the issue.

cheers,
Justin

#3

What’s odd is there is nothing outside of THIS.webtopURL and THIS.projectURL in the constructor call. The folder is already in the webroot starting at /farcry/ and I don’t have any mappings defined in the lucee admin at all.

#4

Ok, if you don’t have a /farcry mapping at all then it’s a really wacky one :slight_smile: It should just find the files on the file system as normal…

Do you have any Application mappings in the farcryConstructor.cfm?

#5

The only thing I see is <cfset THIS.mappings = structNew() />. Nothing is actually in THIS.mapings.<blah> though. It’s not used beyond that initial struct create.

#6

Hmmm, can you try removing the cfset THIS.mappings = structNew() if it’s not used?

There’s actually a ticket here for Lucee 5.3.2.x which “adds support” for cfimport via Application mappings;
https://luceeserver.atlassian.net/browse/LDEV-2051

Maybe that’s somehow causing a regression if the THIS.mappings is defined as an empty struct? Seems odd, but worth a try.

#7

And if that doesn’t help then you could try defining the /farcry mapping in THIS.mappings and it might take advantage of that new feature since you’re on that version of Lucee, could be another potential workaround.

#8

Bummer, I’d hoped that 5.3 had a fix for this (thought I’d spotted on the lucee forum a while back) so I’m disappointed to hear it hasn’t.
My work around ended up being to change as many of my project & plugin cfimport taglib’s to relative eg: taglib="…/…/…/…/plugins/something
Otherwise I’d run the risk of the core webtop cfimports not working… which wasn’t a good look.
It certainly started happening in the move to 5.2. Startup load seems to have a lot to do with it. (I run multiple sites on the same server.) Also I suspect if the DB server starts cuing requests on startup it seems worse.

#9

I’ll give putting in an actual mapping a try in the constructor and let you know if that improves things.

1 Like
#10

@ophbalance I’ll be keen to know how you go :slight_smile:

1 Like