Ivan,
Some notes about your comments:
> 1. Specifying subset of metrics which are exported to an external system.
I believe there are no any subset if metrics except of metrics related
with one particular source. Also I think that there is no need to
filter out metrics set on export stage. If so
Nikolai,
Metric is disabled if it doesn't allocate any memory and doesn't
update any variable because doesn't have any value. Ideally disabling
metrics for some cache should be equal to cache stopping.
On Fri, Jun 28, 2019 at 1:02 PM Nikolay Izhikov wrote:
>
> Hello, Alexey.
>
> Thanks for the f
2019 at 4:49 PM Andrey Gura wrote:
>
> Nikolai,
>
> Metric is disabled if it doesn't allocate any memory and doesn't
> update any variable because doesn't have any value. Ideally disabling
> metrics for some cache should be equal to cache stopping.
>
>
d in the case we adds new node or replace
> > > >
> > > > existing to the cluster.
> > > > > Use can have parameters similar to Ignite configuration, log
> > > >
> > > > configuration files.
> > > > >
> &
hit rate configuration.
>
> I think the user should be able to configure buckets for histogram and
> rateTimeInterval for hitrate.
>
> Ignite has dozens of use-cases and deployment modes, seems,
> we can't cover it all with the single predefined buckets/rateTimeInterval set.
it looks ugly and not usable.
>
> Thanks, for the feedback, appreciate you ownesty.
>
> > No. But we should admit that this is bad decision and do not include this
> > change to the code base.
>
> What is your proposal?
> How metrics configuration should work?
>
> &
Good example of proper buckets configuration. Such configuration is
suitable for may cases. See attached screenshot (I hope it will not be
reject by mail system or forum).
On Tue, Aug 6, 2019 at 2:45 PM Andrey Gura wrote:
>
> > What do you mean by "exponential bounds"?
>
Both ways are right because there is probability that user home isn't
defined in system.
So we should try resolve user dir and fail if it can't be resolved.
On Mon, Aug 12, 2019 at 7:04 PM Ivan Rakov wrote:
>
> Choosing the smallest of two evils, I'll agree with user.dir.
> Being able to run wit
+1
On Fri, Aug 23, 2019 at 3:32 PM Anton Vinogradov wrote:
>
> -1 (binding)
> Explained at discussion thread.
>
> On Fri, Aug 23, 2019 at 11:17 AM Anton Vinogradov wrote:
>
> > Dmitriy,
> >
> > Did you check RC using automated TeamCity task?
> >
> > On Fri, Aug 23, 2019 at 11:09 AM Zhenya Stanil
> But the slack is not indexing and not accessible for all people in the
Internet
+1
On Mon, Aug 26, 2019 at 4:56 PM Alexey Zinoviev wrote:
>
> I think that channels for separate IEP-s is too much.
> But the slack is not indexing and not accessible for all people in the
> Internet. Maybe it's wr
Hi, Igniters!
I'm working on some metrics related aspects and it seems that we have
missed some points regarding the metrics management. There are at
least two major problems from my point of view.
Problem definition.
---
1. There is no unified approach to adding metrics
Why chat is called chat? [1] Just ignore modern definitions :) Chat is
"bla-bla-bla".
IMO, there are no any pros for using Slack in order to make Ignite
Collaboration 100% Open and Transparent. Chat is just garbage of some
phrases that aren't structured into discussions (please, don't talk me
abou
each list(that doesn't currently exists in Ignite) will be
> > discussed in separate tickets
> > 2. Metric Exporters (optionally) can support list export.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11905
> >
> >
> > В Вт, 14/05/2019 в 16:42 +0
2 main methods:
> * `visitAll(AttributeVisitor visitor);` - visits each attribute of
> the some monitoring row class. Provides index, name and class of attribute to
> the consumer.
> * `visitAll(R row, AttributeWithValueVisitor visitor)` - visits each
> attribute of som
+1 (binding)
On Mon, Sep 16, 2019 at 12:50 PM Alexey Kuznetsov wrote:
>
> +1 (binding)
>
> On Mon, Sep 16, 2019 at 3:58 PM Pavel Tupitsyn wrote:
>
> > +1 (binding)
> >
> > On Fri, Sep 13, 2019 at 8:09 PM Denis Magda wrote:
> >
> > > +1 (binding)
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Fr
n
> > demand. So we should have public API for it, SQL API and JMX. There is
> > no need any exporters.
>
> What if we want to export lists to log or via http, etc?
>
> > Also it would be great to involve more people to this discussion.
>
> Any feedback are welcome!
based model, not on demand.
>
> I don't know such dbms.
> Seems, it's OK if some SPI implementation supports only part of exported data.
>
> Are we use "lists" or "view" term? :)
>
> My point is:
>
> We can have single manager for metri
s current state of the node.
>
> > We can live with one manager for absolutely all entities in the system
> > but we don't do it, right? :)
>
> I don't propose that.
> What I propose is to have one manager for the same entities.
>
> Please, don't overact
Igniters,
>From my point of view monitoring isn't ready for release. So it would
be great to return to this discussion later. It seems that beginning
of November is good time for it.
On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev wrote:
>
> Nikolay Izhikov, ok, let's arrange the talk in ASF sla
s not ready?
> Can we track planned changes somehow?
>
>
> В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет:
> > Igniters,
> >
> > From my point of view monitoring isn't ready for release. So it would
> > be great to return to this discussion later. It seems that
e by design.
On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura wrote:
>
> >> From my point of view monitoring isn't ready for release.
>
> > Can you clarify, what exactly is not ready?
> > Can we track planned changes somehow?
>
> We have too many not resolve
features that someone will not partially
> merge the new one? Should we monitor the master branch commits for
> such purpose?
>
> On Mon, 23 Sep 2019 at 20:18, Andrey Gura wrote:
> >
> > Maxim,
> >
> > >> From my point, if some components will not be ready
user impression.
> >
> > Can you advise, how can we guarantee in our case when we complete with
> > current partially merged features that someone will not partially
> > merge the new one? Should we monitor the master branch commits for
> > such purpose?
> >
>
:
> > >
> > > > Andrey,
> > > >
> > > > Agree with you. It can affect the user impression.
> > > >
> > > > Can you advise, how can we guarantee in our case when we complete with
> > > > current part
Alexey,
Yes, system view must be enabled by default and must not have any
enable/disable features. As I told early, system views is on demand
feature and views don't consume any resources while not requested.
On Wed, Sep 18, 2019 at 4:10 PM Alex Plehanov wrote:
>
> One more point to discuss: Wou
> There is no need for a HashMap unified solution.
>
> We can extend `AttibuteWalkerGenerator` to generate all required boilerplace
> code (for enabling/disabling metrics, etc.)
>
> I want to bold my statement: We should keep metric creation as simple as we
> can.
> Developer of speci
>From my point of view @IgniteTransactional annotation is redundant
entity which will just confuse and lead to questions like "How to use
this annotation?" I think documention update is better way.
On Wed, Feb 15, 2017 at 1:50 PM, Evgeniy Stanilovskiy
wrote:
> postgres has the different viewpoint
Feb 27, 2017 at 5:09 AM, Kozlov Maxim wrote:
>>
>>> Hi Igniters,
>>>
>>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only
>>> one value PRIMARY. Andrey Gura, proposition remove
>>> CacheAtomicWriteOrderMode enum. Will there be somethi
No, it should be removed. If somebody use entry last update time (e.g.
for conflict resolving) they should store this time as entry field.
On Wed, Mar 1, 2017 at 12:57 AM, Dmitriy Setrakyan
wrote:
> Do we still need GridClockSyncProcessor?
>
> On Tue, Feb 28, 2017 at 5:26 AM, Andrey Gu
Hi, Aleksey!
Thank you for contribution!
I've reviewed your changes and have some comments (mostly cosmetic).
Could you please fix this comment? See review in Upsource for details.
On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
wrote:
> Plz, review my PR :
> http://reviews.ignite.apache.org
; GridCacheAtomicPrimaryWriteOrderReloadAllSelfTest
> IgniteCachePutRetryAtomicPrimaryWriteOrderSelfTest
> GridCacheValueConsistencyAtomicPrimaryWriteOrderSelfTest
> IgniteCacheAtomicPrimaryWriteOrderExpiryPolicyTest
>
> ok? :)
>
>> 1 марта 2017 г., в 2:04, Andrey Gura написал(а):
>>
>>
I think that it is ok.
On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim wrote:
> Ok. What do you say for the rest?
>
>> 1 марта 2017 г., в 18:15, Andrey Gura написал(а):
>>
>> Maxim,
>>
>> I think that during renaming we should not lose "Atomic" p
Aleksey,
if you talk about fut.listen() then it doesn't make sense. listen()
call checks whether future is already completed and if it completed
invokes passed listener from current thread.
On Thu, Mar 2, 2017 at 12:42 PM, ALEKSEY KUZNETSOV
wrote:
> Hi all ! During pessimistic transaction we exe
eturn new IgniteUuid(new UUID(((long)topVer << 32) | nodeOrderDrId,
>> globalTime), order);
>> }
>>
>> globalTime parameter replaced by something or remove this method?
>>
>>
>> > 2 марта 2017 г., в 12:07, Kozlov Maxim
>> написал(а):
>> >
&
Aleksey,
once again, listener will be called directly in
GridFutureAdapter.listen() method if future already completed.
1. execute prepareAsync()
2. prepare phase answer got
3. listener binded (actually not binded but called)
@Override public void listen(IgniteInClosure> lsnr0) {
assert lsnr
; - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader reader)
>
> use globalTime variable, must be removed case 0: (in both methods) or replace
> globalTime?
>
>
>
>> 2 марта 2017 г., в 16:58, Andrey Gura написал(а):
>>
>> +1
>>
>> Removing
code at github rather than upsource later on. Because, the
> later is too slow and bring no substantial benefits compared github
>
> ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
>
>> Hi, Aleksey!
>>
>> Thank you for contribution!
>>
>> I've reviewed your cha
Aleksey, thanks!
I answered in JIRA ticket.
On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
wrote:
> I've fixed the comments.
> http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>
> пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
>
>> Aleksey,
>>
>>
>
>
>> 3 марта 2017 г., в 19:19, Andrey Gura написал(а):
>>
>> Maxim,
>>
>> I think the next implementation will be good enough:
>>
>> public IgniteUuid asGridUuid() {
>>return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
>&
Aleksey,
node N1 must not contain C1 cache data (must not be affinity node for
cache C1), but N1 node must to know about C1 cache (must jave C1 cache
descriptor) in order to provide access to C1 cache from this node.
On Mon, Mar 6, 2017 at 4:36 PM, ALEKSEY KUZNETSOV
wrote:
> Consider we've got
. In other words, i want to make sure N1 doesn't
> contain C1 cache. Is there a function F() as following : F (N1) = null ,
> F(N2) = C1.
>
> пн, 6 мар. 2017 г. в 16:54, Andrey Gura :
>
>> Aleksey,
>>
>> node N1 must not contain C1 cache data (must not be af
Time) {
>> .
>> }
>> else
>> return globalTime > otherGlobalTime ? 1 : -1; // => return -1;
>>
>> and,
>> GridCacheMvcc class,
>> SER_VER_COMPARATOR is comparator by globalTime var. His remove and remove
>> compareSerializableVersion?
>>
>
>> Andrey, in GridTimeSyncProcessorSelfTest class methods: testTimeSync() and
>> testTimeSyncChangeCoordinator() also removed?
>>
>>
>>> 6 марта 2017 г., в 18:42, Andrey Gura написал(а):
>>>
>>> Maxim,
>>>
>>> About SER_VER_COMPARATOR.
Aleksey, thanks a lot!
Answered in JIRA ticket.
On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV
wrote:
> Hi! I have fixed all sources. Plz, review it again
>
> пн, 6 мар. 2017 г. в 15:43, Andrey Gura :
>
>> Aleksey, thanks!
>>
>> I answered in JIRA ticket.
>
JFYI
Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
cluster manager for Vert.x in HA/Clustered mode.
On Tue, Mar 7, 2017 at 3:10 AM, Denis Magda wrote:
> The Apache Ignite Community is pleased to announce the release of Apache
> Ignite 1.9.0.
>
> Apache Ignite In-Memory Data
GNITE/External+Integrations>
>
> —
> Denis
>
>> On Mar 7, 2017, at 11:47 AM, Andrey Gura wrote:
>>
>> JFYI
>>
>> Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
>> cluster manager for Vert.x in HA/Clustered mode.
>>
>> On T
che.org/viewType.html?buildTypeId=
> IgniteTests_RunAll&branch_IgniteTests=pull%2F1521%
> 2Fhead&tab=buildTypeStatusDiv <http://ci.ignite.apache.org/
> viewType.html?buildTypeId=IgniteTests_RunAll&branch_
> IgniteTests=pull/1521/head&tab=buildTypeStatusDiv>
>
Aleksey,
I don't see any new changes. So I'll check TC and merge changes today.
On Fri, Mar 10, 2017 at 10:20 AM, ALEKSEY KUZNETSOV
wrote:
> Hi! Can u plz review ticket once more
>
> вт, 7 мар. 2017 г. в 18:52, Andrey Gura :
>
>> Aleksey, thanks a lot!
>>
&g
Aleksey,
Thanks for your contribution! I've merged this PR into master branch.
See JIRA issue comment for details.
On Fri, Mar 10, 2017 at 2:58 PM, Andrey Gura wrote:
> Aleksey,
>
> I don't see any new changes. So I'll check TC and merge changes today.
>
> On
startGrids() method starts nodes sequentially, whille
startGridsMultiThread() does it in parallel. Moreover,
startGridsMultiThreaded() waits for finishing of partition map
exchange.
On Mon, Mar 13, 2017 at 4:43 PM, ALEKSEY KUZNETSOV
wrote:
> Hi All!
> When would you call startGridsMultiThreaded i
iv
>>> <http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignit
>>> eTests_RunAll&branch_IgniteTests=pull/1521/head&tab=buildTypeStatusDiv>
>>>
>>> > 7 марта 2017 г., в 14:15, Andrey Gura написал(а):
>>> >
>>> > Maxim,
Michael,
it makes sense only for cases when partitions count is power of two.
Affinity function doesn't have this limitation.
Bu, of course, we can check, that partitions count is power of two and
use optimized hash code calculation.
On Wed, Mar 15, 2017 at 4:09 PM, Michael Griggs
wrote:
> Hi
. If this change actually provides
> better distribution, it absolutely makes sense to do it.
>
> Michael, can you create a Jira ticket and put you findings there?
>
> -Val
>
> On Wed, Mar 15, 2017 at 3:58 PM, Andrey Gura wrote:
>
>> Michael,
>>
>> it makes
Dmitry, see JIRA ticket for review comments.
On Mon, Mar 27, 2017 at 6:13 PM, Denis Magda wrote:
> Hello Dmitriy, thanks! Someone will have a look at your changes soon. Sorry
> for the delay.
>
> —
> Denis
>
>> On Mar 27, 2017, at 3:24 AM, Дмитрий Рябов wrote:
>>
>> Hello, can anyone review thi
t; What if go further and remove CacheAtomicWriteOrderMode enum from the
>>>> public API at all? I see no sense to keep it for the only one option left
>>>> - PRIMARY.
>>>>
>>>> Any objections?
>>>>
>>>> —
>>&
Dmitry,
this review is in progress. But I'm confused about PR number because
in JIRA ticket we discussed PR 1631. What is actual PR number for
latest changes?
On Mon, Apr 10, 2017 at 11:38 AM, Дмитрий Рябов wrote:
> Hello, igniters. Please, review.
>
> PR: https://github.com/apache/ignite/pull/1
Guys,
It seems that both mentioned problem have the same root cause: each
cache has personal affinity function instance and it leads to
perfromance problem (we retry the same calcualtions for each cache)
and problem related with fact that FailAffinityFunction is statefull
(some co-located cache ha
x27;t it?).
> So ticket has only one attached link to "GitHub Pull Request #1630".
>
> 2017-04-10 14:24 GMT+03:00 Andrey Gura :
>
>> Dmitry,
>>
>> this review is in progress. But I'm confused about PR number because
>> in JIRA ticket we discussed PR
Aleksey,
timer like you are mentioned exists - it is transaction timeout.
On Tue, Apr 11, 2017 at 3:25 PM, ALEKSEY KUZNETSOV
wrote:
> Igniters! If we started transaction, and in phase prepare the primary node
> doesnt receive GridDhtPrepareResponse then the transaction got stuck for a
> long tim
Dmitry,
thanks a lot for your contribution. Changes are merged into master branch.
On Mon, Apr 10, 2017 at 7:07 PM, Andrey Gura wrote:
> Thanks, Dmitry! I've reviewed your changes again and will merge it
> after TC results.
>
> On Mon, Apr 10, 2017 at 3:08 PM, Дмитрий Рябов
Vyacheslav,
thank you for contribution! Your changes are merged into master branch.
On Mon, Mar 20, 2017 at 1:11 PM, Vyacheslav Daradur wrote:
> I've received answers in the issue.
>
> Ready for review.
>
> 2017-03-16 10:14 GMT+03:00 Vyacheslav Daradur :
>
>> Hello everyone.
>>
>> I have some qu
gt; this task.
>
>
> 2017-04-12 19:13 GMT+03:00 Andrey Gura :
>
>> Vyacheslav,
>>
>> thank you for contribution! Your changes are merged into master branch.
>>
>> On Mon, Mar 20, 2017 at 1:11 PM, Vyacheslav Daradur
>> wrote:
>> > I've recei
+1
23 мая 2017 г. 11:30 AM пользователь "Alexey Kuznetsov" <
akuznet...@apache.org> написал:
> +1
>
> On Tue, May 23, 2017 at 3:23 PM, Sergi Vladykin
> wrote:
>
> > +1
> >
> > Sergi
> >
> > 2017-05-23 10:20 GMT+03:00 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > +1
> > >
>
gt; catch (CacheException e) {
>> >>> if (e.getCause() instanceof IgniteCheckedException &&
>> >>> e.getCause().getCause() instanceof TransactionDeadlockException)
>> >>>
>> >>> System.out.println(e.getCause().getCause().getMessa
org.*h2*.jdbc.JdbcSQLException
It isn't realted with JDBC. He uses schema name instead of table name
for insert.
On Thu, Jun 22, 2017 at 2:41 PM, Igor Sapego wrote:
> There is still no reply for this ticket. Who can take a look?
> Val? Andrey?
>
> Best Regards,
> Igor
>
> On Tue, Jun 20, 2017 at
I've commented first reply to the question. But actualy I didn't test it.
On Thu, Jun 22, 2017 at 8:24 PM, Andrey Gura wrote:
> org.*h2*.jdbc.JdbcSQLException
>
> It isn't realted with JDBC. He uses schema name instead of table name
> for insert.
>
> On Thu, Jun
; > > expected behaviour as a normal part of system operations.
> > > - Why do we decide that critical thread should monitor each other? For
> > > instance, if all the tasks were blocked and unable to run,
> > > node reset would never occur. As for me, a bet
associated with each thread status exceeded a
> > > > maximum
> > > > > > time
> > > > > > > limit.
> > > > > > >
> > > > > > > Third (not too many options here),
> > > > > > > - `log every
tionBegin`
> > > > > method should be used.
> > > > >
> > > > > -
> > > > > blockingSectionEnd();
> > > > >
> > > > > try {
> > > > > resVer = exchFut.get(exchTimeout, TimeUnit.M
Agree with Andrey.
IGNITE-9723 will be merged to ignite-2.7 branch soon.
On Mon, Oct 1, 2018 at 3:56 PM Andrey Kuznetsov wrote:
>
> Igniters,
>
> There is an inaccuracy in critical worker termination detection, and I'm
> working on a fix right now, see [1]. Also, we have trivial yet important
> f
Nikolay,
I'm looking at IGNITE-9737 and IGNITE-9710 which are critical issues
from my point of view.
I need some time for review, possible fixes and merge.
I will keep you informed.
On Mon, Oct 15, 2018 at 1:46 PM Igor Sapego wrote:
>
> Guys, Python client is in the master and ignite-2.7 already.
ondakov - IGNITE-9663
> Taras Ledkov - IGNITE-9864
> Igor Seliverstov - IGNITE-9292
>
> В Пн, 15/10/2018 в 17:49 +0300, Andrey Gura пишет:
> > Nikolay,
> >
> > I'm looking at IGNITE-9737 and IGNITE-9710 which are critical issues
> > from my point of view.
> &
t; > > > >
> > > > > > ср, 17 окт. 2018 г. в 11:39, Nikolay Izhikov > >:
> > > > > >
> > > > > > > Hello, Igniters.
> > > > > > >
> > > > > > > 9 tickets to go!
> > > > &g
> > > Where do you track those 8 blockers? Can't find them on
> > > > this
> > > > > wiki
> > > > > > > > >
> > > > > > > > > page:
> > > > > > > > > > > >
> > > > > https://cwiki.apache.org/con
Hi,
I believe that the first solution is better than second because it
takes into account network communication time. Average time of
communication between nodes doesn't make sense from my point of view.
So I vote for #1.
On Thu, Jul 13, 2017 at 11:52 PM, Вячеслав Коптилин
wrote:
> Hi Experts,
First solution is bad idea because client could be closed by driver while
user code still uses this client.
17 июля 2017 г. 12:49 PM пользователь "Vladimir Ozerov" <
voze...@gridgain.com> написал:
> I would say this is a usability issue, please file a ticket. But why one
> need to use JDBC when
+1 non-binding
On Sat, Jul 22, 2017 at 2:57 AM, Denis Magda wrote:
> Anton V,
>
> Would you mind closing the vote if it passes? Unfortunately, I won't do
> this, going offline for significant time.
>
> Denis
>
> On Friday, July 21, 2017, Semyon Boikov wrote:
>
>> +1 binding
>>
>> On Fri, Jul 21,
the total time
> needed to complete an operation including network hoops while a server
> (primary or backup) will count only local time.
>
> —
> Denis
>
>> On Jul 17, 2017, at 7:07 AM, Andrey Gura wrote:
>>
>> Hi,
>>
>> I believe that the first s
+1 (non-binding)
On Wed, Jul 26, 2017 at 12:35 AM, Konstantin Boudnik wrote:
> +1 [binding]
>
> - Checked the signature
> - Checked the sha1
> - Successfully ran the build
> - RAT is clean
>
> Things that need to be improved in the next release:
> - neither sha1 nor md5 are trustful checksum'ing
? So, all that’s left to
> do is to count the same on the servers so that those metrics no longer return
> 0.
>
> —
> Denis
>
>> On Jul 25, 2017, at 6:53 AM, Andrey Gura wrote:
>>
>> Den,
>>
>> doesn't make sense from my point if view. And we c
Hi,
I'll do it soon. But there is problem with Zeppelin because CI should
be configured on local machine. So I need more time than usually for
update Ignite version in Zeppelin (e.g. Ignite 2.0 still not relased
in Zeppelin).
On Tue, Aug 1, 2017 at 9:13 AM, Roman Shtykh wrote:
> Denis,
> I updat
+1
On Tue, Sep 12, 2017 at 6:09 PM, Kozlov Maxim wrote:
> +1
>
>> 12 сент. 2017 г., в 17:36, Sergey Kozlov написал(а):
>>
>> +1
>>
>>
>>
>> On Tue, Sep 12, 2017 at 5:21 PM, Vladimir Ozerov
>> wrote:
>>
>>> +1 (binding)
>>>
>>> On Tue, Sep 12, 2017 at 4:24 PM, Pavel Tupitsyn
>>> wrote:
>>>
+1
15 сент. 2017 г. 5:48 PM пользователь "Anton Vinogradov"
написал:
> Igniters,
>
> We have uploaded a 2.2.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc2/
>
> Git tag name is
> 2.2.0-rc2
>
> This release includes the following changes:
>
> Ignite:
> * Checkpoin
Slava and Igniters,
Do you have any suggestions about described problem?
>From my point of view JCache API metrics specification has a number of
statements that can't be uniquely treated by Ignite user because of
implementations details. Most obvious problems here are related with
transactions th
hases. In my opinion, this is the only way
> to have unambiguous metrics in the product.
>
> 2017-09-20 17:58 GMT+03:00 Andrey Gura :
>
>> Slava and Igniters,
>>
>> Do you have any suggestions about described problem?
>>
>> From my point of view JCache API me
ubt we can do
> anything about it.
>
> 2017-09-20 20:38 GMT+03:00 Andrey Gura :
>
>> Alexey,
>>
>> implicit transactions still can cause problems in metrics interpretation:
>>
>> - locks acquiring is still needed;
>> - metrics that taken in account for
+1
Checked:
- Java: Build from sources.
- Tests of vertx-ignite project are passed successfully.
On Mon, Oct 30, 2017 at 7:54 PM, Denis Magda wrote:
> +1 (binding)
>
> —
> Denis
>
>> On Oct 28, 2017, at 3:58 AM, Vladimir Ozerov wrote:
>>
>> Igniters,
>>
>> We have uploaded a 2.3.0 release candi
Denis Magda wrote:
> Igniters,
>
> In my understanding the Prerequisites page [1] is out of date since it
> doesn't contain IBM JDK and Solaris among JDK's and OS's lists.
>
> *Andrey Gura,
> *Do you know IBM JDK and Solaris versions Ignite was tested against
we
> > > > > > > > > > had a performance drop, and I think it is pretty
> important
> > > that
> > > > > we
> > > > > > > > > address
> > > > > > > > > > it prior to the release.
> > > > > > > > > >
> > > > > > > > > > Can we please get an update for these tickets?
> > > > > > > > > >
> > > > > > > > > > IGNITE-2948 <
> > > https://issues.apache.org/jira/browse/IGNITE-2948
> > > > >
> > > > > -
> > > > > > > > > > Optimize usage of GridCacheConcurrentMap
> > > > > > > > > > IGNITE-1786 <
> > > https://issues.apache.org/jira/browse/IGNITE-1786
> > > > >
> > > > > -
> > > > > > > Need
> > > > > > > > > to
> > > > > > > > > > implement ODBC driver for Ignite
> > > > > > > > > >
> > > > > > > > > > Once these issues are resolved, we can move to the
> testing
> > > > phase
> > > > > > > > > (probably
> > > > > > > > > > a week), and then send it for the vote.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Fri, Apr 29, 2016 at 3:12 AM, Yakov Zhdanov <
> > > > > > yzhda...@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> I think we are almost done with odbc support and I hope
> > that
> > > > we
> > > > > > can
> > > > > > > > > >> release
> > > > > > > > > >> about mid or second half of May.
> > > > > > > > > >>
> > > > > > > > > >> --Yakov
> > > > > > > > > >>
> > > > > > > > > >> 2016-04-27 11:13 GMT+03:00 sssow :
> > > > > > > > > >>
> > > > > > > > > >> > Hi,
> > > > > > > > > >> > When will you release 1.6?
> > > > > > > > > >> > Thank you,
> > > > > > > > > >> >
> > > > > > > > > >> >
> > > > > > > > > >> >
> > > > > > > > > >> >
> > > > > > > > > >> > --
> > > > > > > > > >> > View this message in context:
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-1-6-release-timelines-tp7388p8618.html
> > > > > > > > > >> > Sent from the Apache Ignite Developers mailing list
> > > archive
> > > > at
> > > > > > > > > >> Nabble.com.
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>
--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com
de to provide stable release.
> >>>
> >>> As you know we have a huge amount of tests and some of them now failing
> >>> at release branch.
> >>> Fails can be found here:
> >>>
> >>>
> http://149.202.210.143:8111/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=ignite-1.6
> >>>
> >>> So, feel free to start investigations and fix issues :)
> >>>
> >>
> >>
> >
>
--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com
t? I would like to
> add the example and some words on the feature to readme. io so that the
> communicate can leverage from this.
>
> —
> Denis
>
--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com
need to modify
> these properties - IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS and
> IGNITE_TX_DEADLOCK_DETECTION_TIMEOUT.
>
> Could you elaborate on the procedure more technically so that its clear
> why these properties are needed?
>
> —
> Denis
>
> On May 16, 2016, at 3:47 PM, Andrey Gura wrot
e size ?
> In case user sessions expire by timeout the more appropriate solution would
> be listening to
> EVT_CACHE_OBJECT_EXPIRED event.
> You can also set eager expiration by calling
> CacheConfiguration.setEagerTtl(true)
> to make Ignite expire values automatically.
>
>
process?
>
> To my knowledge, the deadlock detection process should run after
> transaction has timed out and should include the deadlocked keys into the
> timeout exception message. Am I wrong?
>
> D.
>
> On Wed, May 18, 2016 at 9:38 AM, Andrey Gura wrote:
>
> >
u please
> file a ticket on it?
>
> Thanks,
> D.
>
> On Wed, May 18, 2016 at 10:16 AM, Andrey Gura wrote:
>
> > As I can see from GridCacheSwapManager code Ignite doesn't fire eviction
> > events from offheap.
> >
> > On offheap evict GridCacheSwapMan
If it is the transaction
> in deadlock, then I think it should not matter, as it is blocked anyway.
>
> D.
>
> On Sun, May 22, 2016 at 2:11 PM, Andrey Gura wrote:
>
> > Dmitry,
> >
> > Do you think that we should configure deadlock detection using cache
> &
t I mean), then
> each
> > OffHeap put will increased OffHeap get, because readOffheapPointer take
> > place on OffHeap put.
> >
> > The thing confuses my:
> > Has any rules metrics works?
> > Where works with metrics value must take place?
>
>
--
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com
/docs/transactions#deadlock-detection-in-pessimistic-transactions
> >
>
> —
> Denis
>
> > On May 23, 2016, at 2:28 PM, Andrey Gura wrote:
> >
> > Dmitry,
> >
> > In this case "blocked" means that transaction can't be rolled
s());
>
> We execute only put, but get counter also incremented.
>
> Is anyone has another opinion?
>
>
>
> On Wed, May 25, 2016 at 2:51 PM, Andrey Gura wrote:
>
> > Denis,
> >
> > I disagree. readOffheapPointer doesn't touch offheap get/put metrics
>
deadlock-detection into a separate page. This way it will
> be
> >> more prominent and easier to access.
> >>
> >> I think we can mention 2 topics on that page:
> >> - deadlock-free transactions
> >> - deadlock detection
> >>
>
201 - 300 of 564 matches
Mail list logo
