wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Pinkham <pinkh...@gmail.com>
Subject Re: Communication (in-vm) between webapps
Date Fri, 03 Feb 2012 20:06:29 GMT
My first thought would be ehcache all the stuff in front end with a
reasonable expiration period (hours maybe), and then expose a very simple
JMX interface to manually reset the cache without bouncing the entire
app.  No need to send much data over JMX other than just a simple 'refresh
all caches' command. Pretty simple, but gives you a lot of options.

Good luck
On Fri, Feb 3, 2012 at 2:51 PM, Bas Gooren <bas@iswd.nl> wrote:

> Hi All,
> Maybe a fellow wicketeer can help me with this:
> We deploy one of our apps in two components: a frontend and an admin. We
> recently implemented a StringResourceLoader which fetches translations from
> a database.
> So far so good.
> Now we face the following problem: the frontend uses this
> StringResourceLoader, but the actual translations are managed through the
> admin.
> Currently both apps are deployed on the same vm (and in the same tomcat
> instance), but this might change in the future.
> We need a mechanism to tell the frontend to flush the localizer (and
> StringResourceLoader) cache when the user clicks a button in the admin.
> After some investigation we've found a number of solutions, ranging from
> easy to complex:
> - cross context = true, share a boolean through the ServletContext and
> poll for it to change
> - have the frontend expose an MBean (JMX) which the admin can control
> - use a message bus for communication (e.g. rabbitmq)
> - cluster communication, such as jgroups or hazelcast
> Can anyone comment on this? I'd prefer to keep things simple at this stage
> (e.g. setting up an external message bus for this seems overkill), but
> having something which works as we scale out would be preferable.
> Sebastian

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message