Another option might be to turn Pulse into a separate and standalone (Spring Boot?) app. Perhaps that might be an acceptable compromise for pulling it out of the locator completely.
--Jens On Wed, May 1, 2019 at 11:26 AM Anilkumar Gingade <aging...@pivotal.io> wrote: > 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 <dsm...@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 <jde...@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 <jil...@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 <mole...@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 > > > > > > > > > >
