custom Nano time provider

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

custom Nano time provider

JSR166 Concurrency mailing list
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
Java 8 introduced the java.time.Clock API. This can replace
currentTimeMillis for ease of testing.

I don't think such an API exists for nanoTime. I'm not sure how
realistic such an API would be since users of nanoTime are presumably
interested in accuracy.

- Jonas

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:

> Hi folks,
>
> In the recent period I am working on some high availability solution in
> the project I currently work and I have noticed how is important for
> testing purposes to use custom System::currentTimeMillis and
> System::nanoTime providers to trigger specific reproducible conditions:
> there is any plan to allow something similar in some of the concurrent
> primitive that make uses of such functions?
> I believe this could help both implementors and users.
>
>
> Thanks,
> Franz
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
Thanks Jonas,

I am aware of such API, but my request is to allow the existing primitives that uses System::nanoTime and System::currentTimeMillis (eg many lock implementations) to uses a custom time provider.

Il dom 5 apr 2020, 13:34 Jonas Konrad via Concurrency-interest <[hidden email]> ha scritto:
Java 8 introduced the java.time.Clock API. This can replace
currentTimeMillis for ease of testing.

I don't think such an API exists for nanoTime. I'm not sure how
realistic such an API would be since users of nanoTime are presumably
interested in accuracy.

- Jonas

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
> Hi folks,
>
> In the recent period I am working on some high availability solution in
> the project I currently work and I have noticed how is important for
> testing purposes to use custom System::currentTimeMillis and
> System::nanoTime providers to trigger specific reproducible conditions:
> there is any plan to allow something similar in some of the concurrent
> primitive that make uses of such functions?
> I believe this could help both implementors and users.
>
>
> Thanks,
> Franz
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
Yes, having the ability to control the flow of time as perceived by JDK concurrency classes would facilitate writing concurrency tests. Though I hope that those classes do not use currentTimeMilllis under the hood because it shouldn't be used to measure duration. And those 3rd party classes that need to use currentTimeMillis (e.g. Spring cron-style scheduling) can use Clock and provide ways of supplying custom Clock implementations.

Valentin

------------------------------

Message: 3
Date: Sun, 5 Apr 2020 13:44:54 +0200
From: Francesco Nigro <[hidden email]>
To: Jonas Konrad <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] custom Nano time provider
Message-ID:
        <CAKxGtTWo9=2GwaBm8jemanBjWzbiiW7Lp-kkV1FW8=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Thanks Jonas,

I am aware of such API, but my request is to allow the existing primitives
that uses System::nanoTime and System::currentTimeMillis (eg many lock
implementations) to uses a custom time provider

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list

Hello

To expand on Peters answer: For testing purpose to get reproducible results you might to look into some mocking frameworks.

For example in jmockit i can just do this

final MockUp mockUp = new MockUp(System.class) {
    @Mock
    long nanoTime() {
        return 1234;
    }
};
System.out.println(" = " + System.nanoTime());

Boom custom nanoTime Provider.

Best regards,

Thorsten Goetzke

Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
How does that work for a sequence of timestamps you want to feed? (Assuming you will need some j.u.c.Queue for this...)

Alex

On Mon, 6 Apr 2020, 11:54 Thorsten via Concurrency-interest, <[hidden email]> wrote:

Hello

To expand on Peters answer: For testing purpose to get reproducible results you might to look into some mocking frameworks.

For example in jmockit i can just do this

final MockUp mockUp = new MockUp(System.class) {
    @Mock
    long nanoTime() {
        return 1234;
    }
};
System.out.println(" = " + System.nanoTime());

Boom custom nanoTime Provider.

Best regards,

Thorsten Goetzke

Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
[hidden email] 
I was gong to write exactly the same :)

That's why I still think it would beneficial to have something different from a mocked solution, but a proper API extension that unify the usage of temporal info.
From the POV of performance it shouldn't be a big problem, given that a real system is supposed to always use a single provide (and implementor) making the actual call always monomorphic and (given that should just wrap System::nanotTime)
trivially inlineable.

Il giorno lun 6 apr 2020 alle ore 14:19 Alex Otenko <[hidden email]> ha scritto:
How does that work for a sequence of timestamps you want to feed? (Assuming you will need some j.u.c.Queue for this...)

Alex

On Mon, 6 Apr 2020, 11:54 Thorsten via Concurrency-interest, <[hidden email]> wrote:

Hello

To expand on Peters answer: For testing purpose to get reproducible results you might to look into some mocking frameworks.

For example in jmockit i can just do this

final MockUp mockUp = new MockUp(System.class) {
    @Mock
    long nanoTime() {
        return 1234;
    }
};
System.out.println(" = " + System.nanoTime());

Boom custom nanoTime Provider.

Best regards,

