Cross-posting to devlist.
--Yakov
As far as I can see from ticket title reporter wants to disable rebalancing
on per-node basis. So, some nodes would not load partitions from other
nodes while others should load normally. Disabling partition map exchange
will stop rebalancing all over the grid (however, I find this pretty useful
fe
Yakov Zhdanov created IGNITE-5196:
-
Summary: Concurrent modification in
.GridDiscoveryManager.nodeCaches
Key: IGNITE-5196
URL: https://issues.apache.org/jira/browse/IGNITE-5196
Project: Ignite
Yakov Zhdanov created IGNITE-5155:
-
Summary: Need to improve stats dump on exchange timeout
Key: IGNITE-5155
URL: https://issues.apache.org/jira/browse/IGNITE-5155
Project: Ignite
Issue Type
Yakov Zhdanov created IGNITE-5125:
-
Summary: Need to improve logging in case of hang
Key: IGNITE-5125
URL: https://issues.apache.org/jira/browse/IGNITE-5125
Project: Ignite
Issue Type
Coordinator marks the messages as verified for rest of nodes to apply the
changes this message is issued for, i.e. node added message, node failed or
left message are processed by other nodes only after coordinator
verification.
--Yakov
Yakov Zhdanov created IGNITE-5069:
-
Summary: QueryWords example fails with exception
Key: IGNITE-5069
URL: https://issues.apache.org/jira/browse/IGNITE-5069
Project: Ignite
Issue Type: Bug
time-related parameter is long and
we expect milliseconds everywhere. Mostly timeouts are used to schedule
some internal activities, and long-milliseconds is the best for this. There
are some exceptions you mentioned, but I would leave it as is at least for
consistency purposes.
--
Yakov Zhdanov
On A
Denis, there were minor test failures on tc. Alex will fix them on Mon and
I expect merge to happen right after.
--
Yakov Zhdanov
On Apr 22, 2017 2:22 AM, "Denis Magda" wrote:
> Yakov, Sasha,
>
> Are you ready to merge all the changes and close the ticket? As far as I
>
Yakov Zhdanov created IGNITE-5056:
-
Summary: Implement communication backpressure control
Key: IGNITE-5056
URL: https://issues.apache.org/jira/browse/IGNITE-5056
Project: Ignite
Issue Type
Sergi, most probably, performance will not be vert much affected since we
can batch delayed responses and this for primary_sync only. However, I
agree with your point about overcomplicated code, but I did not state that
it would be trivial.
So, what is the solution here? Switch replicated cache to
Guys, what if we look at this from another point - we can switch to read
from primary only if there is any primary_sync operation that is not acked
by backups yet. Or we can wait until all operations of the kind are acked
and then proceed with query. This seems to work when we have query after
sequ
Denis, thanks! That makes sense to me.
Sasha, please go ahead and change code to interpret this parameter as exact
frequency in milliseconds.
--
Yakov Zhdanov
Denis M,
Can you please elaborate on this?
Currently
org.apache.ignite.configuration.IgniteConfiguration#getMetricsUpdateFrequency
has special values like 0 and -1 that hardly make sense if we use this
parameter in discovery to issue metrics updates.
I would agree with Sasha and interpret this p
t;>>> 2017-04-10 13:00 GMT+03:00 Vladimir Ozerov :
>>>>>>
>>>>>> Guys,
>>>>>>>
>>>>>>> We should not have it enabled by default because as Taras mentioned:
>>>>>>>
>>>>>>
atible refactoring in further releases. Are you agree with
> this?
>
> —
> Denis
>
> > On Apr 10, 2017, at 8:39 AM, Yakov Zhdanov wrote:
> >
> > Alex Belyak, please go ahead. Thank you for your help! There were some
> work
> > I did not expect to happen.
/IGNITE-4799 ?
>
> 2017-04-10 14:50 GMT+03:00 Yakov Zhdanov :
>
>> Guys, I have finished with initial changes. There were a little bit more
>> work to do than I originally estimated.
>>
>> Denis, can you please reply in the ticket? I would like you to propose
>&
Guys, I have finished with initial changes. There were a little bit more
work to do than I originally estimated.
Denis, can you please reply in the ticket? I would like you to propose
documentation changes. Can you help?
There is also another question - we have a lot of "heartbeat" mentions in
TC
We should have it enabled by default.
--Yakov
2017-04-10 12:42 GMT+03:00 Sergi Vladykin :
> Why wouldn't we have useBalancer always enabled?
>
> Sergi
>
> 2017-04-10 12:31 GMT+03:00 Taras Ledkov :
>
> > Folks,
> >
> > I worked on issue https://issues.apache.org/jira/browse/IGNITE-3018 that
> > i
Guys, I replied in ticket. Overall I liked the changes but I think this
needs additional elaboration. Please see
https://issues.apache.org/jira/browse/IGNITE-4828
--Yakov
2017-03-31 20:09 GMT+03:00 Denis Magda :
> Michael, thanks.
>
> I did minor improvements and merged them to IGNITE-4828 branc
Yakov Zhdanov created IGNITE-4927:
-
Summary: Write behind - need new mode without skipping values
history
Key: IGNITE-4927
URL: https://issues.apache.org/jira/browse/IGNITE-4927
Project: Ignite
Change this to RuntimeException. I think it would be fine. Assertion in
logs should mean something terrible from now and on.
--Yakov
Yakov Zhdanov created IGNITE-4900:
-
Summary:
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySelfTest#testFailedNodes4
periodically fails in master
Key: IGNITE-4900
URL: https://issues.apache.org/jira/browse
Guys, I see couple of tests which have assertion error in some background
Ignite threads that may not cause test to fail.
https://issues.apache.org/jira/browse/IGNITE-4895
Anton V, can you please take a look?
--Yakov
Yakov Zhdanov created IGNITE-4895:
-
Summary: TC should fail suite if AssertionError is output to logs
Key: IGNITE-4895
URL: https://issues.apache.org/jira/browse/IGNITE-4895
Project: Ignite
et is ready:
>> https://issues.apache.org/jira/browse/IGNITE-4799 <
>> https://issues.apache.org/jira/browse/IGNITE-4799>
>>
>> —
>> Denis
>>
>> > On Mar 7, 2017, at 1:47 AM, Yakov Zhdanov wrote:
>> >
>> >>> What’s ab
Ignore atomicCache.put(k, v) if it is called inside transaction? This is
very counter intuitive. I am strongly against that.
--Yakov
Alex, I will try to review this in a couple of days.
--Yakov
As far as I know operations on atomic caches are applied immediately
dishonoring any tx context.
I would suggest that atomic cache update operation called from active tx
throws illegal state exception, unless user intentionally permits this
update by calling atomicCache.withAllowInTx() (similar to
Dmitry, you are right - this seems to be a very complex change. However, we
can we move current implementations to internal packages, introduce
configuration properties/beans so we can release and continue development
in 2.0 without breaking compatibility.
Denis, I think we can allow this as well,
s://github.com/apache/ignite/pull/1435.
>
> On Thu, Mar 9, 2017 at 6:50 PM, Alexander Fedotov <
> alexander.fedot...@gmail.com> wrote:
>
> > Sure. Will take a look.
> >
> > On Thu, Mar 9, 2017 at 6:05 PM, Yakov Zhdanov
> wrote:
> >
> >> Alexande
.org/ignite/review/IGNT-CR-81
>
> On Fri, Mar 3, 2017 at 11:39 AM, Yakov Zhdanov
> wrote:
>
> > Guys, I want to bring this up. What is the status of this ticket and
> > further steps?
> >
> > --Yakov
> >
> > 2017-01-30 16:37 GMT+03:00 Alexander Fedotov <
Alexey, you should understand how caches startup and partition map exchange
work. I would suggest you start couple of nodes in single VM and simply do
step-by-step debug in your IDE.
I don't think you will need to introduce any new message, but I think you
will have to add info to GridDhtPartition
Dmitry, yes, your understanding is correct.
Denis, I remember I already shared the idea a while ago, but completely
forgot about the ticket. Thanks for bringing it up! You should give me
couple of tips on how to use "Search" function in Jira :)
Guys, this will be compatibility breaking change, as
Guys,
I have an idea of merging all net components to one.
Now we have the following components interacting via network:
1. discovery
2. communication
3. rest
4. odbc
5. ignite-hadoop
6. time processor (being removed together with clock mode)
7. IPC communication endpoint
2-6 use GridNioServer e
>> What’s about compute engine load balancers then? They rely on the
metrics received from remote nodes.
First of all, that was poor design decision - to make different components
dependant, possibly, through user-defined implementation of Discovery Spi.
What you say makes sense to me. Let's remo
Guys, I want to bring this up. What is the status of this ticket and
further steps?
--Yakov
2017-01-30 16:37 GMT+03:00 Alexander Fedotov :
> Done. But it looks like something went wrong since Upsource reports:
> "Review has too many files (1244), aborting".
>
> Also guys, I believe we need to me
Alexey, my comments are in the ticket. Please address them.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2017-03-01 12:15 GMT+03:00 Yakov Zhdanov :
> Alexey, I will take a look at this in couple of days.
>
> --Yakov
>
> 2017-03-01 11:25 GMT+03:0
Thanks, Alex! I will take a look in a couple of days
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2017-03-02 19:07 GMT+03:00 Александр Меньшиков :
> Yakov, Okay. You can see result in JIRA https://issues.apache.org/
> jira/browse/IGNITE-603
>
> 2017
atibility that prevents us from
> both improving documentation and renaming the parameter?
>
> —
> Denis
>
> > On Mar 1, 2017, at 1:13 AM, Yakov Zhdanov wrote:
> >
> > I think we should not rename this, but properly document the behavior and
> > all the relations
Igor, please go ahead.
--Yakov
2017-03-01 12:58 GMT+03:00 Seliverstov Igor :
> Hi guys!
>
> Doesn't anybody mind if I take IGNITE-4681 ticket?
>
> Regards,
> Igor
>
Alexey, I will take a look at this in couple of days.
--Yakov
2017-03-01 11:25 GMT+03:00 ALEKSEY KUZNETSOV :
> Plz, review my changes
> https://issues.apache.org/jira/browse/IGNITE-1094
>
> https://github.com/apache/ignite/pull/1581
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
failure detection timeout.
> >
> > —
> > Denis
> >
> > > On Feb 28, 2017, at 7:28 AM, Yakov Zhdanov
> wrote:
> > >
> > > Denis, I did not get your last message. What did users expect from
> > changing
> > > hbFreq?
> > >
Alexander,
Can you please clarify this?
>I suppose "volatile" is not need here, because right now if
>GridFutureAdapter#onDone()
called in another thread than GridFutureAdapter#get0, it will produce
AssertionError.
1) 99.999% of time GridFutureAdapter#onDone() is called in some other
thread tha
Denis, I can't say for sure, but the fact test was commented out for a long
time is suspicious.
Alexander, can you please uncomment, fix all the compilation errors and
update the ticket with test run results. Make sure you have
modules/ext-data projects built and all paths mentioned
in modules/cor
Denis, I did not get your last message. What did users expect from changing
hbFreq?
--Yakov
2017-02-28 4:08 GMT+03:00 Dmitriy Setrakyan :
> Yakov, what do you think?
>
> On Mon, Feb 27, 2017 at 4:17 PM, Denis Magda wrote:
>
> > Frankly, I decided to initiate this discussion after talking to man
Konstantin Dudkov, you created ticket some time ago. Can you please clarify?
--Yakov
Alexander, you can remove the test and resolve the issue.
--Yakov
2017-02-20 17:43 GMT+03:00 Александр Меньшиков :
> Do we still need this test? Can I remove it?
>
Konstantin, please go ahead.
--Yakov
2017-02-11 20:18 GMT+03:00 Константин Дудков :
> Yakov,
>
> If you don't mind I would like to do this ticket.
>
> 10.02.2017, 16:31, "Yakov Zhdanov (JIRA)" :
> &g
Yakov Zhdanov created IGNITE-4684:
-
Summary: Local cache.get(K) should not block
Key: IGNITE-4684
URL: https://issues.apache.org/jira/browse/IGNITE-4684
Project: Ignite
Issue Type
Yakov Zhdanov created IGNITE-4683:
-
Summary: Need to avoid extra-copy to byte array when marhsalling
to cache object
Key: IGNITE-4683
URL: https://issues.apache.org/jira/browse/IGNITE-4683
Project
Yakov Zhdanov created IGNITE-4682:
-
Summary: Need to finish transition to thread-per-partition model
Key: IGNITE-4682
URL: https://issues.apache.org/jira/browse/IGNITE-4682
Project: Ignite
Yakov Zhdanov created IGNITE-4681:
-
Summary: Apply new future adapter
Key: IGNITE-4681
URL: https://issues.apache.org/jira/browse/IGNITE-4681
Project: Ignite
Issue Type: Improvement
Yakov Zhdanov created IGNITE-4680:
-
Summary: Properly split batch atomic cache operations between
stripes (putAll, removeAll, etc)
Key: IGNITE-4680
URL: https://issues.apache.org/jira/browse/IGNITE-4680
some cases, but much less
> critical.
>
> -Val
>
> On Wed, Feb 8, 2017 at 9:20 PM, Yakov Zhdanov
> wrote:
>
> > Val,
> >
> > 1. Our clients should stop require persistent store implementation if
> they
> > do not need it. Can you please file a ticket? I kn
Wow! This is the regression (from long ago version) if true.
As far as having mbean to manage eviction policy on the fly - why not? This
is handy.
--
Yakov Zhdanov
On Feb 9, 2017 9:09 PM, "Andrey Mashenkov"
wrote:
> Folks,
>
> I've found no mention in ignite code wher
ersion.
>
> Sergi
>
> 2017-02-09 7:42 GMT+03:00 Yakov Zhdanov :
>
> > Guys (esp Alex P and Sergi),
> >
> > Do we preserve transactional semantics of updates?
> >
> > In other words, does the following make sense? and when it does not?
> >
&
server it is connected to.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2017-02-09 5:19 GMT+07:00 Valentin Kulichenko :
> Yakov,
>
> I agree that investing in the legacy client doesn't make sense - it's slow
> and outdated. Regarding your p
Yakov Zhdanov created IGNITE-4675:
-
Summary: Make client node to fetch configuration from server (i.e.
connect only by address:port)
Key: IGNITE-4675
URL: https://issues.apache.org/jira/browse/IGNITE-4675
Guys (esp Alex P and Sergi),
Do we preserve transactional semantics of updates?
In other words, does the following make sense? and when it does not?
startTx()
insert into blabla...
update bla bla...
commit()
--Yakov
Filed a ticket https://issues.apache.org/jira/browse/IGNITE-4665
--Yakov
2017-02-07 0:49 GMT+07:00 Dmitriy Setrakyan :
> On Mon, Feb 6, 2017 at 12:29 AM, Yakov Zhdanov
> wrote:
>
> > What users do not expect is that partitioned cache suddenly turns to
> > replicated wi
Yakov Zhdanov created IGNITE-4665:
-
Summary: Make near readers update async by default
Key: IGNITE-4665
URL: https://issues.apache.org/jira/browse/IGNITE-4665
Project: Ignite
Issue Type
"undeprecating" - lol :D
Consider introducing @Un annotation which negates all annotations on the
same level and below.
I would probably agree with Val and Vova, but adding features to
thin-client seems questionable to me.
Is these possible:
1. avoid dependencies on client machine and require ign
Val, I think value read which is about to be overwritten by a commit is
possible. I think only pessimistic repeatable read tx can protect you
against that. Also, it seems there are no difference between read from one
node and read from several nodes here.
In primary_sync mode primaries send finish
+1 to Vladimir suggestion
--Yakov
2017-02-07 20:50 GMT+07:00 Vladimir Ozerov :
> Andrey, Valya,
>
> There is another problem here. What is we decide to add some existing
> setter method to MBean? If it has signature "T setSomething(...)", we will
> not be able to do so. We need to understand how
2017-02-06 15:20 GMT+07:00 Vladimir Ozerov :
> Yakov,
>
> I think forcing reads in TX or from primary is not what users expect by
> default. So i would have this mode disabled by default.
>
> On Mon, Feb 6, 2017 at 10:40 AM, Yakov Zhdanov
> wrote:
>
> > >It still
ough the transaction has already been committed.
>This just does not seem kosher to me.
See above example for continuous queries and slow client queue limit.
Thanks!
--Yakov
2017-02-04 12:12 GMT+07:00 Dmitriy Setrakyan :
> Hm... interesting. My questions are inline.
>
> On Mon, Jan
#x27;t guess what to expect.
> >
> > Anyway modifying my protocol for IGNITE-4302 is not a big deal, I can
> > easily change it to handle situations of like this.
> > Also as part of the JIRA I'll try to clarify documentation at least for
> > this case.
> >
>
Can anyone point a place in javadoc that states that there is exactly once
guarantee?
Imagine you have nodes A, B and C. A sends custom message to B and gets ack
back, B sends to C and dies. A connects to C and resends the message.
Result - C has got the message twice. Currently handling logic is
Yakov Zhdanov created IGNITE-4646:
-
Summary: Try to unmarshall direct messages in striped pool
Key: IGNITE-4646
URL: https://issues.apache.org/jira/browse/IGNITE-4646
Project: Ignite
Issue
Yakov Zhdanov created IGNITE-4645:
-
Summary: Best effort to avoid extra copying in binary marshaller
Key: IGNITE-4645
URL: https://issues.apache.org/jira/browse/IGNITE-4645
Project: Ignite
Thanks, Alexander! I looked this through and it seems fine to me.
Anton V, can you also review and merge if it is OK to you?
--Yakov
2017-01-31 12:49 GMT+03:00 Александр Меньшиков :
> And result of testing:
> http://ci.ignite.apache.org/project.html?projectId=IgniteTests&tab=
> projectOverview&
>> This is prefectly valid. Second transaction'll wait for completion of
first.
Alex S., I think you did not get the point. It seems AG meant two jobs of
the same task, so it is one TX. It is unclear to me how to resolve this
automatically. I would agree with AG and permit only primary keys local
Guys,
Currently when we do cache updates in FULL_SYNC mode we update near readers
(near cache entries) synchronously. This is quite big drawback in design, I
think. I get each near reader update at cost of 1 extra backup update. I
think everyone understands that partitioned cache easily turns to
r
;
> Is it possible to track updates in separate map in transaction and then use
> it during cache store commit? Will this work? Can this break anything
> and/or affect performance in negative way?
>
> -Val
>
> On Wed, Jan 25, 2017 at 2:00 AM, Yakov Zhdanov
> wrot
Agree. We need to start tests with 9 as soon as possible.
--Yakov
2017-01-25 16:47 GMT+03:00 Vladimir Ozerov :
> Igniters,
>
> Please see this article [1] from Kotlin guys. They had to re-pack public
> API because Java 9 doesn't allow several modules to share the same public
> package. Looks lik
Val, actually there is no reordering. It seems you use pessimistic
repeatable read transaction and entries are flushed into DB in the same
order entries are locked in memory.
You can do:
1. Lock all the keys in the same order, i.e. add cache.get("key1");
2. switch to non-repeatable read transactio
ages and public API. What is the purpose of
> the timeout in this case?
>
> I'm just trying to properly understand the semantics and at least fix the
> JavaDoc as it seems to be completely wrong now.
>
> -Val
>
> On Thu, Jan 12, 2017 at 2:41 AM, Yakov Zhdanov
> wrote
Alexander, as far as I remember we talked about having cluster id set via
TcpDiscoverySpi configuration and also via system property.
What do you mean by "existence of sufficient comparator"? If we require
that attribute is integer then we don't have any problems. If it is not
integer then you sho
Alexander, I was against any comparator and user defined logic exactly for
reason that comparison may be inconsistent. After long discussion and
consensus you implement approach with comparator. Can you please explain
why you did not just add logic to compare the value of CLUSTER_REGION_ID
node att
Guys, we are missing compute continuations section on readme IO. Anyone
wants to fill in this space and create an article?
--Yakov
:08 AM, Sergey Kozlov
> wrote:
> > >
> > > I like the idea to use the full range notation like
> 10.0.0.1..10.0.0.100.
> > > One issue we may face is the using of the addresses from different
> > networks
> > > like 10.0.0.201..10.0.1.100.
> > >
>
nd will not break compatibility.
> Thoughts?
>
> -Val
>
> On Wed, Jan 11, 2017 at 12:20 AM, Yakov Zhdanov
> wrote:
>
> > If you send ordered messages to a node and listener on receiving side has
> > not yet been added then timeout is still sufficient
on of ordered messaging was reworked and 'out-of-order message'
> can't happen anymore. Is this correct? If so, I think the timeout should be
> removed from the API.
>
> -Val
>
> On Tue, Jan 10, 2017 at 2:34 AM, Yakov Zhdanov
> wrote:
>
> > Val, timeout still
I would place it under Ignite for consistency with other streamers.
--Yakov
Guys, before I file a ticket - should we support range notation for each
byte in IP address? I think we should.
--Yakov
will be available. If task timeout elapses then messages get
cleared. Please let me know if you still have questions.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2017-01-06 1:02 GMT+03:00 Valentin Kulichenko :
> Folks,
>
> Anyone knows what is the p
Agree with Vladimir.
However, this functionality maybe useful in some cases. As far as I
remember we support port range notation, e.g. 127.0.0.1:47500..47509, but
we don't have this for addresses. If we implement this I would suggest the
same approach, e.g 192.168.0.1..5:47500
Thoughts?
--Yakov
instanceName is confusing in, for example, SpringCacheManager and several
other places. See email from Alexander.
Btw, gridName was OK for GridConfiguration:)
--
Yakov Zhdanov
Alexander, your point makes sense to me. Please go on with
'igniteInstanceName' and let me review the PR so we can take the final
decision.
--Yakov
Alexander, sounds good! Please post updates to ticket and this thread (if
necessary) while working.
--Yakov
Guys, I have updated the ticket.
Alexander Menshikov, when do you expect the implementation to be finished?
I am OK with CLUSTER_REGION_ID. However I would like this name -
DISCOVERY_REGION_ID - more.
>>
Do you think we will ever care about the order of nodes within the same
region, e.g. does the order of nodes within the same rack matter?
>>
I think this is too much, but if you care you still can. Ima
Vyacheslav, my comments are below.
>>
1. It is necessary to check a flag MaxDirectMemorySize, but there is no
recommendation of it:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
2. Whether it is necessary to output message in "Quiet mode"?
3. Where it is better to output information
>>
My main concern here is code complexity. Yakov, how difficult it is to
stick a new node in an arbitrary spot of a discovery ring?
>>
Dmitry, I think this is not hard. At least I don't see any issue now.
>>
I think the NodeComparator approach will work. User can chose how to sort
nodes from one
Yakov Zhdanov created IGNITE-4492:
-
Summary: Add MBean for StripedExecutor
Key: IGNITE-4492
URL: https://issues.apache.org/jira/browse/IGNITE-4492
Project: Ignite
Issue Type: Improvement
me too.
--Yakov
>>
I just want to understand which benefits we get when implement what we're
talking about. If major benefit is reduced latency of ring messages, then
the assignment 'ARC ID' in accordance with latency value is quite
enough. But if there are any hidden problems because of the large number of
reconn
>>
I thought of latency values.
Latency between host nodes < Latency between same rack nodes < Latency
between subnet nodes < etc.
>>
Vyacheslav, I agree that latency increase in the way you describe, but I
still don't understand how we use this information in discovery. Latency
may differ from t
Dmitry, for example, running queries from old fashioned pool seems to
perform better, but short-term cache updates perform better when run on
striped pool.
--Yakov
301 - 400 of 738 matches
Mail list logo
