These are chat archives for paypal/squbs
squbs-httpclientlevel by default (not at template level).
squbs-httpclientlevel as it cannot have
ExtensionLifecycle, as it is unaware of unicomplex
squbs-httpclient; however, need to register it at the template level. It would be great if it got registered at
squbs-httpclientlevel. One way I can try is to make
ResolverRegistryExtensionaccessible, then call it inside
CilentFlow, if it cannot find it, register the default one. But, that also goes against the overall design. We should let teams to unregister a resolver if you want to. We cannot force a special resolve to be always there.
squbs-httpclient; however, the solutions there won’t be clean. So, doing it at the template level might be ok for now. However, we also need to think about the scenario where
squbs-httpclientis used outside of the squbs ecosystem (as it only needs an actor system). In such scenario, the very first experience would be invalid endpoint resolution, which I really do not like..
checkAndRecordShortCircuit()name change. Your point is very valid; however, I am not very sure about the method name including something with metric recording.
DefaultHttpEndpointResolverpaypal/squbs#396. I would like to update the doc here https://github.com/paypal/squbs/blob/master/docs/httpclient.md#service-discovery-chain. But, before that I need to find a way to register this resolver by default in
squbs-httpclient. We discussed that one way is to make
ClientFlowan Akka Extension; however, that would make the API look more different than Akka HTTP client and not sure if it is worth to make it an extension just for this change. Any other alternatives you can think of ?
squbs-httpclientshould not bring
logback.xml. Unless you have any objections, I will delete it. Also, the commit message suggests that it was checked in when the module was created. Accordingly, I assume it was accidental ?
DefaultHttpEndpointResolver, I actually take it back. I will convert
ClientFlowto an Akka Extension. We anyway pass
ActorSystemcurrently (so it slightly differs from Akka HTTP Client API). Moving
ClientFlowextension style would not make it any worse, might even improve it.
logback.xmlI think it was there before open source, in error. Please remove.
ActorSystemwas because it is already an Akka Extension. Looks like I'm wrong. So at least it won't hurt to make it an extension. But lets also keep thinking about alternate solves.
HttpClientPipeline.scala.waiting(it can stay "waiting" a little longer). Couple of things on hand and including fixing the coverage uploads.
ClientFlow to an Akka Extension, the Java API might get little worse though. Looking into it now.. Currently it looks like
ClientFlow.create("sample", system, mat);
I do not want it to look like
ClientFlow(it is an
object) that holds actor system names that are initialized. If non-existent, add the name and install a new resolver.
ActorSystemImpland you'll find
extensionsis just a
ConcurrentHashMapmight not be too bad..
ConcurrentHashMap, we need to add more logic around..
ConcurrentHashMapwould mark it registration already attempted.. Not as it is in the list or not..