profile
viewpoint

bijukunjummen/boot2-load-demo 71

Demonstrates a load test with Spring Boot 2

bijukunjummen/AOP-Samples 14

AOP Samples - different ways of writing Aspects

bijukunjummen/algos 12

A collection of algorithms

bijukunjummen/ci-concourse-caching-sample 9

Demo of caching feature in Concourse - for Gradle and Maven based projects

bijukunjummen/circuit-breaker-sample 7

Sample using Netflix Hystrix libraries @HystrixCommand annotation with Spring-Boot

bijukunjummen/blog-boot-project 5

Boot with Kotlin

bijukunjummen/boot2-with-junit5-sample 5

Sample demonstrating Junit 5 with Spring Boot2 based app

bijukunjummen/akka-scala-spring 4

akka-scala-spring

push eventbijukunjummen/reactive-cities-demo

Biju Kunjummen

commit sha e92f34abefa71912b4afcac37a9616b93e6b8967

Adds expand sample

view details

push time in 17 hours

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

@nicmunroe, this should be good to merge now?

bijukunjummen

comment created time in 15 days

push eventbijukunjummen/webclient-hystrix-sample

Biju Kunjummen

commit sha 2c0929e5c5b4d0c40b7b6b386752c4f5ccdda4cf

Adds sample for WebClient.Builder customization

view details

push time in a month

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

Yes, it is good for one more round of review @nicmunroe - the failure was fixed after the hooks were explicitly cleared after every test:

Schedulers.removeExecutorServiceDecorator(...);

There is a new flag to enable the feature and the details of the flag has been documented.

bijukunjummen

comment created time in 2 months

push eventbijukunjummen/reactive-cities-demo

Biju Kunjummen

commit sha 9ddb33cb6daf6e3232ad281bd11445ccb07a3f2b

Tuple samples

view details

push time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 92909d85e87aa71281691921b82f2a60b9fcf75a

Does not return a null bean

view details

push time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 19c17a40443ba18fc46d57aeb56dff2822279818

Adds one more explicit removal of decorator in test

view details

push time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 1af5d667340631fab40b2b133790b70e1677dc2f

Explicitly removes schedule decorator between tests

view details

push time in 2 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

Getting a failing test - trying to figure out how to clear the scheduler cache, doesn't look like using a Schedulers.newElastic(..) is helping, checking why.

bijukunjummen

comment created time in 2 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

As far as moving the wingtips+project reactor registration to WingtipsSpringBoot2WebfluxConfiguration, that seems good, except I'd want to see the ability to enable/disable it via application properties (WingtipsSpringBoot2WebfluxProperties).

I'm on the fence on whether it should be enabled or disabled by default. I'm leaning towards disabled due to the subtle behavior concerns we've been discussing - those issues make me think it should be opt-in for users who are aware of when it will work and when it won't.

Yes, I feel disabled could be the right default too. I have now added support to take in a property to enable the feature.

Which brings up another point - these subtleties should be called out in the readme for this module. Yes, good call. Fixed readme also

bijukunjummen

comment created time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 381a549e529259ea0139cb65b83c8dbc2bd4bb92

Disables reactor support by default, additional tests

view details

push time in 2 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

The only way the ScheduledExecutorServiceWithTracing wrapping works is if the correct tracing state is on the thread at the site of subscription, not where the Mono/Flux is defined. This is ok if you have full control over where your Mono/Flux is subscribed to, and you understand this subtlety. But it severely limits effectiveness in other scenarios. For example: in a SB2 endpoint you could return a Mono and have the WingtipsReactorConfiguration registered so you'd think it would all "just work". But it falls apart as soon as you do something that causes SB2 to subscribe on a different thread, like putting a @RequestBody arg into your endpoint method. I could see this leading to a lot of confusion. That said I can see how this PR would be useful for some users in some scenarios, so I don't want to just say no to this PR. Thoughts?

Got a chance to test a method with normal Webflux endpoints. You are right, reactor does not appear to use the scheduler hooks at all for Webflux endpoints. But I noticed that WingtipsSpringWebfluxWebFilter that is part of WingtipsReactorConfiguration does work for those endpoints and any explicit subscribeOn, publishOn work off the hooks.

bijukunjummen

comment created time in 2 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

