Improving the ehCache Extension

So I’ve recently submitted a pull request for some bug fixes to ehCache and in doing so, I had some thoughts on the extension could be improved so I wanted to start some dialog on changes to the extension.

These changes are specifically for configuring ehCache with a manual configuration and it might break the mental model for users because it would not match up with the way you’d configure the ehcache.xml directly, but I think it would simplify things greatly from a configuration issue.

  1. The RMI URLs, must contain not only a hostname:port, but also the current cache name. So, you can’t just do: 192.168.1.20:40001|192.168.1.30:40001, you would need 192.168.1.20:40001/CurrentCacheName|192.168.1.30:40001/CurrentCacheName . That seems odd to me that you’d need to duplicate the cache name. Seems like Lucee should just add that for you.
  2. This is an ehCache thing, but in the RMI URLs you must exclude the current server from the list of listeners. This makes it difficult to push out Lucee configurations to a pool of servers, because you need to push a different configuration out to each node. For example, if you have 3 nodes (A, B, C), then node A must set up B & C, node B set up A & C and finally node C would set up A & B. I think it would simplify things a lot if Lucee would just ignore any hosts that match the current server. This might be difficult to do if not using IP addresses, but if it can be done, it would allow the same configuration to be pushed out to each node.
  3. The “Listener” port is required for both automatic and distributed mode. Since it’s required, we could simplify the RMI URLs even more by not making the port required in the values. The only use case where this could be a problem is if you’re using different ports for each host. However, if the port is supplied, we use the port supplied.
  4. Today, the extension creates a new ehcache.xml file for each cache configured for distribution. This means you end up needing to use a new port for each manually distributed cache. However, this normally is not necessary when configuring an ehcache.xml file manually. You can use the same port for multiple caches. So instead of building one ehcache.xml per cache, we build one per listener configuration. So if you have several different caches using the same listener ports, a single XML configuration is used for all the caches.

So, if you were using port 40001 for your RMI listener, you could just configure the RMI setup with hostname A,B,C on each server. It would automatically append the cachenames and port (when applicable) and ignore hostnames that match the current server.

I think this would simplify things greatly the configurations, and it would make the manual distribution configuration much more portable. Because a manual configuration requires a different RMI configuration for each node, you can’t just have a centralized Docker config you can spin up as needed for production. Each node has to be updated with it’s own configuration. Ideally, those configurations would just use multicasting, but multicasting is not always an option. For example, in our hosting environment, multicasting is only allowed on private cloud infrastructure. I suspect a lot of Lucee developers are in similar situations. Multicasting is definitely the way to go when you can, but if not, I think Lucee could make things easier!

5 Likes

This PR has been merged and released as 2.10.0.33-SNAPSHOT

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

1 Like