Yep, thinking about it we can need something flexible on that area (exact vs approximative but lock free for instance). A bench would say it ;)
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-09-05 15:07 GMT+02:00 John D. Ament <[email protected]>: > MP Fault Tolerance requires both semaphore and threadpool based > bulkheads. What you have in DeltaSpike is the semaphore approach (guarding > based on the calling thread count). > > Agreed that its not a general solution, its specific to bulkhead based use > cases (where you want to limit the number of callers to a specific > component). > > John > > > On Tue, Sep 5, 2017 at 8:02 AM Romain Manni-Bucau <[email protected]> > wrote: > >> Hmm, I would need more details on what you want to build cause semaphores >> are not always the best for fault tolerances. let me try tp put some >> thought in a bullet list and maybe start discussing from it to try to be >> more precise: >> >> - JWT: I'd really go without any lib, it is easy to impl on top of java 8 >> and avoid to bring in jackson/jose/jjwt and other libs we likely dont want >> to enforce for stack consistency >> - health checker: here we need to be very careful about 2 things: do we >> want a light monitoring with an aggregated view where healthchecks and >> gauges are great or do we want an event based monitoring where >> healthchecks, gauges and counters are useless since the aggregation is done >> somewhere else (kibana, splunk and a lot of others) >> - fault tolerance: here I know 2 different ways to do: local fallback or >> remote failover, it is mainly just a way to replace a service call by a >> list through an interceptor (in CDI) - sorting impl with @Priority is quite >> nice BTW. Only trick is how to handle exception (the parsing needs to be a >> bit clever to detect 500 etc...) >> - ^^ is likely linked to circuit breakers, the simple one of [lang3] can >> be a good start >> >> It is random thoughts based on my last 5 years so don't read it as "it is >> the right way" but more as an experience feedback. >> >> >> >> Romain Manni-Bucau >> @rmannibucau <https://twitter.com/rmannibucau> | Blog >> <https://blog-rmannibucau.rhcloud.com> | Old Blog >> <http://rmannibucau.wordpress.com> | Github >> <https://github.com/rmannibucau> | LinkedIn >> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory >> <https://javaeefactory-rmannibucau.rhcloud.com> >> >> 2017-09-05 13:52 GMT+02:00 John D. Ament <[email protected]>: >> >>> Cool, git repo's been requested. >>> >>> @Romain I will need your input. You had implemented semaphores in >>> deltaspike, including that in this project would help align better to the >>> bulkhead requirements. Any concerns if we base some logic off of that? A >>> lot can get cleaned up in the mean time since we can base on Java 8. >>> >>> John >>> >>> On Tue, Sep 5, 2017 at 6:27 AM Mark Struberg <[email protected]> wrote: >>> >>>> +1 go ahead. Happy to help! >>>> >>>> LieGrue, >>>> Strub >>>> >>>> Am 05.09.2017 um 01:56 schrieb John D. Ament <[email protected]>: >>>> >>>> Gah zombie thread. >>>> >>>> So I want to pick back up at least with fault tolerance. Would anyone >>>> be opposed to starting up a repo on it? I'm thinking of the name >>>> "Safeguard" so that it would either be "org.apache.safeguard" or >>>> "org.apache.geronimo.safeguard" as group id in maven (xbean uses the >>>> former, config the latter). >>>> >>>> I've given it a bit more thought as well. While I'm cautious about >>>> Failsafe's future, its something where we can start off as a dependency and >>>> grow and replace, or look to get a grant or just import the source code >>>> leaving the original headers if need be. >>>> >>>> I do have a preference to create this as a git repo. >>>> >>>> John >>>> >>>> On Tue, Aug 1, 2017 at 4:45 AM Mark Struberg <[email protected]> wrote: >>>> >>>>> I would love implementing the mp jwt spec at Geronimo. >>>>> But I've not closely followed the discussions and current state. >>>>> So I cannot really make an educated guess right now about whether it >>>>> already makes sense to implement it. >>>>> >>>>> Although I think it cannot be wrong to start tinkering with it in a >>>>> seperate component. >>>>> And then we know a lot better what it is able to and what not. >>>>> This is not yet a guarantee that we release anything in that direction. >>>>> But by playing with it we don't loose anything. An the worst case we >>>>> learn a lot ;) >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> > Am 30.07.2017 um 23:58 schrieb Romain Manni-Bucau < >>>>> [email protected]>: >>>>> > >>>>> > >>>>> > >>>>> > Le 30 juil. 2017 23:54, "John D. Ament" <[email protected]> a >>>>> écrit : >>>>> > >>>>> > >>>>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau < >>>>> [email protected]> wrote: >>>>> > Is there any actual spec? >>>>> > >>>>> > Not sure what you mean. Rhetorical question? >>>>> > >>>>> > No no, for now MP is a lot of marketing - server part is nothing for >>>>> instance. If no spec but future specs I d wait it is close to release. >>>>> > >>>>> > >>>>> > >>>>> > For jwt we can impl from scratch, it is not hard and would avoid a >>>>> big dep and enable some consistency using jsonb. >>>>> > >>>>> > JWT is a lot more complicated than that. It's more than reading the >>>>> JSON, but also ensuring proper crypto signatures, on the generation and >>>>> consumption side. You need to be able to reach out to other servers to >>>>> fetch keys and handle extra validation checks. There's a standard set of >>>>> claims that's being requested as well. Yes, the json smart dependency >>>>> bites, maybe we can convince the author to switch to the javax.json >>>>> namespace? >>>>> > >>>>> > It is trivial to impl on java once you have json link, ~200 lines >>>>> for the needed part. Javax.json is maybe not rigyt bit building on it >>>>> sounds right - actually did on johnzon with quite successes. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > Le 30 juil. 2017 23:28, "John D. Ament" <[email protected]> a >>>>> écrit : >>>>> > All, >>>>> > >>>>> > I know Mark brought in Config to Geronimo. We have at least 3 more >>>>> specs coming in MP 1.2 (Fault Tolerance, Health, JWT Processing), possibly >>>>> Metrics and OpenTracing. >>>>> > >>>>> > I have a fully functioning JWT Processing impl based on jose ( >>>>> https://bitbucket.org/connect2id/nimbus-jose-jwt/src ) which I'd be >>>>> happy to bring over to Geronimo. >>>>> > >>>>> > Health is a tricky one, may make sense to start from scratch, or >>>>> bring in pieces of the former Sirona podling to start a health checker. >>>>> > >>>>> > I had started on a Fault Tolerance implementation, based on the work >>>>> from failsafe. However, from talking to the developer offline I'm a bit >>>>> worried about relying on Failsafe. >>>>> > >>>>> > Any thoughts on bringing these into Geronimo? >>>>> > >>>>> > John >>>>> > >>>>> > >>>>> >>>>> >>