Thorsten Goetzke

Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list

You can replace 1234 with whatever logic you want ,  so  yes a queue seems a natural choice

final MockUp mockUp = new MockUp(System.class) {
    private final Queue<Long> objects = new LinkedBlockingQueue(List.of(12L, 144L));

    @Mock
    long nanoTime() {
        return objects.poll();
    }
};
System.out.println(" = " + System.nanoTime()); //12
System.out.println(" = " + System.nanoTime()); // 144
System.out.println(" = " + System.nanoTime()); // dies miserably

Or he what about this

final MockUp mockUp = new MockUp(System.class) {
    private final Iterator<Long> objects = LongStream.iterate(20, x -> x + 1).iterator();

    @Mock
    long nanoTime() {
        return objects.next();
    }
};

> That's why I still think it would beneficial to have something different from a mocked solution, but a proper API extension that unify the usage of temporal info.

I kind of fail to see how that would work differently from what you can do with Mocks.  You get your callback and you can do whatever you want and if your code is stupid enough you might blow up your application ;)

I dont't whant to argue about this, just showcasing for reference that one can return reproducible values from System#nanoTime without to much effort and without requiring a new API.

Best regards,

Thorsten

Am 06/04/2020 um 14:18 schrieb Alex Otenko:
How does that work for a sequence of timestamps you want to feed? (Assuming you will need some j.u.c.Queue for this...)

Alex

On Mon, 6 Apr 2020, 11:54 Thorsten via Concurrency-interest, <[hidden email]> wrote:

Hello

To expand on Peters answer: For testing purpose to get reproducible results you might to look into some mocking frameworks.

For example in jmockit i can just do this

final MockUp mockUp = new MockUp(System.class) {
    @Mock
    long nanoTime() {
        return 1234;
    }
};
System.out.println(" = " + System.nanoTime());

Boom custom nanoTime Provider.

Best regards,

Thorsten Goetzke

Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: custom Nano time provider

JSR166 Concurrency mailing list
Well, mock will work only if you know the Queue is not going to call nanoTime. As such, this is a dangerous assumption. 

Alex

On Mon, 6 Apr 2020, 13:52 Thorsten via Concurrency-interest, <[hidden email]> wrote:

You can replace 1234 with whatever logic you want ,  so  yes a queue seems a natural choice

final MockUp mockUp = new MockUp(System.class) {
    private final Queue<Long> objects = new LinkedBlockingQueue(List.of(12L, 144L));

    @Mock
    long nanoTime() {
        return objects.poll();
    }
};
System.out.println(" = " + System.nanoTime()); //12
System.out.println(" = " + System.nanoTime()); // 144
System.out.println(" = " + System.nanoTime()); // dies miserably

Or he what about this

final MockUp mockUp = new MockUp(System.class) {
    private final Iterator<Long> objects = LongStream.iterate(20, x -> x + 1).iterator();

    @Mock
    long nanoTime() {
        return objects.next();
    }
};

> That's why I still think it would beneficial to have something different from a mocked solution, but a proper API extension that unify the usage of temporal info.

I kind of fail to see how that would work differently from what you can do with Mocks.  You get your callback and you can do whatever you want and if your code is stupid enough you might blow up your application ;)

I dont't whant to argue about this, just showcasing for reference that one can return reproducible values from System#nanoTime without to much effort and without requiring a new API.

Best regards,

Thorsten

Am 06/04/2020 um 14:18 schrieb Alex Otenko:
How does that work for a sequence of timestamps you want to feed? (Assuming you will need some j.u.c.Queue for this...)

Alex

On Mon, 6 Apr 2020, 11:54 Thorsten via Concurrency-interest, <[hidden email]> wrote:

Hello

To expand on Peters answer: For testing purpose to get reproducible results you might to look into some mocking frameworks.

For example in jmockit i can just do this

final MockUp mockUp = new MockUp(System.class) {
    @Mock
    long nanoTime() {
        return 1234;
    }
};
System.out.println(" = " + System.nanoTime());

Boom custom nanoTime Provider.

Best regards,

Thorsten Goetzke

Am 06/04/2020 um 11:55 schrieb Peter Levart via Concurrency-interest:
You could perhaps use bytecode instrumentation (https://www.baeldung.com/java-instrumentation) to "patch" System class and redirect/delegate it's execution to your custom time source.

Peter

On 4/5/20 1:23 PM, Francesco Nigro via Concurrency-interest wrote:
Hi folks,

In the recent period I am working on some high availability solution in the project I currently work and I have noticed how is important for testing purposes to use custom System::currentTimeMillis and System::nanoTime providers to trigger specific reproducible conditions: there is any plan to allow something similar in some of the concurrent primitive that make uses of such functions?
I believe this could help both implementors and users.


Thanks,
Franz

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest