Vladimir, I think we should make the same changes to the .NET API.
On Tue, Jan 25, 2022 at 5:17 PM Vladimir Steshin wrote:
> Similar question about .NET. I'm doing the sub-ticket with metrics
> of the platform services. Should we return proxy every tome by
> /IServices.GerServiceProxy()/ an
Similar question about .NET. I'm doing the sub-ticket with metrics
of the platform services. Should we return proxy every tome by
/IServices.GerServiceProxy()/ and probably deprecate
/IServices.GetService()/. Same problems with variate the behavior of
/GerServiceProxy()/ and statistics corr
>>>Did I correctly understand that: we need to revert the previous
patch, update it with the deprecation, and submit it again to master?
Not sure at all. For what? The patch could be improved. But it is
independent, brings new features with documented limitations. If we want
to deprecate somet
Vladimir,
Agreed. My point is that the actual issue we want to fix is broken metrics.
Thus, we should have a single ticket/patch *about the broken metrics* that
incorporates all required changes, as well as relevant documentation
updates.
I don't think we need a vote. I will also change mine to +
Sure. This is a simple change. These 2 fixes could go together. And
the doc already has notes of service statistics traits. Ok, might be
even better.
I'm not sure whether we need extra voting for deprecating
'service()' and, as earlier and making 'serviceProxy()' return proxy
every ti
Hi Maksim,
Which patch are you referring to?
-Val
On Mon, Jan 24, 2022 at 10:36 AM Maksim Timonin
wrote:
> Hi guys,
>
> > If we already agreed to deprecate the service() method, then I'm ok with
> the change
>
> As I can see in the previous discussion that Vladimir mentioned [1], there
> was a
Hi guys,
> If we already agreed to deprecate the service() method, then I'm ok with
the change
As I can see in the previous discussion that Vladimir mentioned [1], there
was a proposal for deprecating by Vladimir and Denis Mekhanikov, but there
wasn't a final decision. So I tried to see the `#ser
If we already agreed to deprecate the service() method, then I'm ok with
the change. But I think we should do both fixes together and also clearly
document that using service() can lead to incorrect metrics.
-Val
On Fri, Jan 21, 2022 at 1:13 AM Vladimir Steshin wrote:
> Valentin, there are
Valentin, there are 2 notable issues:
1) Variate behavior of `/serviceProxy()/` depending on user setting. It
can return both proxy and reference.
2) Service metrics are corrupted by invocations through `/service()/`.
How we can fix:
1) Just return proxy every time.
2) Deprecate `/
Maxim, hi
I'd like to correct you slightly. Of course, I did benchmarks. But
there was no doubt proxied invocation is slower. But is the job slower?
As you can see, trivial operations `cache.getAndPut()` takes the same
with proxy compared to the direct reference. Is there noted optimiz
Hi guys,
> because it's still possible to get a local instance via the service()
method
I think that there are some cases why a user doesn't want to have a proxy:
1. the user actually cares about proxy performance. (Vladimir measured it
here [1] and found that proxy actually affects some simple c
Valentin, hello again.
Previous version of the ticket suggested deprecation of
/IgniteServices#service()/. Reasons:
1) Doubt in utility of faster invocation. Proxy call local reference if
possible. Technically it is slower of course. But how does it affect
real cases, not empty metho
So the proposed change will not actually fix the issue with metrics,
because it's still possible to get a local instance via the service()
method. At the same time, the change removes an existing performance
optimization.
Let's figure out how to fix the actual problem. If the *only* way to have
me
Yes. Invocations from direct reference are not measured. This method
in the javadoc:
/* NOTE: Statistics are collected only with service proxies
obtaining by methods like/
/* {@link IgniteServices#serviceProxy(String, Class, boolean)} and won't
work for direct reference of local/
/* serv
Valentin, hi.
"Could you elaborate on why we count metrics incorrectly when
theserviceProxy() returns an instance of a local service instead of an
actual proxy?"
Local instance executes direct calls without any wrapping and doesn't
measure itself. That's why we bring proxy by 'serviceProxy(
Slava, hi.
There are many 'give-service' methods. I doubt we need one more.
User should consider exact type of the service handle, instance or
proxy. It's up to Ignite to decide.
There is a service interface for user. But yes, we might just return
proxy every time.
On 18.01.2022 14:30
Hi,
> Yep, seems that current behaviour is not correct at all. `serviceProxy()`
should return exactly what it should -- proxy.
+1. I tend to have the same opinion.
Thanks,
S.
ср, 19 янв. 2022 г. в 17:33, Ivan Daschinsky :
> Yep, seems that current behaviour is not correct at all. `serviceProxy(
BTW, there is also the service() method that can only return an instance
and never returns a proxy. Does it corrupt the metrics as well?
-Val
On Wed, Jan 19, 2022 at 1:09 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Maxim,
>
> The reason I'm asking is that I don't really unde
Maxim,
The reason I'm asking is that I don't really understand how client side
mechanics affect server side metrics (number of executions and their
durations). I feel that we might be fixing a wrong problem.
Could you elaborate on why we count metrics incorrectly when
the serviceProxy() returns a
Yep, seems that current behaviour is not correct at all. `serviceProxy()`
should return exactly what it should -- proxy.
ср, 19 янв. 2022 г. в 10:32, Maksim Timonin :
> Hi, guys!
>
> > this is not a good idea to change the behavior of serviceProxy()
> depending on statistics
>
> I think that the
Hi, guys!
> this is not a good idea to change the behavior of serviceProxy()
depending on statistics
I think that the patch doesn't change the behavior of `serviceProxy()`.
This method promises a proxy and it actually returns it. The fact that
`serviceProxy()` can return non-proxy objects is an i
What are the metrics that are being affected by this?
-Val
On Tue, Jan 18, 2022 at 3:31 AM Вячеслав Коптилин
wrote:
> Hello Igniters,
>
> IMHO, this is not a good idea to change the behavior of serviceProxy()
> depending on statistics (enabled/disabled). It seems counterintuitive to
> me.
> Per
Hello Igniters,
IMHO, this is not a good idea to change the behavior of serviceProxy()
depending on statistics (enabled/disabled). It seems counterintuitive to me.
Perhaps, we need to introduce a new method that should always return a
proxy to the user service.
Thanks,
Slava.
вт, 28 дек. 2021 г
Hi!
Agree with Maxim.
It seems to me quite normal to return a proxy for a local instance in
the case when the user has explicitly enabled statistics collection in
the service settings. Those. by default, we do not change the behavior
and if the collection of metrics is not needed, a local instanc
Hi!
I agree that users shouldn't expect a non-proxy when invoking the
`IgniteServices#serviceProxy()` method. I think it's up to Ignite to return
a non-proxy instance here as possible optimisation. But users have to use
interfaces in any case. There is the `IgniteServices#service()` method for
exp
Hi, Igniters.
I'd like to suggest modifying `/IgniteServices.serviceProxy(String name,
Class svcItf, boolean sticky)/` so that it may return proxy
even for local service. Motivation: service metrics [1]. To measure
method call we need to wrap service somehow. Also, the method name says
`prox
26 matches
Mail list logo