@bijukunjummen I took a quick look, and here are a few things I noticed. These may or may not be showstoppers - hard for me to say since I don't personally do much with project reactor. But in any case:

  1. Project reactor seems to be doing things with caching executors. So if, for example, an ElasticScheduler (like the default Schedulers.elastic()) is created and used before Schedulers.addExecutorServiceDecorator(...) is called to register the new wingtips ScheduledExecutorServiceWithTracing, then the old regular executor is used forever and always and the decorator you wanted is ignored. i. This is probably not a big deal for many SB2 apps, as the WingtipsReactorConfiguration will probably do its thing before any of this caching takes effect...

Yes, I think this is a fair assumption. I see this being useful only in Spring Boot 2 based projects and the initializer will ensure that the hook takes effect before any of the reactor library functions are used.

ii. ...But it does make tests potentially dependent on test ordering, since the hooks are all static and the tests run in the same JVM. If they execute in the wrong order, then we could get intermittent failures. For example, if you run the WingtipsSpringBoot2WebfluxConfigurationTest.reactor_async_trace_propagation(...) test by itself, they'll all fail. But if you reorder the dataprovider for that test so that MANUAL_IMPORT_ONLY is not first, then they all pass. So the fact that this branch builds successfully is by accident, as some other test must be setting the hook before this test runs. And I've definitely seen tests executed in different orders depending on platform. That makes me really uncomfortable.

Ah, nice catch. I think the reason was that for manual_import_only WingtipsSpringBoot2WebfluxConfiguration is the only configuration being imported and I had put the hook configuration into a separate configuration altogether. I have now added the initializer bean also into the same WingtipsSpringBoot2WebfluxConfiguration configuration. So the test should consistently pass and the order should not matter.

iii. As far as I can tell it's impossible to clear this caching once it's done. I'd like to be wrong, and maybe there's a proper official Project Reactor way to reset/clear this kind of cache? 🤷‍♂

Yes, I don't entirely understand how the internal caching works but will do a little more research.

  1. The only way the ScheduledExecutorServiceWithTracing wrapping works is if the correct tracing state is on the thread at the site of subscription, not where the Mono/Flux is defined. This is ok if you have full control over where your Mono/Flux is subscribed to, and you understand this subtlety. But it severely limits effectiveness in other scenarios. For example: in a SB2 endpoint you could return a Mono and have the WingtipsReactorConfiguration registered so you'd think it would all "just work". But it falls apart as soon as you do something that causes SB2 to subscribe on a different thread, like putting a @RequestBody arg into your endpoint method. I could see this leading to a lot of confusion.

That said I can see how this PR would be useful for some users in some scenarios, so I don't want to just say no to this PR. Thoughts?

Yes, good point. I believe though that ScheduledExecutorServiceWithTracing is always called at the point of subscription. I will double check and get back. I have a project which using a subset of this functionality with @RequestBody, I will check how the functionality works there and get back.

bijukunjummen

comment created time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 5e1a45f2771b197580b80aa3f0c99cfc8b4ff62c

Fixes location of reactor hook configuration

view details

push time in 2 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

@bijukunjummen I took a quick look, and here are a few things I noticed. These may or may not be showstoppers - hard for me to say since I don't personally do much with project reactor. But in any case:

  1. Project reactor seems to be doing things with caching executors. So if, for example, an ElasticScheduler (like the default Schedulers.elastic()) is created and used before Schedulers.addExecutorServiceDecorator(...) is called to register the new wingtips ScheduledExecutorServiceWithTracing, then the old regular executor is used forever and always and the decorator you wanted is ignored. i. This is probably not a big deal for many SB2 apps, as the WingtipsReactorConfiguration will probably do its thing before any of this caching takes effect... ii. ...But it does make tests potentially dependent on test ordering, since the hooks are all static and the tests run in the same JVM. If they execute in the wrong order, then we could get intermittent failures. For example, if you run the WingtipsSpringBoot2WebfluxConfigurationTest.reactor_async_trace_propagation(...) test by itself, they'll all fail. But if you reorder the dataprovider for that test so that MANUAL_IMPORT_ONLY is not first, then they all pass. So the fact that this branch builds successfully is by accident, as some other test must be setting the hook before this test runs. And I've definitely seen tests executed in different orders depending on platform. That makes me really uncomfortable. iii. As far as I can tell it's impossible to clear this caching once it's done. I'd like to be wrong, and maybe there's a proper official Project Reactor way to reset/clear this kind of cache? 🤷‍♂
  2. The only way the ScheduledExecutorServiceWithTracing wrapping works is if the correct tracing state is on the thread at the site of subscription, not where the Mono/Flux is defined. This is ok if you have full control over where your Mono/Flux is subscribed to, and you understand this subtlety. But it severely limits effectiveness in other scenarios. For example: in a SB2 endpoint you could return a Mono and have the WingtipsReactorConfiguration registered so you'd think it would all "just work". But it falls apart as soon as you do something that causes SB2 to subscribe on a different thread, like putting a @RequestBody arg into your endpoint method. I could see this leading to a lot of confusion.

