ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Mekhanikov <dmekhani...@gmail.com>
Subject Re: Reference of local service.
Date Mon, 02 Mar 2020 16:50:52 GMT
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:
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/servicegrid/SimpleMapService.java
I mentioned the *Serializable* interface just as an example of an interface
that can be present, but it's not the one that is going to be called by a
user.

What I'm trying to say is that there is no way to say whether the service
is going to be used through a proxy only, or usage of a local instance is
also possible.

Vladimir,

I don't like the idea, that enabling or disabling of metrics will change
the behaviour of the component you collect the metrics for. Such behaviour
is far from obvious.

Nikolay,

I agree, that such approach is valid and makes total sense. But making the
*IgniteServices#serviceProxy()* method always return a proxy instead of a
local instance will change the public contract. The javadoc currently says
the following:

> If service is available locally, then local instance is returned,
> otherwise, a remote proxy is dynamically created and provided for the
> specified service.


I propose introducing a new method that will always return a service proxy
regardless of local availability, and deprecating *serviceProxy()* and
*service()
*methods. What do you think?

Denis

пн, 2 мар. 2020 г. в 16:08, Nikolay Izhikov <nizhikov@apache.org>:

> 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 lead to performance
> > degradation for local instances, which is another argument against such
> change.
>
> As far as I know, many and many modern frameworks use a proxy approach.
> Just to name one - Spring framework works with the proxy.
>
> We should measure the impact on the performance that brings proxy+metric
> and after it make the decision on local service metrics implementation.
> Vladimir, can you, as a contributor of this task make this measurement?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11927
>
> пн, 2 мар. 2020 г. в 12:56, Vladimir Steshin <vladsz83@gmail.com>:
>
> > 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 мар. 2020 г. в 11:26, Vyacheslav Daradur <daradurvs@gmail.com>:
> >
> > > >> 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 though the best thing we can do is to calculate remote
> > > invocations only, since all of them go through a proxy.
> > >
> > > Let's introduce a system property to manage local services monitoring:
> > > - local services monitoring will be disabled by default - to avoid any
> > > backward compatibility issues;
> > > - local services monitoring can be enabled runtime with a known
> > limitation
> > > for new services for example;
> > > Moreover, if we introduce such a feature flag to ServiceConfiguration -
> > > the new feature can be enabled per service separately.
> > >
> > > What do you think?
> > >
> > >
> > >
> > > On Mon, Mar 2, 2020 at 12:33 AM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > wrote:
> > >
> > >> 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 all services to have
> an
> > >> interface, unfortunately. Such change can potentially break existing
> > code,
> > >> since such requirement doesn't exist currently.
> > >> 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?
> > >>
> > >> Usage of a proxy instead of service instances can lead to performance
> > >> degradation for local instances, which is another argument against
> such
> > >> change.
> > >>
> > >> I think, it will make sense to make all service invocations work
> through
> > >> a proxy in Ignite 3.
> > >> For now though the best thing we can do is to calculate remote
> > >> invocations only, since all of them go through a proxy.
> > >> Another option is to provide a simple way for a user to account the
> > >> service invocations themselves.
> > >>
> > >> What do you guys think?
> > >>
> > >> Denis
> > >>
> > >>
> > >> вт, 25 февр. 2020 г. в 16:50, Vyacheslav Daradur <daradurvs@gmail.com
> >:
> > >>
> > >>> 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 <vladsz83@gmail.com>:
> > >>>
> > >>>> 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] https://issues.apache.org/jira/browse/IGNITE-12464
> > >>>>
> > >>>> вт, 25 февр. 2020 г. в 16:17, Vyacheslav Daradur <
> daradurvs@gmail.com
> > >:
> > >>>>
> > >>>>> {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 future releases direct link will be returned,
> a
> > >>>>> service instance might be wrapped for monitoring for example.
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Feb 25, 2020 at 4:09 PM Vladimir Steshin <
> vladsz83@gmail.com
> > >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> 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
<
> > daradurvs@gmail.com
> > >>>>>> >:
> > >>>>>>
> > >>>>>>> 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 for load-balancing.
> > >>>>>>>
> > >>>>>>> [1]
> > >>>>>>>
> >
> https://github.com/apache/ignite/blob/56975c266e7019f307bb9da42333a6db4e47365e/modules/core/src/main/java/org/apache/ignite/IgniteServices.java#L569
> > >>>>>>>
> > >>>>>>> On Tue, Feb 25, 2020 at 3:51 PM Vladimir Steshin <
> > vladsz83@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Hello, Igniters.
> > >>>>>>>>
> > >>>>>>>> Previous e-mail was with wrong topic 'daradurvs@gmail.com'
:)
> > >>>>>>>>
> > >>>>>>>> I got a question what exactly IgniteServices#service(String
> name)
> > >>>>>>>> is supposed to return: reference to the object
or a proxy for
> > some reason
> > >>>>>>>> like IgniteServices#serviceProxy(…)? Vyacheslav
D., can you tell
> > me your
> > >>>>>>>> opinion?
> > >>>>>>>>
> > >>>>>>>> public interface MyService {
> > >>>>>>>>
> > >>>>>>>>                public void foo();
> > >>>>>>>>
> > >>>>>>>> }
> > >>>>>>>>
> > >>>>>>>> public class MyServiceImpl implements Service,
MyService {
> > >>>>>>>>
> > >>>>>>>>                @Override public void foo(){ …
}
> > >>>>>>>>
> > >>>>>>>>                public void bar(){ … };
> > >>>>>>>>
> > >>>>>>>> }
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> // Is it required to support
> > >>>>>>>>
> > >>>>>>>> MyServiceImpl srvc = ignite.services().service(“myService”);
> > >>>>>>>>
> > >>>>>>>> srvc.foo();
> > >>>>>>>>
> > >>>>>>>> srvc.bar();
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> // Or is the only correct way:
> > >>>>>>>>
> > >>>>>>>> MyService srvc = ignite.services().service(“myService”);
> > >>>>>>>>
> > >>>>>>>> srvc.foo();
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Best Regards, Vyacheslav D.
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Best Regards, Vyacheslav D.
> > >>>>>
> > >>>> --
> > >>> Best Regards, Vyacheslav D.
> > >>>
> > >>
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message