Crosspost to dev list.
Igniters,
This proposal looks quite reasonable. Do we have any restrictions that
could prevent implementing such feature?
I think it's nice to have in Ignite.
Thanks!
-Dmitry.
On Sun, Apr 23, 2017 at 1:37 AM, npordash wrote:
> Thanks!
>
> That would definitely help addr
Hi all!
According to this thread [1] in JDBC store configuration:
1. Map key and value fields to the same columns in DB.
2. Try to update data.
3. Got invalid SQL.
Let's see an pseudocode example of described use case.
KeyClass { field1; field2; field3 }, ValClass { field1; field2; field3 }
Map
g 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
> such
> >> option. Currently user thread can block indefinitely or loop in
> >> w
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 <
> dkarachent...@g
> to deserialize the job on receiver side. It was resolved properly - we
> > caught exception on receiver side and reported it back sender side.
> >
> > I believe we must do the same for services. Otherwise we may end up in
> > messy API which doesn't resolve original probl
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 log
