These are chat archives for spring-cloud/spring-cloud

29th
Nov 2016
Stefan Pfeiffer
@dl1ely
Nov 29 2016 12:09
I want to use Spring Cloud Bus to broadcast Subclasses of RemoteApplicationEvent to all my microservices. They get deserialized based on their simpleName. I have them in shared package (Using @RemoteEventScan). All works fine except when i introduce a new event subtype and not every microservice knows about it. They throw deserialization exceptions then. Is there a way to solve that gracefully? I cannot update all microservices (that are not interested in that new event) that listen on the bus just because one new event gets introduced.
Spring Cloud Bus Docs say both Producer and Consumer must have access to the event class definition, which is fine when the consumer needs to make sense out of the event, but is there a way to ignore non-deserializable subclasses of RemoteApplicationEvent?
Dave Syer
@dsyer
Nov 29 2016 12:55
Maybe not. You could add that feature if you want.
Stefan Pfeiffer
@dl1ely
Nov 29 2016 13:07
Thanks. Unfortunately i have no solid idea how to tackle that :-)
Stefan Pfeiffer
@dl1ely
Nov 29 2016 13:20
But nice to hear i did not miss something obvious. I will think about that problem then
Dave Syer
@dsyer
Nov 29 2016 13:22
Can you open an issue in github?
Stefan Pfeiffer
@dl1ely
Nov 29 2016 13:42
I will
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:00
Well, looks like i can register my own bean of name busJsonConverter that implements convertFromInternala little more gracefully for my case.
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:07
Unfortunately, BusJacksonMessageConverter is a non-public class in BusJacksonAutoConfiguration.java which prevents me from extending it and reusing all the boilerplate stuff it has to implement -(
Dave Syer
@dsyer
Nov 29 2016 15:33
Life sucks sometimes
If it works, then you know how to create a PR, I guess
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:37
Doesn't work, as other MessageConverters down the chain kick in if i do not throw an exception in BusJacksonMessageConverter, and MappingJackson2MassageConverter takes over for the base type RemoteApplicationEvent, but still cannot resolve the type id of my concrete event class.
Obviously i am fighting an uphill battle here :-)
Dave Syer
@dsyer
Nov 29 2016 15:39
Maybe it's better to convert it to something that can be ignored (i.e. not throw an exception)?
Ideally you'd want to react to it in some way. So the owner of the app knows there are new events to consume.
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:40
Yes, i wanted to log a single line about the onknown event, instead of the monstrous exception, but i see that is the wrong angle to attack
I wanted to keep the @StreamListener(…) acceptRemote(RemoteApplicationEvent event) dispatcher call, but that forces me to convert to RemoteApplicationEvent. I had hoped to discard the message when the message converter returns null.
Dave Syer
@dsyer
Nov 29 2016 15:44
I guess that's a spring-cloud-stream feature
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:44
It is.
Dave Syer
@dsyer
Nov 29 2016 15:45
Pinging @mbogoevici
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:46
So i guess it might be better to implement my own @StreamListener(…) acceptRemote(Tuple data) dispatcher call, getting the type info from the tuple, decide on myself if i can convert that class given the ObjectMapper at hand, and selectively publish the remote event in my application (or not)
But if i go that far, i can use my own exchange and my own RemoteEvent Base class :worried: I had hopes i could piggyback on the Bus infrastructure by subclassing its RemoteEvent. But being resilient to unknown Event Types in the system seems to be harder than expected :-)
Stefan Pfeiffer
@dl1ely
Nov 29 2016 15:53
Its all no problem if all participants on the bus see the same domain model of events, so they can deserialize everything they get served from the bus. If not, things seem to get hairy. I could just let the exceptions pop up, but OPs won't like these masses of exceptions from services regarding events they don't even care about.
Another road to go might be routing of Events based on their type in RabbitMQ itself, so that every service only subscribes to exchanges that serve Events of types it knows. But that will get out of hand quickly with increasing event types. But now i have input for further thought.
Thank you.
pradeepkusingh
@pradeepkusingh
Nov 29 2016 16:39
@dsyer - We are trying to implement Oauth2 JWT, I have one qq.. if Auth server goes down then what is the best failover strategy ?
Dave Syer
@dsyer
Nov 29 2016 16:59
Redundancy?
Cloud Foundry generally runs with 2 instances.
It's never been an issue
pradeepkusingh
@pradeepkusingh
Nov 29 2016 18:10
Auth server is maintain by another team a product call ping federate.. if we loose network connectivity then it will stop my apps to serve consumers. so was looking for some fallback options.
sorri if I was not clear enough on my first post
sorry
Dave Syer
@dsyer
Nov 29 2016 18:11
Seems like an operational concern. Nothing specifically to do with Spring Cloud?
If you don't trust the ping product maybe you need to run your own auth server
pradeepkusingh
@pradeepkusingh
Nov 29 2016 18:29
ok, Thanks Dave
Marius Bogoevici
@mbogoevici
Nov 29 2016 23:54
@dl1ely @dsyer at least at Stream level, I don’t feel we should silently discard messages if we don’t know what to do with them - that’s an application concern. Maybe in this cases the converter could just return an UnknownRemoteApplicationEvent instance (fallback type that could be part of spring-cloud-bus) wrapping the original payload and give the user an option to react or ignore ?