Oh, that actually cleared up what the vertx package is in the plumtree module. I was a bit confused as to whether it was part of the implementation or not.
It does seem that vertx is only used within the example server and related integration tests. If this isn't required as part of the programming model then it would be better to move it out, I think. The servlet implementation might be interesting. I will give it some more thought. On Mon, Dec 12, 2022 at 12:30 AM Antoine Toulme <[email protected]> wrote: > Yes, that is a valid use case! It’s just gossip and propagation, and as > long as all servers know of at least a valid peer, they can propagate the > information. > > Definitely happy to help with a tutorial page and push this component to > maturation. > Maybe a way to also make this less tied to the example implementation > might be to have a second implementation example, and move the example > implementation out of the plumtree module so we don’t ship dependencies > inadvertently. > That second example can be servlet-based if that helps with testing this > out with Jetty. > > Cheers, > > Antoine > > > > On Dec 11, 2022, at 9:22 PM, larry mccay <[email protected]> wrote: > > > > Tuweni Dev's - > > > > I am considering the possibility of a usecase for Plumtree and would like > > to get the community's thoughts. > > > > I'd like multiple servers that have embedded Jetty servers to be able to > be > > aware of each other. I am considering using the gossip protocol support > > provided by the plumtree library in Tuweni. Let's consider this a state > > server usecase for now. > > > > I want to be able to register a new participant with any other > participant > > and that information be propagated across all participating instances. > > Performance isn't necessarily critical due to the nature of the state > being > > replicated in this usecase and we are probably looking at a number in 10s > > of participating nodes rather than anything in 100s or more. > > > > There may also be multiple replication types. For instance, instances > > colocated in the same cluster may need to replicate state that should not > > be replicated to instances in remote deployments while other data should > be. > > > > I'm wondering a couple things: > > > > 1. Does this sound like a valid plumtree usecase? > > 2. Could we get a dev tutorial page for plumtree that is similar to that > > for net [1]? The getting started with plumtree page is currently empty > [2]. > > 3. I have looked at the gossip app sample but have quite got the > > programming model teased out from the app implementation details. The > > general programming mode description in #2 would be helpful. > > 4. Would you recommend using vert.x (as is done in gossip) for this > within > > the Jetty based server or something more native to JEE and/or the Jetty > > server? Jetty specific Handlers would be portable across Jetty servers, > JEE > > servlets or filters or the like would be portable across EE servers. > > Perhaps, if vert.x is the recommendation it would be more appropriate as > a > > custom handler? > > > > I could help flesh out the getting started with plumtree page once I get > > the ball rolling. That is assuming this usecase seems to sound > reasonable. > > > > Thoughts? > > > > thanks! > > > > --larry > > > > 1. > https://tuweni.apache.org/tutorials/networking/getting-started-with-net/ > > 2. > > > https://tuweni.apache.org/tutorials/networking/getting-started-with-plumtree/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
