geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anilkumar Gingade <aging...@pivotal.io>
Subject Re: Pulse - Non-Embedded Mode
Date Wed, 01 May 2019 18:26:10 GMT
We should be supporting non-embedded mode; I believe most of the app-server
based use cases will be doing this. This also reduces the resource usage on
the geode cluster.



On Wed, May 1, 2019 at 10:44 AM Dan Smith <dsmith@pivotal.io> wrote:

> Option 2 does sound like a good way to go. It does seem like if you are
> making changes to fix non-embedded mode, you probably need to add an
> acceptance test for that mode since there is non already, regardless of
> whether you deprecate non-embedded mode.
>
> I have no issues with deprecating either embedded or non-embedded mode. I
> don't think we've put a lot of energy into pulse recently.
>
> -Dan
>
>
> On Tue, Apr 30, 2019 at 2:12 PM Jens Deppe <jdeppe@pivotal.io> wrote:
>
> > More accurately, I think geode-core is only required when TLS is enabled
> on
> > the locator and Pulse needs to make JMX/RMI calls over TLS.
> >
> > I would vote for option 2 in this scenario.
> >
> > --Jens
> >
> > On Tue, Apr 30, 2019 at 1:44 PM Jinmei Liao <jiliao@pivotal.io> wrote:
> >
> > > I believe to run pulse in non-embedded mode, you just need to install
> the
> > > war in a web server and some configuration changes, you don't need
> > > geode-core at all.
> > >
> > > We do lack the acceptance test to run pulse in non-embedded mode
> though.
> > We
> > > have a few unit tests that touches some aspect of it.
> > >
> > > On Tue, Apr 30, 2019 at 12:10 PM Michael Oleske <moleske@pivotal.io>
> > > wrote:
> > >
> > > > Hi Geode Community!
> > > >
> > > > Some colleagues and I were looking at GEODE-6683 (
> > > > https://issues.apache.org/jira/browse/GEODE-6683) and noticed that
> we
> > do
> > > > not have test coverage for running Pulse in non-embedded mode.  We
> were
> > > > wondering what our strategy is around Pulse in non-embedded mode. In
> > > order
> > > > to fully fix the issue, we would prefer to have a high-level
> acceptance
> > > > test that actually tries to run Pule in non-embedded mode (we could
> not
> > > > find an existing acceptance test that performs this).   However, this
> > > > non-embedded mode seems a bit odd, as the instructions for it (
> > > >
> > > >
> > >
> >
> https://geode.apache.org/docs/guide/19/tools_modules/pulse/pulse-hosted.html
> > > > )
> > > > are slightly confusing and need some updating for geode (such as
> making
> > > > sure geode-core is on the class path). It seems strange to try and
> > host a
> > > > web app in this way, especially with the extra configuration needed
> > > (cannot
> > > > just plop the Pulse war file in my web server with some config and
> have
> > > it
> > > > work).  So there's some questions about the best path forward.
> > > >
> > > > 1.  Should we continue supporting non-embedded mode for Pulse?  It
> > seems
> > > > like it may be useful to allow Pulse to run outside of a member, but
> > not
> > > as
> > > > it currently does.  If it was deprecated, I wouldn't be as insistent
> on
> > > an
> > > > acceptance test for it.
> > > >
> > > > 2.  Should we try to make a separate artifact that is intended to be
> > > > deployed on a web server?  This would have a new artifact that could
> > run
> > > > elsewhere then (with maybe a user provided config file for
> properties.)
> > > >
> > > > 3.  For the issue that brought up these questions (GEODE-6683), we
> have
> > > > currently only written some unit tests to add the properties. So the
> > > > current question is what type of path forward should we take?
> > > >
> > > >
> > > > -michael
> > > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
>

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