Hi, folks.
I'd like to advance the final decision. Is it OK to:
1)Make IgniteService.serviceProxy() return proxy for locally deployed
service too.
2)Make the proxy collect metrics of service method invocations without
any additional conditions, interfaces, options.
3) Deprecate
Andrey,
>>> Is it possible to return actual class instance instead of interface
from serviceProxy() method?
No, it is not possible. IgniteServiceImpl doesn't allow that:
public T serviceProxy(final String name, final Class
svcItf, final boolean sticky, final long timeout) {
...
Vladimir,
> Why not using IgniteServices.serviceProxy() for that? Since it requires an
> interface, It could return proxy for local service too and
> keep backward compatibility at the same time.
Is it possible to return actual class instance instead of interface
from serviceProxy() method?
Andrey,
IgniteServices.service() method could return actual interface implementation
instead of interface itself.
IgniteServices.service() always return actual local service instance, no proxy,
might be without any interface but except Service.
If yes then we can add new method
Vladimir,
>> We won’t affect existing services
> How exactly will we affect services without special interface? Please see
> the benchmarks in previous email.
I talk about backward compatibility, not about performance. But it
doesn't matter because... see below.
My fault. From discussion I
Andrey, hi.
>> We won’t affect existing services
How exactly will we affect services without special interface? Please see
the benchmarks in previous email.
>>> what if we generate will generate proxy that collects service’s metrics
only if service will implement some special interface?
I
Hi, everyone.
I've done some benchmarks and wonder whether we need to disable service
metrics somehow. As Denis suggested, proxies might be involved for local
services. If I enable current proxy for local services, I see the flowing
cases:
1) Service proxy is too slow with trivial operations to
Hi there,
what if we will generate proxy that collects service's metrics only if
service will implement some special interface? In such case:
- we won't affect existing services at all.
- we can impose additional requirement for services that want use
metrics out of box (i.e. service that
Vyacheslav, Denis, hi again.
>>> I agree with the proposal to introduce a new method which returns proxy
include the case of locally deployed services.
I see one is restricted to use an interface for service with
IgniteServiceProcessor#serviceProxy(…):
A.ensure(svcItf.isInterface(),
Denis, finally I understood your arguments about interfaces check, thank
you for the explanation.
I agree with the proposal to introduce a new method which returns proxy
include the case of locally deployed services.
Also, such a method should be able to work in mode "local services
preferred",
Vyacheslav,
You can't make service interfaces extend
*org.apache.ignite.services.Service*. Currently it works perfectly if
*org.apache.ignite.services.Service* and a user-defined interface are
independent. This is actually the case in our current examples:
Hello, Vladimir.
> What if we just provide an option to disable service metrics at all?
I don't think we should create an explicit property for service metrics.
We will implement the way to disable any metrics in the scope of
IGNITE-11927 [1].
> Usage of a proxy instead of service instances can
Denis, Vyacheslav, hi.
What if we just provide an option to disable service metrics at all? It
would keep direct references for local services. Also, we can make service
metrics disabled by default to keep current code working. A warning of
local service issues will be set with the option.
пн, 2
>> Moreover, I don't see a way of implementing such a check. Are you going
to look just for any interface? What about Serializable? Will it do?
The check should look for the interface which implements
"org.apache.ignite.services.Service", it covers the requirement to be
Serializable.
>> For now
Vladimir, Slava,
In general, I like the idea of abstracting the service deployment from its
usage, but there are some backward-compatibility considerations that won't
let us do so.
Or we can declare usage of services without interfaces incorrect
I don't think we can introduce a requirement for
It is not a change of public API from my point of view.
Also, there is a check to allow getting proxy only for an interface, not
implementation.
Denis, what do you think?
вт, 25 февр. 2020 г. в 16:28, Vladimir Steshin :
> Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
>
Vyacheslav, this is exactly what I found. I'm doing [1] (metrics for
services) and realized I have to wrap local calls by a proxy. Is it a
change of public API and should come with major release only? Or we can
declare usage of services without interfaces incorrect?
[1]
{IgniteServices#service(String name)} returns direct reference in the
current implementation.
So, class casting should work for your example:
((MyServiceImpl)ignite.services().service(“myService”)).bar();
It is safer to use an interface instead of an implementation, there is no
guarantee that in
Vyacheslav, Hi.
I see. But can we consider 'locally deployed service' is a proxy too, not
direct reference? What if I need to wrap it? This would be local service
working via proxy or null.
вт, 25 февр. 2020 г. в 16:03, Vyacheslav Daradur :
> Hi, Vladimir
>
> The answer is in API docs: "Gets
Hi, Vladimir
The answer is in API docs: "Gets *locally deployed service* with specified
name." [1]
That means {IgniteServices#service(String name)} returns only locally
deployed instance or null.
{IgniteServices#serviceProxy(…)} returns proxy to call instances across the
cluster. Might be used
20 matches
Mail list logo
