You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Florent Guillaume <fg...@nuxeo.com> on 2021/02/11 21:50:48 UTC
Modernizing geronimo-transaction
Hi,
Is there any interest in modernizing geronimo-transaction a bit? Is there
any chance of then doing a release in the not too distant future if some
patches get accepted (i.e., is geronimo-transaction completely dead or not)?
FYI my first changes would probably be to allow usage of a java.time.Clock
for time measurement and timeout management, in order to allow better (and
faster) unit testing.
Thanks,
Florent
--
[image: Nuxeo Logo] <https://www.nuxeo.com/>
Florent Guillaume Head of R&D [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>
Nuxeo Content Services Platform. Stay ahead.
[transaction] use Clock to manage time
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi All,
Thanks for your comments. Lovely to see that there's still interest in
geronimo-transaction.
As an example to start the discussion, and because I find that showing code
is in this case clearer, here's an example PR of what could be done using a
Clock.
https://github.com/apache/geronimo-txmanager/pull/5
You'll note that I updated the timeout test, which used to take 15s because
of the sleeps, but is now instantaneous (that's the point of this change).
The overhead of using clock.millis() over System.currentTimeMillis() is
negligible in the default case, because when the clock is the one returned
by Clock.systemUTC() then clock.millis() is just a one-method indirection
to the same System.currentTimeMillis(), which will probably get inlined by
the JIT anyway.
I removed TransactionTimer instead of trying to reuse it because
its getCurrentTime() method was static, so not amenable to subclassing in
tests, and because Clock is already a perfect lightweight time abstraction
-- provided we're ok with requiring Java 8 of course.
Florent
On Fri, Feb 12, 2021 at 8:53 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi,
>
> Using Clock will likely be slower than using System.nanoTime() as of today
> but I assume you want something like
> https://rmannibucau.metawerx.net/post/cdi-mock-java-clock.
> We can surely add a TimeProvider {long now()} or so API we can set in our
> transaction manager and have a default fast impl and a customizable impl
> for tests using clock or so.
> We can also drop the thread measuring the time since, as of today, it is
> not really faster than using currentTimeMillis or other alternatives, we
> just need to avoid Clock and Instant overhead by default but let them be
> pluggable.
> My question would be: is it about timeouts and sufficient for your testing
> use case?
>
> @David Jencks <da...@gmail.com> aout the logger, we already have
> TransactionLog abstraction so I guess we can change it quite easily without
> much code change so can open the door to experimentations.
>
> Something I spoke about some years ago (don't recall it was on our slack
> or IRC) was to make it reactive and drop this thread local requirement.
> Technically there is no reason to have it except some EE assumptions but in
> modern code and with CompletionStages it is quite irrelevant so can be
> another option for our future.
>
> But overall: yes the project is alive, just insanely stable so does not
> move much ;).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le ven. 12 févr. 2021 à 06:53, David Jencks <da...@gmail.com> a
> écrit :
>
>> Something I’ve wondered about since SSD drives became available…
>>
>> When implementing this using HOWL logger, the idea I had was to try to
>> queue up stuff in the transaction log and release the transactions when the
>> disk spun around and claimed to have written the bits onto rust. IIRC
>> there’s a 10 ms time somewhere, which I thought was the time taken to
>> actually write something. I could never find out for sure if the code
>> actually worked and succeeded in defeating the hard drive’s built in
>> caching.
>>
>> Now that SSDs are common, I wonder if a completely different logger
>> implementation would be reasonable. (I haven’t looked at the code in
>> years, but haven’t noticed any changes go by on the mailing list).
>>
>> David Jencks
>>
>> On Feb 11, 2021, at 8:53 PM, Jean-Baptiste Onofre <jb...@nanthrax.net>
>> wrote:
>>
>> Hi Florent,
>>
>> Maybe we can start with a set of Jira or discussion on the mailing list.
>>
>> I think it makes sense to move forward on geronimo-transaction and
>> prepare a new release.
>>
>> Thanks !
>> Regards
>> JB
>>
>> Le 11 févr. 2021 à 22:50, Florent Guillaume <fg...@nuxeo.com> a
>> écrit :
>>
>> Hi,
>>
>> Is there any interest in modernizing geronimo-transaction a bit? Is there
>> any chance of then doing a release in the not too distant future if some
>> patches get accepted (i.e., is geronimo-transaction completely dead or not)?
>>
>> FYI my first changes would probably be to allow usage of a
>> java.time.Clock for time measurement and timeout management, in order to
>> allow better (and faster) unit testing.
>>
>> Thanks,
>> Florent
>>
>> --
>> [image: Nuxeo Logo] <https://www.nuxeo.com/>
>> Florent Guillaume Head of R&D [image: LinkedIn]
>> <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
>> <https://twitter.com/efge> [image: Github] <https://github.com/efge>
>>
>> Nuxeo Content Services Platform. Stay ahead.
>>
>>
>>
>>
--
[image: Nuxeo Logo] <https://www.nuxeo.com/>
Florent Guillaume Head of R&D [image: LinkedIn]
<https://www.linkedin.com/in/fguillaume/> [image: Twitter]
<https://twitter.com/efge> [image: Github] <https://github.com/efge>
Nuxeo Content Services Platform. Stay ahead.
Re: Modernizing geronimo-transaction
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Using Clock will likely be slower than using System.nanoTime() as of today
but I assume you want something like
https://rmannibucau.metawerx.net/post/cdi-mock-java-clock.
We can surely add a TimeProvider {long now()} or so API we can set in our
transaction manager and have a default fast impl and a customizable impl
for tests using clock or so.
We can also drop the thread measuring the time since, as of today, it is
not really faster than using currentTimeMillis or other alternatives, we
just need to avoid Clock and Instant overhead by default but let them be
pluggable.
My question would be: is it about timeouts and sufficient for your testing
use case?
@David Jencks <da...@gmail.com> aout the logger, we already have
TransactionLog abstraction so I guess we can change it quite easily without
much code change so can open the door to experimentations.
Something I spoke about some years ago (don't recall it was on our slack or
IRC) was to make it reactive and drop this thread local requirement.
Technically there is no reason to have it except some EE assumptions but in
modern code and with CompletionStages it is quite irrelevant so can be
another option for our future.
But overall: yes the project is alive, just insanely stable so does not
move much ;).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 12 févr. 2021 à 06:53, David Jencks <da...@gmail.com> a
écrit :
> Something I’ve wondered about since SSD drives became available…
>
> When implementing this using HOWL logger, the idea I had was to try to
> queue up stuff in the transaction log and release the transactions when the
> disk spun around and claimed to have written the bits onto rust. IIRC
> there’s a 10 ms time somewhere, which I thought was the time taken to
> actually write something. I could never find out for sure if the code
> actually worked and succeeded in defeating the hard drive’s built in
> caching.
>
> Now that SSDs are common, I wonder if a completely different logger
> implementation would be reasonable. (I haven’t looked at the code in
> years, but haven’t noticed any changes go by on the mailing list).
>
> David Jencks
>
> On Feb 11, 2021, at 8:53 PM, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Florent,
>
> Maybe we can start with a set of Jira or discussion on the mailing list.
>
> I think it makes sense to move forward on geronimo-transaction and prepare
> a new release.
>
> Thanks !
> Regards
> JB
>
> Le 11 févr. 2021 à 22:50, Florent Guillaume <fg...@nuxeo.com> a
> écrit :
>
> Hi,
>
> Is there any interest in modernizing geronimo-transaction a bit? Is there
> any chance of then doing a release in the not too distant future if some
> patches get accepted (i.e., is geronimo-transaction completely dead or not)?
>
> FYI my first changes would probably be to allow usage of a java.time.Clock
> for time measurement and timeout management, in order to allow better (and
> faster) unit testing.
>
> Thanks,
> Florent
>
> --
> [image: Nuxeo Logo] <https://www.nuxeo.com/>
> Florent Guillaume Head of R&D [image: LinkedIn]
> <https://www.linkedin.com/in/fguillaume/> [image: Twitter]
> <https://twitter.com/efge> [image: Github] <https://github.com/efge>
>
> Nuxeo Content Services Platform. Stay ahead.
>
>
>
>
Re: Modernizing geronimo-transaction
Posted by David Jencks <da...@gmail.com>.
Something I’ve wondered about since SSD drives became available…
When implementing this using HOWL logger, the idea I had was to try to queue up stuff in the transaction log and release the transactions when the disk spun around and claimed to have written the bits onto rust. IIRC there’s a 10 ms time somewhere, which I thought was the time taken to actually write something. I could never find out for sure if the code actually worked and succeeded in defeating the hard drive’s built in caching.
Now that SSDs are common, I wonder if a completely different logger implementation would be reasonable. (I haven’t looked at the code in years, but haven’t noticed any changes go by on the mailing list).
David Jencks
> On Feb 11, 2021, at 8:53 PM, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Florent,
>
> Maybe we can start with a set of Jira or discussion on the mailing list.
>
> I think it makes sense to move forward on geronimo-transaction and prepare a new release.
>
> Thanks !
> Regards
> JB
>
>> Le 11 févr. 2021 à 22:50, Florent Guillaume <fguillaume@nuxeo.com <ma...@nuxeo.com>> a écrit :
>>
>> Hi,
>>
>> Is there any interest in modernizing geronimo-transaction a bit? Is there any chance of then doing a release in the not too distant future if some patches get accepted (i.e., is geronimo-transaction completely dead or not)?
>>
>> FYI my first changes would probably be to allow usage of a java.time.Clock for time measurement and timeout management, in order to allow better (and faster) unit testing.
>>
>> Thanks,
>> Florent
>>
>> --
>> <https://www.nuxeo.com/>
>> Florent Guillaume Head of R&D <https://www.linkedin.com/in/fguillaume/> <https://twitter.com/efge> <https://github.com/efge>
>> Nuxeo Content Services Platform. Stay ahead.
>>
>
Re: Modernizing geronimo-transaction
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Florent,
Maybe we can start with a set of Jira or discussion on the mailing list.
I think it makes sense to move forward on geronimo-transaction and prepare a new release.
Thanks !
Regards
JB
> Le 11 févr. 2021 à 22:50, Florent Guillaume <fg...@nuxeo.com> a écrit :
>
> Hi,
>
> Is there any interest in modernizing geronimo-transaction a bit? Is there any chance of then doing a release in the not too distant future if some patches get accepted (i.e., is geronimo-transaction completely dead or not)?
>
> FYI my first changes would probably be to allow usage of a java.time.Clock for time measurement and timeout management, in order to allow better (and faster) unit testing.
>
> Thanks,
> Florent
>
> --
> <https://www.nuxeo.com/>
> Florent Guillaume Head of R&D <https://www.linkedin.com/in/fguillaume/> <https://twitter.com/efge> <https://github.com/efge>
> Nuxeo Content Services Platform. Stay ahead.
>