educing cluster availability when operations can be safely
> completed.
>
> 2018-01-23 2:22 GMT+03:00 Yakov Zhdanov :
>
> > Val,
> >
> > Your suggestion to prohibit any cache operation on partition loss does
> not
> > make sense to me. Why should I care about
Alex Goncharuk, can you please take a look and comment? Test seems to be
valid from my standpoint.
Yakov Zhdanov,
www.gridgain.com
2018-01-22 23:14 GMT-08:00 ALEKSEY KUZNETSOV :
>
> created ticket with reproducer [1]
>
> I think the fix should be to clear context in tx.close()
&
Val,
Your suggestion to prohibit any cache operation on partition loss does not
make sense to me. Why should I care about some partition during particular
operation if I don't access it? Imagine I use data on nodes A and B
performing reads and writes and node C crashes in the middle of tx. Should
Guys, can you check if you call tx.close(); or properly use
try-with-resources construct?
Tx context should not be cleared automatically otherwise user would not get
any notification that original transaction failed. I believe context should
be cleared on tx.close().
Anyway, let's take a look at
Thanks Tim! I hope Vlad can review your patch. If this does not happen in
2-3 days I will take a look. Can you please let me know on weekend if I
need to?
--Yakov
2018-01-16 23:36 GMT+03:00 Tim Onyschak :
> Hey all,
>
> I created a patch and posted to user group, was told feed back would be
> le
>> How about using both escaping and a text file with the name? One can
think of the escaped name as of a kind of ID, which happens to be
human-readable when the name is in ASCII,
and as unreadable as an UUID when the name is in UTF. This way we have all
the readability in the common case (when nam
To understand how much storage you need for cache group "X" and watch the
trends.
Anyway, folder named by ID and txt file inside should do the trick =)
--Yakov
>> And then a new node appears with a different kind of file system..
This is hardly possible. And I suggest not to
>> Escaping removes all limitations and does not affect usability.
Disagree. You will never ever relate smth like "fdee0456adcc" to
"мои_данные".
Guys, I just realized that we creat
+0080 .. U+ [1]
I also would think over some intersection of allowed file name characters
in different file systems [2]
[1] https://dev.mysql.com/doc/refman/5.7/en/identifiers.html
[2] https://en.wikipedia.org/wiki/Filename
Yakov Zhdanov
I agree with your suggestion to add required properties to node attributes
under specific key disregarding includeProperties value.
--Yakov
What if we change default to empty array? Users that want to include
everything will init it to null manually
--Yakov
Guys, this config property allows to filter out system/env properties
- org.apache.ignite.configuration.IgniteConfiguration#getIncludeProperties
By default this returns null which is "include everything". Pass empty
array to filter all or non-empty for filtering.
--Yakov
unstable topologies.
Btw, I have just got an idea - if we need to rebalance partition to more
than 1 node then we need to scan it only once. I believe now we do it each
time from very beginning.
Yakov Zhdanov,
www.gridgain.com
2017-12-27 6:14 GMT+03:00 Dmitriy Setrakyan :
> Yakov,
>
> As o
Ilya, agree. I like IGNITE_AVAILABLE_CPU more.
Yakov Zhdanov,
www.gridgain.com
2017-12-26 16:36 GMT+03:00 Ilya Lantukh :
> Hi Yakov,
>
> I think that property IGNITE_NODES_PER_HOST, as you suggested, would be
> confusing, because users might want to reduce amount of available res
Cross-posting to dev list.
Guys,
Suggestion below makes sense to me. Filed a ticket
https://issues.apache.org/jira/browse/IGNITE-7310
Perhaps, Arseny would like to provide a PR himself ;)
--Yakov
2017-12-26 14:32 GMT+03:00 Arseny Kovalchuk :
> Hi guys.
>
> Ignite configures all thread pools,
Yakov Zhdanov created IGNITE-7310:
-
Summary: Ignite should be easily configured to share hardware
resources between instances
Key: IGNITE-7310
URL: https://issues.apache.org/jira/browse/IGNITE-7310
Hello!
I tried to summarize some ideas on how to make ATOMIC caches stay
consistent in case of topology changes.
Imagine partitioned ATOMIC cache with 2 backups configured (primary + 2
backup copies of the partition). One of possible scenarios to get to
primary and backups divergence is the follo
Great news, Pavel! As a Linux user I will definitely try that and let you
know on results.
--Yakov
How about we explain it in javadocs and properly document on wiki? Guys, I
would do this at some point when there is no another bigger issue in Ignite
=)
--Yakov
Thanks for update, Petr. I like the solution. I think we can go ahead.
--Yakov
Petr, what debs and rpms can I currently download using apache.org/dist?
Please provide examples. I also think you should mostly work with mirrors.
Correct?
--Yakov
I agree with Alex.
Mikhail, you will have to allocate this "safe buffer" during prepare step.
I would add to Alex idea that each thread allocates its own "safe buffer"
and internal threads do not release this buffer and only enlarge if
necessary. Of course, if buffers occasionally grows too large
Yakov Zhdanov created IGNITE-7195:
-
Summary: GridToStringBuilder should limit large collections output
to first N elements
Key: IGNITE-7195
URL: https://issues.apache.org/jira/browse/IGNITE-7195
Hello!
What is your JIRA username?
--Yakov
2017-12-04 18:25 GMT+03:00 Иванов Петр :
> Hi, Igniters!
>
>
> I'd like to contribute into Apache Ignite and can take a task of creating
> RPM and DEB packages in order to try to include correctly packed future
> releases into main linux distributions
Guys, how about having 2 native threads - one calling some java method,
another one monitoring that the first one is active and is not stuck on
safepoint (which points to GC pause)? Testing GC pause with java thread is
a bit strange and can give info only after GC pause finishes. Native
threads can
This seems to be incorrect place for implementing it. I would think of
something more generic like IgniteClusterMBean. It should also work for any
implementation of discovery SPI if one ever appears =)
--Yakov
+1 for warning about potential deadlock and improving javadocs
--Yakov
I would also consider having docs under separate git repository. Separate
since we need to have an opportunity to revisit documentation for already
released versions.
--Yakov
Agree
--Yakov
I would consider moving decent questions to mailing lists asking to do so
in response to gitter requests and at some point stop gitter.
--Yakov
Alexey, I agree. Feel free to file a ticket and provide the fix. You should
suppress exceptions on handshake response unmarshall and continue to the
rest of IPs. Please make sure that exception trace is still logged if debug
level is enabled for logger.
--Yakov
2017-10-20 11:12 GMT+03:00 Alexey P
Vladimir, I think serverSideDml is better.
--Yakov
Val, I really like your idea to implement common mechanism for all APIs.
Can you please file a ticket?
--Yakov
>>Second of all, it seems that we send a network message from primary node
to
local backup, which doesn't make much sense to me and looks like
unnecessary performance overhead.
This does not work. Remember CLOCK mode for atomic updates? We removed that
mode. You need globally growing version to ma
>>That's a very useful suggestion. Can it be supported for other APIs as
>> well, not only transactions?
>> -Val
Val, please clarify. What APIs do you mean?
--Yakov
Really like .withTag() suggestion!
--Yakov
I agree with Vladimir here. I always have some awkward feelings when
explaining our optimistic transactions behavior. Let's fix it now.
--Yakov
If user has Ignite deployment and does not want Ignite to automatically
change this property and does not want to set it to false. Which means user
wants to have completely default behavior as we have now.
--Yakov
StorageConfiguration + StorageRegionConfiguration
--Yakov
> I guess it is safe to assume that at this point we came to a consensus?
Alex, I think so. Let's carve it in stone (code).
--Yakov
The issue has already been picked up by VK.
Dmitry, after some thought I find it a little bit weird to set system
property automatically without any way to restore default behavior.
--Yakov
hmm.. Dmitry, your suggestion may work if Ignite is started before any of
network layer class is loaded/called. E.g. this will not work if Ignite is
started inside application or web server.
--Yakov
I like Vladimir's suggestion - StorageConfiguration -
StorageRegionConfiguration
--Yakov
Val, I see now.
For example, this http://apache-ignite-users.70518.x6.nabble.com/How-
to-correctly-shut-down-Ignite-Application-td12548.html could happen due to
address passed to
org.apache.ignite.internal.util.IgniteUtils#reachable(java.net.InetAddress,
int) is NULL.
I suspect there may be probl
Yakov Zhdanov created IGNITE-6503:
-
Summary: Need to test Ignite in IPv6 environment
Key: IGNITE-6503
URL: https://issues.apache.org/jira/browse/IGNITE-6503
Project: Ignite
Issue Type
Yakov Zhdanov created IGNITE-6502:
-
Summary: Need to output warning if -Djava.net.preferIPv4Stack=true
is not set
Key: IGNITE-6502
URL: https://issues.apache.org/jira/browse/IGNITE-6502
Project
Pavel, we can optionally enforce that, but not by default.
Dmitry, the problem is the following. User configures Ignite cache and
query entity, does several puts than empty results for SQL. The reason is
very simple - typo in class name or simply different classes in
configuration and of actual ca
I would just create another category for logging configuration, e.g.
ignite.config.log which by default should use our default file appender and
output configuration to that category with info priority. Let's begin with
IgniteConfiguration.toString();
--Yakov
>Any major change in data/index page format. E.g. this could happen once
transactional SQL is ready.
I would suggest we automatically disable this feature for databases created
with older versions.
--Yakov
Fully agree. As Alex mentioned web servers support dev and prod modes. We
need to do the same and default mode should be dev with warning on startup
and ability to change in runtime.
--Yakov
Vladimir,
Can you please describe the situation when 2 is possible, but 4 is not?
--Yakov
Val, can you please provide links to threads you meant? I will take a look.
--Yakov
Vladimir, I like the suggestion. We should definitely try it.
--Yakov
Bas, thanks for joining!
Can you please point me to the page listing all types of issue LGTM can
find (like this one -
https://scan.coverity.com/faq#what-types-of-issues-tool-find)?
LGTM really helped to find some bugs like incorrect key type when working
with hash map instance, unnecessary boxi
Guys, I we should additionally provide ability to manually switch mvcc
coordinator via MBean passing order or ID of a new one. We already have all
the machinery for this.
--Yakov
ot really understand mvcc for atomic cache, could you please
> provide
> > some real use case.
> >
> > Thank you
> >
> > On Mon, Sep 18, 2017 at 1:37 PM, Yakov Zhdanov
> > wrote:
> >
> > > Ouch... of course it makes sense for atomic caches. Seems I am not
> fully
> > > switched on after weekend =)
> > >
> > > Agree on other points.
> > >
> > > --Yakov
> > >
> >
>
Ouch... of course it makes sense for atomic caches. Seems I am not fully
switched on after weekend =)
Agree on other points.
--Yakov
Vladimir, should it be on IgniteConfiguration or on CacheConfiguration? I
think mvcc should be enabled on per cache basis and moreover it makes sense
only for tx caches.
--Yakov
1. Agree. Let's disable MVCC by default.
2. Sam, if user wants to have dedicated mvcc-coordinator, then we can use
configuration you suggested. However, I expect more properties will be
needed. How about having MvccConfiguration bean? Once topology has no
dedicated coordinators, topology should pic
Guys, it seems that we have the same issue that was described in thread -
Specifying location of persistent storage location
I filed a ticket some time ago -
https://issues.apache.org/jira/browse/IGNITE-6285, Alex G, can you take a
look if this ticket makes sense?
--Yakov
Guys,
I remember we tried some static code analysis tools for Java (a bit awkward
not having one yet), but we did not setup regular checks.
I want to return to this. As result I would like to have code analysis tool
running on TC on daily basis and also established process to review and fix
code
>>Can we have separate MemoryPolycy for every CacheGroup? In that case we
could auto generate MemoryPolycy based on CacheGroup settings and have a
"cache level" persistence settings.
>>We can use some kind of MemoryPolicyTemplate to add default values and
even re-use existing MemoryPolicy if all se
> I like the idea of having PersistentMemoryPolicy configuration class.
I like the idea, too.
--Yakov
Yakov Zhdanov created IGNITE-6380:
-
Summary: Exception should be thrown on cache creation attempt
inside transaction
Key: IGNITE-6380
URL: https://issues.apache.org/jira/browse/IGNITE-6380
Project
Agree with Vladimir - the second option seems to be more interesting.
Guys, can we also give recommendations to user on building more effective
data model? For example, can we detect dates in string or indexes on
boolean fields that most probably have very low selectivity or indexed
field which is
Val, can you please help?
--Yakov
2017-09-12 14:30 GMT+03:00 Ilya Kasnacheev :
> Hello Igniters,
>
> It came to our attention that our handling of Web Sessions is inconsistent:
> https://stackoverflow.com/questions/45648884/apache-
> ignite-spring-secutiry-error
>
> I've filed https://issues.apa
Agree with Vladimir. However, this will break API compatibility. So, at
this point this is impossible.
--Yakov
Dmitry, can you please take a look at public API change.
Ticket - https://issues.apache.org/jira/browse/IGNITE-425
PR - https://github.com/apache/ignite/pull/2372
Issues:
1. Do you see any other option other than creating separate class? As for
me I don't.
2. In a new class we still have initial
Agree that implicit actions are always source of issues of different kinds.
Alex, having persistence enabled by default does not seem to be a good idea.
>I think if we go with "persistence per cache" path, we must just enforce the
correct configuration and let users configure the rest
What do yo
Guys, according to this -
http://apache-ignite-users.70518.x6.nabble.com/Task-management-MapReduce-amp-ForkJoin-performance-penalty-td16542.html
- I would think that we need to disable result caching by default.
Or at least find out why it is so costly.
--Yakov
Yakov Zhdanov created IGNITE-6285:
-
Summary: Enhance persistent store paths logging on start
Key: IGNITE-6285
URL: https://issues.apache.org/jira/browse/IGNITE-6285
Project: Ignite
Issue
Yakov Zhdanov created IGNITE-6284:
-
Summary: Add IgniteCompute.withTaskNoResultCache() which should
have similar effect as @ComputeTaskNoResultCache
Key: IGNITE-6284
URL: https://issues.apache.org/jira/browse
Raymond, I think most of Ignite users run on ipv4. So, issues with v6 in
this case are hardly possible =)
--Yakov
+ dev
Pavel Tupitsin, can you please check that
org.apache.ignite.configuration.IgniteConfiguration#setConsistentId has it
platform counterpart? I could not find it.
Raymond, you can explicitly set a bind address for Ignite with public
string Localhost { get; set; }. This will make consistent ID t
NPE should be fixed.
NPE does not have any message, this is why top level exception does not
have it as well.
--Yakov
2017-09-04 17:19 GMT+03:00 Dmitriy Setrakyan :
> On Mon, Sep 4, 2017 at 3:05 AM, Yakov Zhdanov wrote:
>
> > >> Why are we throwing checked exceptions without
Well, let's leave it as is for now, since I don't see any easy way to
consistently solve this.
--Yakov
>> Why are we throwing checked exceptions without any error message? Should
we fix it?
I don't think it is important. This exception is instantiated inside
IgniteUtils.cast() and has a cause.
--Yakov
We already have similar ticket -
https://issues.apache.org/jira/browse/IGNITE-5653
I suggest we prioritize it.
--Yakov
Ilya, go ahead with the plan you suggested.
--Yakov
Ilya, I reviewed your test and I now see the point.
Is the same possible with server-server? Or failure process will be
initiated for remote node by local one?
Will the following work for client? If connection fails then client takes a
pause for 1 sec with Thread.sleep() and takes another attempt
>>Vova, I am not sure I understand. How will it be released?
This can be a module containing only java8 related stuff including method
that converts IgniteFuture to completable future. And it should be built
with java8.
--Yakov
Ilya, can you please provide more details? Is this client or server failing
to connect?
--Yakov
Agree. Vladimir's suggestions should work.
We cannot drop Java7 now.
--Yakov
Yakov Zhdanov created IGNITE-6239:
-
Summary: Provide an ability to change configuration in runtime
Key: IGNITE-6239
URL: https://issues.apache.org/jira/browse/IGNITE-6239
Project: Ignite
CompletableFuture is part of java 8.
--Yakov
2017-08-31 4:46 GMT+03:00 Dmitriy Setrakyan :
> Igniters,
>
> I received the following proposal in my blog. I think this is useful. Any
> thoughts?
>
> Please extend IgniteFuture by conversion method to CompletableFuture. I
> > bored to write somethin
I would postpone review until we come to a clear decision on what should be
done if filter or transformer fails. I don't think cancelling query is too
much. From my standpoint this is a kind of heuristic exception and may
break some sensitive logic.
Thanks!
--
Yakov Zhdanov, Directo
Igniters, esp. Alex Goncharuk,
There was a problem recently discovered
with
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager#locDepOwner
As far as I remember, this flag is automatically set if Ignite detects
public API usage outside of deployment class loader that implies t
I think I have already agreed on a separate class since it seems to be the
only option due to generics issue. Should we extract a super class?
We can put hard requirement that filter and transformer cannot throw
exception (same as cache interceptor). If exception is thrown then we
cancel the query
ontinuousQueryHandler.java#L791
>
> [2] https://github.com/apache/ignite/blob/master/modules/core/
> src/test/java/org/apache/ignite/internal/processors/cache/
> query/continuous/GridCacheContinuousQueryAbstractSelfTest.java#L359
>
>
> 29.08.2017 14:46, Yakov Zhdanov пишет:
>
&
> If filter throws exception entry would be passed to listener.
this is strange. Imagine a filter that very rarely throws some runtime
exception due to external or environmental reasons, but in case of normal
execution filter evaluates to false. In case of error entry is passed to a
local listener
I don't like the idea of having separate class, but it seems to be the only
way as there are too many API and generics differences.
Nikolay, I would also suggest you extract some super class for continuous
query. It will help to avoid code duplicates.
As far as remote transformer failure - we sho
>As far as Maven archetype, Yakov, is the only purpose of it to load a
project, so users can add tests to it?
Yes, but not just add. We will also be providing test examples, data
loading application sample, shell scripts, etc. This can be pretty handy
thing to create project with all dependencies
Sergey, can you please elaborate?
--Yakov
2017-08-26 23:51 GMT+03:00 Sergey Kozlov :
> The idea is great!
>
> Also I would suggest an ability to run new (modified) tests 100 times in
> loop on the CI server to make sure that they don't cause no sporadic
> failures (we can include that as part of
Guys,
I want to discuss the subject again. It is pretty vivid that having wide
set of local unit and simple integration tests most likely help to avoid
many failures and bugs when going to server environment.
I participated in many POC and I can say for sure - if developers are not
implementing l
Agree, let's release new version including tickets mentioned by Denis and
Ivan.
--Yakov
Raul, any ideas on startup counter?
BTW, we have google analytics applied to Ignite site. Can it be used to
count node starts?
--Yakov
Andrey, feel free to file a ticket and remove the parameter =)
--Yakov
>It's not public API, just implementation detail.
>GridFutureAdapter::unregisterWaiter is not thread state in general. It
>won't work properly if the argument is not current thread. And also I
>couldn't prove clearly it wouldn't drop some unrelated Node in concurrent
>operation.
Andrey, it seems
> I think as a first step, the deadlock detection should kick off after a
> certain timeout, even if the transaction timeout was not set.
> What do you think?
Dmitry, I thought that was what I suggested, no? =)
--Yakov
Andrey, do you have an example of such method in Ignite public or private
API?
If it is not Ignite API please provide an example.
--
Yakov Zhdanov
101 - 200 of 738 matches
Mail list logo
