geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Other MP Specs @ Geronimo?
Date Tue, 05 Sep 2017 13:11:19 GMT
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 <johndament@apache.org>:

> 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 <rmannibucau@gmail.com>
> 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 <johndament@apache.org>:
>>
>>> 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 <struberg@yahoo.de> wrote:
>>>
>>>> +1 go ahead. Happy to help!
>>>>
>>>> LieGrue,
>>>> Strub
>>>>
>>>> Am 05.09.2017 um 01:56 schrieb John D. Ament <johndament@apache.org>:
>>>>
>>>> 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 <struberg@yahoo.de> 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 <
>>>>> rmannibucau@gmail.com>:
>>>>> >
>>>>> >
>>>>> >
>>>>> > Le 30 juil. 2017 23:54, "John D. Ament" <johndament@apache.org>
a
>>>>> écrit :
>>>>> >
>>>>> >
>>>>> > On Sun, Jul 30, 2017 at 5:44 PM Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> 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" <johndament@apache.org>
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
>>>>> >
>>>>> >
>>>>>
>>>>>
>>

Mime
View raw message