[kcbabo]

BTW, I forgot to mention that it's totally possible to do this as a custom strategy if your customer needs this now and can't wait for SY 2.0 and FSW 6.1.  For example, if your customer wanted this to always be the default behavior, you could just introduce a new strategy implementation that always checked for a local endpoint and you wouldn't need to mess around with the config stuff.  Of course, I hope you also implement this as a project feature with the configuration if you go that route. :-)

[jorgemoralespou_2]

Keith Babo escribió:

Yes, this will go in the 2.0 version of the schema.  Since it's a boolean field, it will default to false in the config model so you shouldn't have to check explicitly in your strategy logic whether the underlying switchyard.xml is 1.x or 2.0.

Hi,

I think that for SY2 schema should default to true, as it should always try to invoke locally. For SY1, I agree it should default to false, or else, check clustered configuration.

[kcbabo]

As I mentioned earlier, this should not default to true.

[jorgemoralespou_2]

Keith Babo escribió:

BTW, I forgot to mention that it's totally possible to do this as a custom strategy if your customer needs this now and can't wait for SY 2.0 and FSW 6.1.  For example, if your customer wanted this to always be the default behavior, you could just introduce a new strategy implementation that always checked for a local endpoint and you wouldn't need to mess around with the config stuff.  Of course, I hope you also implement this as a project feature with the configuration if you go that route. :-)

I've seen that LoadBalanceStrategy can be pluged in, but the problem is that if I set clustered, method call will be remote, even if I always return local endpoint. So yes, I'm doing the enhancement.

I'm in the stage of building it to test on EAP, but probably will leave it for now, as it's been long day.

[kcbabo]

I've seen that LoadBalanceStrategy can be pluged in, but the problem is that if I set clustered, method call will be remote, even if I always return local endpoint.

Bah!  That's right.

[jorgemoralespou_2]

As captain commands although I do not agree.

[jorgemoralespou_2]

Keith Babo escribió:

I didn't quite catch what you are asking for confirmation on, so let me play it back to you to make sure we are on the same page:

• ClusteredInvoker should be aware of whether a service being invoked is available locally.
• There should be a way to specify that ClusteredInvoker should prefer local invocations over remote invocations.  The existing implementations should not change to make this default behavior, however.

I agree with both those points.  Some implementation notes:

• I think this change should be fairly localized - probably just to the load balancer strategy implementation itself.
• Node name should be optional for cases of remote clients executing outside the container, so keep a version of the constructor which doesn't take it and don't rely on it being non-null.
• We can start with just calling these different load balance strategy names.  I have a feeling that approach won't scale particularly well as we will end up with lots and lots of strategy names to configure behavior.  Unfortunately, the SCA schema boxes us into this by only allowing extension attributes and not elements.  I say start with the approach of using a different strategy name and we'll see how it turns out.
• I'm not particularly fond of the term affinity for this, but I don't have a better suggestion at the moment that's not super long (e.g. RandomPreferLocalStrategy).  The reason I don't like affinity is that it can actually mean a number of different things.  It definitely could mean prefer local, but it could also mean partitioning workload based on some other criteria (priority, classification, geography, function, etc.).  This isn't a huge deal as it's easy to change names as we develop, but figured I would throw it out there for discussion.

After looking at the code, and doing some changes, I think that ClusteredInvoker should be left for remote standalone clients, and that SCAInvoker should implement RemoteInvoker, so it has access to the registry and LoadBalanceStrategy and is able to determine if call should be local or not depending on the availability of the service on the registry.

I also have to extend the RemoteRegistry to be able to get the LocalEndpoint of a service.

I also don't get the point of "Node name should be optional for ....". As I said, ClusteredInvoker for me should be client side so no Node awareness.

[kcbabo]

As captain commands although I do not agree.

Ha! Let me soften that a bit and say "I strongly believe that it should be false by default".  That said, we make decisions as a group on this project, so you are welcome to keep the conversation going and build support for your case. :-)

[kcbabo]

I would just push up your code when you're ready and we can discuss.

[jorgemoralespou_2]

Keith Babo escribió:

Ha! Let me soften that a bit and say "I strongly believe that it should be false by default".  That said, we make decisions as a group on this project, so you are welcome to keep the conversation going and build support for your case. :-)

Ok, Then I'll keep discussing, but if it is only you and me, we will never agree.

I think that "By default" should prefer local endpoints (in SY2), and only when using SY1 namespace (lagacy services) behavior should be kept. Maybe I'm not thinking on how customers will upgrade their services, but if I define this property in namespace 2 that means that when using it, users should know what they are doing. And of course, the sooner the better.

[jorgemoralespou_2]

There are already the corresponding pull requests for core and components.

I'll talk to you when you criticize my code

Night