geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Oleske <mole...@pivotal.io>
Subject Pulse - Non-Embedded Mode
Date Tue, 30 Apr 2019 19:10:30 GMT
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

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