Re: Service proxy API changes

Valentin, I understand your point and it makes sense to me. To summarize discussion I'll do the following. Leave timeout, use LT for spammed stack traces and file separate ticket for serialization issue in calculations as suggested Semyon. On Wed, Nov 16, 2016 at 1:11 AM, Valentin Kulichenko <

Re: Service proxy API changes

Dmitry, I absolutely agree with this and I'm not saying that timeout solves any of these problems. However, it provides a bit of safety for such cases (client continues working instead of hanging forever) and also allows not too wait for the service too long which can be also useful sometimes

Re: Service proxy API changes

Valentin, as I understand, this situation is abnormal, and if user thread hangs on getting service proxy, it's worth to check logs for failure instead of making workaround. On 15.11.2016 19:47, Valentin Kulichenko wrote: I would still add a timeout there. In my view, it makes sense to have

Re: Service proxy API changes

I would still add a timeout there. In my view, it makes sense to have such option. Currently user thread can block indefinitely or loop in while(true) forever. -Val On Tue, Nov 15, 2016 at 7:10 AM, Dmitriy Karachentsev < dkarachent...@gridgain.com> wrote: > Perfect, thanks! > > On Tue, Nov 15,

Re: Service proxy API changes

Perfect, thanks! On Tue, Nov 15, 2016 at 5:56 PM, Vladimir Ozerov wrote: > To avoid log pollution we usually use LT class (alias for GridLogThrottle). > Please check if it can help you. > > On Tue, Nov 15, 2016 at 5:48 PM, Dmitriy Karachentsev < >

Re: Service proxy API changes

To avoid log pollution we usually use LT class (alias for GridLogThrottle). Please check if it can help you. On Tue, Nov 15, 2016 at 5:48 PM, Dmitriy Karachentsev < dkarachent...@gridgain.com> wrote: > Vladimir, thanks for your reply! > > What you suggest definitely makes sense and it looks more

Re: Service proxy API changes

Vladimir, thanks for your reply! What you suggest definitely makes sense and it looks more reasonable solution. But there remains other thing. The second issue, that this solution solves, is prevent log pollution with GridServiceNotFoundException. The reason why it happens is because

Re: Service proxy API changes

Also we implemented the same thing for platforms some time ago. In short, job result processing was implemented as follows (pseudocode): // Execute. Object res; try { res = job.run(); } catch (Exception e) { res = e } // Serialize result. try { SERIALIZE(res); } catch (Exception e)

Re: Service proxy API changes

Dmitriy, Shouldn't we report serialization problem properly instead? We already had a problem when node hanged during job execution in case it was impossible to deserialize the job on receiver side. It was resolved properly - we caught exception on receiver side and reported it back sender side.

Service proxy API changes

Hi Igniters! I'd like to modify our public API and add IgniteServices.serviceProxy() method with timeout argument as part of the task https://issues.apache.org/jira/browse/IGNITE-3862 In short, without timeout, in case of serialization error, or so, service acquirement may hang and infinitely