That said I can see how this PR would be useful for some users in some scenarios, so I don't want to just say no to this PR. Thoughts?

Thanks for your thoughtful feedback @nicmunroe. I will get back soon

bijukunjummen

comment created time in 2 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha f06a099ccab68da646781d19a12f7509c31524d7

Adds tracing support to async boundaries in reactor-core Co-authored-by: RDBreed <rafaelabreed@gmail.com>

view details

push time in 3 months

push eventbijukunjummen/wingtips

Biju Kunjummen

commit sha 75120f6d2184a6be819642910c89483385f3808c

Adds tracing support to async boundaries in reactor-core Co-authored-by: RDBreed <rafaelabreed@gmail.com>

view details

push time in 3 months

pull request commentNike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

Hey @bijukunjummen ! Thanks for the contribution. We'll try to get to this soon. In the meantime, you'll need to sign the CLA before we can accept this PR.

Thanks @nicmunroe , I have signed the CLA now.

bijukunjummen

comment created time in 3 months

PR opened Nike-Inc/wingtips

Adds tracing support to async boundaries in reactor-core

Spring's project-reactor provides a powerful set of operators that abstracts some of the async operations behind very simple operators (like map, flatMap). This PR adds support for propagating tracing details across thread boundaries using reactor's operators.

+803 -0

0 comment

4 changed files

pr created time in 3 months

create barnchbijukunjummen/wingtips

branch : reactor-core-tracing

created branch time in 3 months

fork bijukunjummen/wingtips

Wingtips is a distributed tracing solution for Java based on the Google Dapper paper.

fork in 3 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha a25a33471c433329d0eb4aa7f74b0baed3bd667a

Polish

view details

push time in 3 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha dc04021cd63dec5dc6af3bfa4a96b13224e65839

Resolves test via spring bom

view details

push time in 4 months

created tagbijukunjummen/json-hash

tagv0.5.0

Utility for hashing a Jackson JsonNode

created time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha 1766b6627b3b7c114a14bedc1b103ebf02df5225

Without dep plugin

view details

push time in 4 months

created tagbijukunjummen/json-hash

tagv0.4.0

Utility for hashing a Jackson JsonNode

created time in 4 months

created tagbijukunjummen/json-hash

tagv0.3.0

Utility for hashing a Jackson JsonNode

created time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha 8ae10d7f55f30e50f6c957d5b09786d247ae21a0

Polish

view details

push time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha c610518c12fe95d4bdddbad4c1f7df14d05ef904

Sources

view details

push time in 4 months

created tagbijukunjummen/json-hash

tagv0.2.0

Utility for hashing a Jackson JsonNode

created time in 4 months

created tagbijukunjummen/json-hash

tagv0.1.0

Utility for hashing a Jackson JsonNode

created time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha 46b8058c14bc3b3df5571a69d1efce9066c6054d

Maven install tweaks

view details

Biju Kunjummen

commit sha ddd3172ba73f2d2cc6bca0b94013a519f9be1b8e

Maven plugin

view details

push time in 4 months

created tagbijukunjummen/json-hash

tagv0.1.0-rc.2

Utility for hashing a Jackson JsonNode

created time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha 6135abaa6815f287b0872033197d3afaa6a6d938

Adds in bintray tasks

view details

Biju Kunjummen

commit sha b4eb844310f8b6b91e4a16de5f103a0c9e987f2f

Bintray tweaks

view details

push time in 4 months

created tagbijukunjummen/json-hash

tagv0.1.0-rc.1

created time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha 0f6e7825a3233604932438ea68948a57b0932494

Fixes formatting

view details

push time in 4 months

push eventbijukunjummen/json-hash

Biju Kunjummen

commit sha a9a58b788520ee7eed695ea224f2118c5c7848ba

Base functionality for hashing jsonnode

view details

push time in 5 months

create barnchbijukunjummen/json-hash

branch : master

created branch time in 5 months

created repositorybijukunjummen/json-hash

created time in 5 months

push eventbijukunjummen/webclient-hystrix-sample

Biju Kunjummen

commit sha e7c2b885f06d7b026f4ba536133d7a429e7e1920

More samples

view details

push time in 5 months

more