You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bas Gooren <ba...@iswd.nl> on 2012/02/03 20:51:13 UTC
Communication (in-vm) between webapps
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
Re: Communication (in-vm) between webapps
Posted by Bas Gooren <ba...@iswd.nl>.
Thanks Jeremy!
Since I needed something up & running quickly I have implemented the
"flush cache" operation through a page with pre-shared key auth for now.
Op 4-2-2012 15:04, schreef Jeremy Thomerson:
> I agree a messaging queue is a nice scalable system. But I also think
> pragmatic approaches are best. You don't have "messages" that need to be
> sent right now (data sent between disparate apps). You have a single
> command that needs to be invoked. That happens to be what HTTP is *really*
> good at. And, you're already writing a web app. That said, I'd choose
> Serban's recommendation. Create a Wicket bookmarkable page that takes a
> pre-shared key or some other method of authentication and call that from
> the app. If it's just an encrypted URL param that gives authorization you
> don't even need to call it from the other app - just give the user a link
> to click that goes straight to the "flush cache" page on the frontend.
> Open that in a new window, have your page print out "all your strings are
> belong to us" and you're done :)
>
>
Re: Communication (in-vm) between webapps
Posted by Jeremy Thomerson <je...@wickettraining.com>.
I agree a messaging queue is a nice scalable system. But I also think
pragmatic approaches are best. You don't have "messages" that need to be
sent right now (data sent between disparate apps). You have a single
command that needs to be invoked. That happens to be what HTTP is *really*
good at. And, you're already writing a web app. That said, I'd choose
Serban's recommendation. Create a Wicket bookmarkable page that takes a
pre-shared key or some other method of authentication and call that from
the app. If it's just an encrypted URL param that gives authorization you
don't even need to call it from the other app - just give the user a link
to click that goes straight to the "flush cache" page on the frontend.
Open that in a new window, have your page print out "all your strings are
belong to us" and you're done :)
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
On Sat, Feb 4, 2012 at 6:47 AM, Bas Gooren <ba...@iswd.nl> wrote:
> François,
>
> Thanks for your response.
>
> Playing around with messaging has been on my wishlist for a while now.
> I really like the features of JBoss HornetQ, in the context of my question
> especially the "no dependencies, can be embedded through guice, handles
> persistence itself without external db and ... in-vm transport".
>
> I didn't know about this project, so thanks for pointing it out.
>
> Sebastian
>
> Op 4-2-2012 12:39, schreef Francois Meillet:
>
> Hi Sebastian,
>>
>>
>> 1) crossContext :
>> Tomcat 7 - javadocs:
>>
>> Set to true if you want calls within this application to
>> ServletContext.getContext()
>> to successfully return a request dispatcher for other web applications
>> running on
>> this virtual host.
>>
>> But if you want something secure :
>> Set to false (the default) in security conscious environments, to make
>> getContext() always return null.
>> Easy, not scalable, unsecure
>>
>>
>> 2) socket :
>> Write a server and a listener using Socket and ServerSocket.
>> Inexpensive, not-scalable, .... must manage new threads
>>
>>
>> 3) jmx / mxbean
>> If you want to write a lot of lines of code ....
>>
>>
>> 4) Memory-mapped file with NIO
>> Easy, not scalable
>>
>>
>> 5) messaging
>> It may be overkill at first glance. Only at first glance,
>>
>> If you want something scalable and secure, go for a messaging bus:
>> For example, why not using JBoss HornetQ messaging system ?
>> It's scalable, multi-protocol, embeddable.
>>
>> Your components will be loosely-coupled, scalable and secure, and your
>> unit tests much easier.
>> Especially if you deploy your web app to a cluster....
>>
>>
>> François Meillet
>>
>>
>>
>>
>> Le 4 févr. 2012 à 12:17, Bas Gooren a écrit :
>>
>> Yeah, I was thinking the same thing.
>>>
>>> The only thing I need to take care of then is access control, normal
>>> users should not be able to invoke a cache clear by calling the url. But
>>> since the call made from the admin to the frontend will not go over a
>>> public network I can simply use a pre-shared key for that.
>>>
>>> Thanks to all who replied for their input!
>>>
>>> Op 4-2-2012 11:02, schreef Martin Grigorov:
>>>
>>>> On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci<thespamtrapp@**
>>>> gmail.com <th...@gmail.com>> wrote:
>>>>
>>>>> Some REST interface to be called through Httpclient from the admin
>>>>> application I'd say it's the simplest approach.
>>>>>
>>>> I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because
>>>> these require different ports to be open and sometimes this is
>>>> problematic.
>>>>
>>>> --
>>>>> View this message in context: http://apache-wicket.1842946.**
>>>>> n4.nabble.com/Communication-**in-vm-between-webapps-**
>>>>> tp4355616p4355667.html<http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html>
>>>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>>>
>>>>> ------------------------------**------------------------------**
>>>>> ---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: Communication (in-vm) between webapps
Posted by Bas Gooren <ba...@iswd.nl>.
François,
Thanks for your response.
Playing around with messaging has been on my wishlist for a while now.
I really like the features of JBoss HornetQ, in the context of my
question especially the "no dependencies, can be embedded through guice,
handles persistence itself without external db and ... in-vm transport".
I didn't know about this project, so thanks for pointing it out.
Sebastian
Op 4-2-2012 12:39, schreef Francois Meillet:
> Hi Sebastian,
>
>
> 1) crossContext :
> Tomcat 7 - javadocs:
>
> Set to true if you want calls within this application to ServletContext.getContext()
> to successfully return a request dispatcher for other web applications running on
> this virtual host.
>
> But if you want something secure :
> Set to false (the default) in security conscious environments, to make getContext() always return null.
> Easy, not scalable, unsecure
>
>
> 2) socket :
> Write a server and a listener using Socket and ServerSocket.
> Inexpensive, not-scalable, .... must manage new threads
>
>
> 3) jmx / mxbean
> If you want to write a lot of lines of code ....
>
>
> 4) Memory-mapped file with NIO
> Easy, not scalable
>
>
> 5) messaging
> It may be overkill at first glance. Only at first glance,
>
> If you want something scalable and secure, go for a messaging bus:
> For example, why not using JBoss HornetQ messaging system ?
> It's scalable, multi-protocol, embeddable.
>
> Your components will be loosely-coupled, scalable and secure, and your unit tests much easier.
> Especially if you deploy your web app to a cluster....
>
>
> François Meillet
>
>
>
>
> Le 4 févr. 2012 à 12:17, Bas Gooren a écrit :
>
>> Yeah, I was thinking the same thing.
>>
>> The only thing I need to take care of then is access control, normal users should not be able to invoke a cache clear by calling the url. But since the call made from the admin to the frontend will not go over a public network I can simply use a pre-shared key for that.
>>
>> Thanks to all who replied for their input!
>>
>> Op 4-2-2012 11:02, schreef Martin Grigorov:
>>> On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci<th...@gmail.com> wrote:
>>>> Some REST interface to be called through Httpclient from the admin
>>>> application I'd say it's the simplest approach.
>>> I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because
>>> these require different ports to be open and sometimes this is
>>> problematic.
>>>
>>>> --
>>>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html
>>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Communication (in-vm) between webapps
Posted by Francois Meillet <qq...@gmail.com>.
Hi Sebastian,
1) crossContext :
Tomcat 7 - javadocs:
Set to true if you want calls within this application to ServletContext.getContext()
to successfully return a request dispatcher for other web applications running on
this virtual host.
But if you want something secure :
Set to false (the default) in security conscious environments, to make getContext() always return null.
Easy, not scalable, unsecure
2) socket :
Write a server and a listener using Socket and ServerSocket.
Inexpensive, not-scalable, .... must manage new threads
3) jmx / mxbean
If you want to write a lot of lines of code ....
4) Memory-mapped file with NIO
Easy, not scalable
5) messaging
It may be overkill at first glance. Only at first glance,
If you want something scalable and secure, go for a messaging bus:
For example, why not using JBoss HornetQ messaging system ?
It's scalable, multi-protocol, embeddable.
Your components will be loosely-coupled, scalable and secure, and your unit tests much easier.
Especially if you deploy your web app to a cluster....
François Meillet
Le 4 févr. 2012 à 12:17, Bas Gooren a écrit :
> Yeah, I was thinking the same thing.
>
> The only thing I need to take care of then is access control, normal users should not be able to invoke a cache clear by calling the url. But since the call made from the admin to the frontend will not go over a public network I can simply use a pre-shared key for that.
>
> Thanks to all who replied for their input!
>
> Op 4-2-2012 11:02, schreef Martin Grigorov:
>> On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci<th...@gmail.com> wrote:
>>> Some REST interface to be called through Httpclient from the admin
>>> application I'd say it's the simplest approach.
>> I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because
>> these require different ports to be open and sometimes this is
>> problematic.
>>
>>> --
>>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html
>>> Sent from the Users forum mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Communication (in-vm) between webapps
Posted by Bas Gooren <ba...@iswd.nl>.
Yeah, I was thinking the same thing.
The only thing I need to take care of then is access control, normal
users should not be able to invoke a cache clear by calling the url. But
since the call made from the admin to the frontend will not go over a
public network I can simply use a pre-shared key for that.
Thanks to all who replied for their input!
Op 4-2-2012 11:02, schreef Martin Grigorov:
> On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci<th...@gmail.com> wrote:
>> Some REST interface to be called through Httpclient from the admin
>> application I'd say it's the simplest approach.
> I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because
> these require different ports to be open and sometimes this is
> problematic.
>
>> --
>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
Re: Communication (in-vm) between webapps
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Feb 3, 2012 at 10:17 PM, Serban.Balamaci <th...@gmail.com> wrote:
> Some REST interface to be called through Httpclient from the admin
> application I'd say it's the simplest approach.
I also think this is better than JMX, JMS/RabbitMQ/0mq, ... because
these require different ports to be open and sometimes this is
problematic.
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Communication (in-vm) between webapps
Posted by "Serban.Balamaci" <th...@gmail.com>.
Some REST interface to be called through Httpclient from the admin
application I'd say it's the simplest approach.
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Communication-in-vm-between-webapps-tp4355616p4355667.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Communication (in-vm) between webapps
Posted by Jim Pinkham <pi...@gmail.com>.
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 <ba...@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
>