[jira] [Created] (IGNITE-14060) UsageTest#multiRootConfigurationTest fails in main
Valentin Kulichenko created IGNITE-14060: Summary: UsageTest#multiRootConfigurationTest fails in main Key: IGNITE-14060 URL: https://issues.apache.org/jira/browse/IGNITE-14060 Project: Ignite Issue Type: Bug Affects Versions: 3.0.0-alpha1 Reporter: Valentin Kulichenko [~sergey-chugunov] Sergey, looks like you created this test. Please take a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14059) Thin Python client doesn't work with nested complex objects
Igor Sapego created IGNITE-14059: Summary: Thin Python client doesn't work with nested complex objects Key: IGNITE-14059 URL: https://issues.apache.org/jira/browse/IGNITE-14059 Project: Ignite Issue Type: Bug Components: python, thin client Affects Versions: python-0.3.4 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: python-0.4.0 Attachments: main.py Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14058) Python Thin client: get boolean type return integers
Igor Sapego created IGNITE-14058:
Summary: Python Thin client: get boolean type return integers
Key: IGNITE-14058
URL: https://issues.apache.org/jira/browse/IGNITE-14058
Project: Ignite
Issue Type: Bug
Components: python, thin client
Affects Versions: python-0.3.4
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: python-0.4.0
Steps:
- put boolean value in cluster
{code}
from pyignite import Client
from pyignite.datatypes import *
client = Client()
client.connect('127.0.0.1', 10800)
cache = client.get_or_create_cache("test")
cache.put(1, [True, False], key_hint=IntObject, value_hint=BoolArrayObject)
{code}
- get value
{code}
from pyignite import Client
from pyignite.datatypes import *
client = Client()
client.connect('127.0.0.1', 10800)
cache = client.get_or_create_cache("test")
result = cache.get(1, key_hint=IntObject)
print(*[str(arr_item).lower() for arr_item in result])
{code}
Actual:
- return integers
{code}
0 1
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Missed (non-suited) tests
Hi, Ilya! I made a fix to the check. Now it aggregates info about tests and suites from all modules and then validates it. Could you please review the PR [1]? I tried to move some tests between modules, but unfortunately it still looks like spaghetti. So I reverted all changes to testsuites (new and splitted suites) and reworked the check. [1] https://github.com/apache/ignite/pull/8367 On Mon, Dec 28, 2020 at 2:03 PM Ilya Kasnacheev wrote: > Hello! > > You could try to move these tests as .java files between modules in a > separate commit. I think I could review it. > > Regards, > -- > Ilya Kasnacheev > > > пт, 25 дек. 2020 г. в 17:19, Max Timonin : > > > Hi! > > > > Ilya thanks for the reply! I agree that it's a valid case when a test is > > part of multiple suites in different modules. But it is definitely a bug > > that the test is written in a module where it can't be run at all and > aimed > > to run within different modules (core tests in core that require h2). I > > propose to fix this issue. > > > > I'm going to check all such tests and move them to the right module. As I > > can see there are about 100 such test classes, but I hope that most of > them > > follow only a few patterns. > > > > On Fri, Dec 25, 2020 at 2:58 PM Ivan Daschinsky > > wrote: > > > > > Hi! > > > >> I'm not sure that we should assume every test is only run from one > > test > > > suite. One test may be run from different test suites located in > > different > > > modules. > > > Agree. For example, if we introduce this limitation, zk suites will be > > > broken. > > > > > > > > > пт, 25 дек. 2020 г. в 14:48, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > > > > > > Hello! > > > > > > > > Sorry for the long wait. > > > > > > > > I'm not sure that we should assume every test is only run from one > test > > > > suite. One test may be run from different test suites located in > > > different > > > > modules. > > > > > > > > I wonder if we can drop this requirement, check all the modules > > > > transitively for used/unused tests. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > ср, 2 дек. 2020 г. в 18:23, Max Timonin : > > > > > > > > > Hi, > > > > > > > > > > I don't think so. It looks like a bug that tests fail if one runs > > them > > > > > within their module (actually, what is the goal of this test?). The > > > check > > > > > showed us this problem, there is no need to fix the check. > > > > > > > > > > Currently I see two ways: > > > > > 1. Find the right module for every misplaced test. There are 104 > > tests, > > > > > maybe just move them all to the target module? If TeamCity runs > them > > > > within > > > > > the indexing module only is there a reason to have a test in the > core > > > > > module at all? > > > > > 2. Back to my previous proposal - create fake suites within a > module, > > > > then > > > > > replace test classes in a target suite with the single class of the > > > fake > > > > > suite. > > > > > > > > > > > > > > > > > > > > On Wed, Dec 2, 2020 at 5:38 PM Ilya Kasnacheev < > > > > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hello! > > > > > > > > > > > > I think this means that we should abandon the plan of moving > tests > > > > > between > > > > > > suites, and that your tool has to understand the dependency graph > > > > > > between modules' tests when assessing what's included and what's > > not. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > ср, 2 дек. 2020 г. в 15:56, Max Timonin >: > > > > > > > > > > > > > Hi, Ilya! > > > > > > > > > > > > > > I've checked testsuites. There is an issue. For example > > > > > > > *IgniteBinaryCacheQueryTestSuite* suite is now in 2 modules: > > > > > ignite-core, > > > > > > > ignite-indexing. On TeamCity it runs by "Query 1" suite. > > Simplified > > > > > maven > > > > > > > command for the suite is > > > > > > > > > > > > > > mvn -DtestIgniteBinaryCacheQueryTestSuite -am -pl > > :ignite-indexing > > > > > > > surefire:test > > > > > > > > > > > > > > Sequence of actions is: > > > > > > > 1. Find modules dependencies (*-am* flag): ignite-tools, > > > ignite-core; > > > > > > > 2. Run the test command for every module. In this step the > maven > > > > tries > > > > > to > > > > > > > find the specified test for every module. This is good news, so > > we > > > > > don't > > > > > > > need to create new TeamCity suites for such splitted suites. > > > > > > > > > > > > > > But the run performs within the current module classpath, so > for > > > the > > > > > core > > > > > > > module the test suite fails with error "Add module > > > 'ignite-indexing' > > > > to > > > > > > the > > > > > > > classpath of all Ignite nodes". Maven can't resolve it. > > > > > > > > > > > > > > The only way to work with it is to specify additional classpath > > > > > elements > > > > > > > for tests with setting > > > > > >
[jira] [Created] (IGNITE-14057) Python thin: implement support for big-endianness
Igor Sapego created IGNITE-14057: Summary: Python thin: implement support for big-endianness Key: IGNITE-14057 URL: https://issues.apache.org/jira/browse/IGNITE-14057 Project: Ignite Issue Type: Bug Components: python, thin client Affects Versions: python-0.3.4 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: python-0.4.0 Currently, big endian byte order is not supported in Python Thin client. Need to implement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Shiva, I've cherry-picked the issue to 2.10 branch. https://issues.apache.org/jira/browse/IGNITE-13912 Ilya, Thank you for preparing the patch. I've cherry-picked to 2.10 it too. https://issues.apache.org/jira/browse/IGNITE-14039 On Mon, 25 Jan 2021 at 17:50, Ilya Kasnacheev wrote: > > Hello! > > I have pushed the developer warning, javadoc warning and documentation > update to https://issues.apache.org/jira/browse/IGNITE-14039 about the > dangers of WAL state change. > > Please cherry-pick it to 2.10 branch or mention me if it's OK for me to do > this. > > Regards, > -- > Ilya Kasnacheev > > > пн, 25 янв. 2021 г. в 14:44, Никита Сафонов : > > > Hi Denis, > > > > Thanks a lot! > > I'll update my PR's accordingly. > > > > Regards, > > Nikita > > > > сб, 23 янв. 2021 г. в 00:59, Denis Magda : > > > > > Nikita, thanks. I reviewed those and shared some suggestions. Please take > > > them into consideration. > > > > > > - > > > Denis > > > > > > > > > On Fri, Jan 22, 2021 at 1:45 PM Никита Сафонов < > > vlasovpavel2...@gmail.com> > > > wrote: > > > > > > > Hi everyone, > > > > > > > > The following documentation tasks for the important features now have > > > PATCH > > > > AVAILABLE status: > > > > > > > >- Caches warming up strategy - > > > >https://issues.apache.org/jira/browse/IGNITE-13385?src=confmacro > > > >- Update on JMX default configuration removal - > > > >https://issues.apache.org/jira/browse/IGNITE-13606?src=confmacro > > > >- Control.sh indexes manipulation commands - > > > >https://issues.apache.org/jira/browse/IGNITE-13285?src=confmacro > > > > > > > > Please see the PR's attached to the tickets. > > > > > > > > Thank you! > > > > > > > > Regards, > > > > Nikita > > > > > > > > пт, 22 янв. 2021 г. в 18:03, shm : > > > > > > > > > Hi All, > > > > > Can you please also include a critical ticket > > > > > https://issues.apache.org/jira/browse/IGNITE-13912 > > > > > to 2.10 In terms of functionality it is a blocker. Still some > > > debugging > > > > is > > > > > going on related to this issue. > > > > > > > > > > Thanks, > > > > > Shiva > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > > > > > >
[jira] [Created] (IGNITE-14056) Python thin: Readme and other docs are outdated
Igor Sapego created IGNITE-14056: Summary: Python thin: Readme and other docs are outdated Key: IGNITE-14056 URL: https://issues.apache.org/jira/browse/IGNITE-14056 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Igor Sapego Assignee: Igor Sapego The readme files for thin clients should be updated accordingly as now they're separate products be following rules: * readme is located in root directory * how to install from zip * how to upgrade if a previous version installed -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hello! I have pushed the developer warning, javadoc warning and documentation update to https://issues.apache.org/jira/browse/IGNITE-14039 about the dangers of WAL state change. Please cherry-pick it to 2.10 branch or mention me if it's OK for me to do this. Regards, -- Ilya Kasnacheev пн, 25 янв. 2021 г. в 14:44, Никита Сафонов : > Hi Denis, > > Thanks a lot! > I'll update my PR's accordingly. > > Regards, > Nikita > > сб, 23 янв. 2021 г. в 00:59, Denis Magda : > > > Nikita, thanks. I reviewed those and shared some suggestions. Please take > > them into consideration. > > > > - > > Denis > > > > > > On Fri, Jan 22, 2021 at 1:45 PM Никита Сафонов < > vlasovpavel2...@gmail.com> > > wrote: > > > > > Hi everyone, > > > > > > The following documentation tasks for the important features now have > > PATCH > > > AVAILABLE status: > > > > > >- Caches warming up strategy - > > >https://issues.apache.org/jira/browse/IGNITE-13385?src=confmacro > > >- Update on JMX default configuration removal - > > >https://issues.apache.org/jira/browse/IGNITE-13606?src=confmacro > > >- Control.sh indexes manipulation commands - > > >https://issues.apache.org/jira/browse/IGNITE-13285?src=confmacro > > > > > > Please see the PR's attached to the tickets. > > > > > > Thank you! > > > > > > Regards, > > > Nikita > > > > > > пт, 22 янв. 2021 г. в 18:03, shm : > > > > > > > Hi All, > > > > Can you please also include a critical ticket > > > > https://issues.apache.org/jira/browse/IGNITE-13912 > > > > to 2.10 In terms of functionality it is a blocker. Still some > > debugging > > > is > > > > going on related to this issue. > > > > > > > > Thanks, > > > > Shiva > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > >
[jira] [Created] (IGNITE-14055) Deadlock in timeoutObjectProcessor between 'send messag'e & 'handshake timeout'
Anton Kalashnikov created IGNITE-14055:
--
Summary: Deadlock in timeoutObjectProcessor between 'send messag'e
& 'handshake timeout'
Key: IGNITE-14055
URL: https://issues.apache.org/jira/browse/IGNITE-14055
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
Cluster hangs after jvm pauses on one of server nodes.
Scenario:
1. Start three server nodes with put operations using StartServerWithTxPuts.
2. Emulate jvm freezes on one server node by running the attached script:
{{*sh freeze.sh *}}
3. Wait until the script has finished.
Result:
The cluster hangs on tx put operations.
The first server node continuously prints:
{{{noformat}}}
{{}}{{[2020-11-03 09:36:01,719][INFO
][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
rmtAddr=/127.0.0.1:57714][2020-11-03 09:36:01,720][INFO
][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
Received incoming connection from remote node while connecting to this node,
rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
09:36:01,922][INFO
][grid-nio-worker-tcp-comm-0-#23%TcpCommunicationSpi%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
rmtAddr=/127.0.0.1:57716][2020-11-03 09:36:01,922][INFO
][grid-nio-worker-tcp-comm-0-#23%TcpCommunicationSpi%][TcpCommunicationSpi]
Received incoming connection from remote node while connecting to this node,
rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
09:36:02,124][INFO
][grid-nio-worker-tcp-comm-1-#24%TcpCommunicationSpi%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
rmtAddr=/127.0.0.1:57718][2020-11-03 09:36:02,125][INFO
][grid-nio-worker-tcp-comm-1-#24%TcpCommunicationSpi%][TcpCommunicationSpi]
Received incoming connection from remote node while connecting to this node,
rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
09:36:02,326][INFO
][grid-nio-worker-tcp-comm-2-#25%TcpCommunicationSpi%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
rmtAddr=/127.0.0.1:57720][2020-11-03 09:36:02,327][INFO
][grid-nio-worker-tcp-comm-2-#25%TcpCommunicationSpi%][TcpCommunicationSpi]
Received incoming connection from remote node while connecting to this node,
rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
09:36:02,528][INFO
][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
rmtAddr=/127.0.0.1:57722][2020-11-03 09:36:02,529][INFO
][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
Received incoming connection from remote node while connecting to this node,
rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3]}}
{{{noformat}}}{{}}
The second node prints long running transactions in prepared state ignoring the
default tx timeout:
{{{noformat}}}
{{1}}{{[2020-11-03 09:36:46,199][WARN
][sys-#83%56b4f715-82d6-4d63-ba99-441ffcd673b4%][diagnostic] >>> Future
[startTime=09:33:08.496, curTime=09:36:46.181, fut=GridNearTxFinishFuture
[futId=425decc8571-4ce98554-8c56-4daf-a7a9-5b9bff52fa08, tx=GridNearTxLocal
[mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
[entries=LinkedHashSet [IgniteTxEntry [txKey=IgniteTxKey
[key=KeyCacheObjectImpl [part=833, val=833, hasValBytes=true],
cacheId=-923393186], val=TxEntryValueHolder [val=CacheObjectByteArrayImpl
[arrLen=1048576], op=CREATE], prevVal=TxEntryValueHolder [val=null, op=NOOP],
oldVal=TxEntryValueHolder [val=null, op=NOOP], entryProcessorsCol=null, ttl=-1,
conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null,
filters=CacheEntryPredicate[] [], filtersPassed=false, filtersSet=true,
entry=GridDhtDetachedCacheEntry [super=GridDistributedCacheEntry
[super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=833, val=833,
hasValBytes=true], val=null, ver=GridCacheVersion [topVer=0, order=0,
nodeOrder=0], hash=833, extras=null, flags=0]]], prepared=0, locked=false,
nodeId=07583a9d-36c8-4100-a69c-8cbd26ca82c9, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
xidVer=GridCacheVersion [topVer=215865159, order=1604385188157, nodeOrder=2]]],
explicitLock=false, queryUpdate=false,
[jira] [Created] (IGNITE-14054) Improve discovery ducktest: add partial network drop.
Vladimir Steshin created IGNITE-14054: - Summary: Improve discovery ducktest: add partial network drop. Key: IGNITE-14054 URL: https://issues.apache.org/jira/browse/IGNITE-14054 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)
Hi Denis, Thanks a lot! I'll update my PR's accordingly. Regards, Nikita сб, 23 янв. 2021 г. в 00:59, Denis Magda : > Nikita, thanks. I reviewed those and shared some suggestions. Please take > them into consideration. > > - > Denis > > > On Fri, Jan 22, 2021 at 1:45 PM Никита Сафонов > wrote: > > > Hi everyone, > > > > The following documentation tasks for the important features now have > PATCH > > AVAILABLE status: > > > >- Caches warming up strategy - > >https://issues.apache.org/jira/browse/IGNITE-13385?src=confmacro > >- Update on JMX default configuration removal - > >https://issues.apache.org/jira/browse/IGNITE-13606?src=confmacro > >- Control.sh indexes manipulation commands - > >https://issues.apache.org/jira/browse/IGNITE-13285?src=confmacro > > > > Please see the PR's attached to the tickets. > > > > Thank you! > > > > Regards, > > Nikita > > > > пт, 22 янв. 2021 г. в 18:03, shm : > > > > > Hi All, > > > Can you please also include a critical ticket > > > https://issues.apache.org/jira/browse/IGNITE-13912 > > > to 2.10 In terms of functionality it is a blocker. Still some > debugging > > is > > > going on related to this issue. > > > > > > Thanks, > > > Shiva > > > > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >
[jira] [Created] (IGNITE-14053) Remove status check message at all.
Vladimir Steshin created IGNITE-14053: - Summary: Remove status check message at all. Key: IGNITE-14053 URL: https://issues.apache.org/jira/browse/IGNITE-14053 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14052) [Ducktape: Thin client] Executing Compute Tasks Test
Evgeniya Vdovets created IGNITE-14052: - Summary: [Ducktape: Thin client] Executing Compute Tasks Test Key: IGNITE-14052 URL: https://issues.apache.org/jira/browse/IGNITE-14052 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Assignee: Evgeniya Vdovets Need to check Executing Compute Tasks API works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14051) [Ducktape: Thin client] Executing SQL Statements Test
Evgeniya Vdovets created IGNITE-14051: - Summary: [Ducktape: Thin client] Executing SQL Statements Test Key: IGNITE-14051 URL: https://issues.apache.org/jira/browse/IGNITE-14051 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Assignee: Evgeniya Vdovets Need to check Executing SQL Statements API works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14050) [Ducktape: Thin client] Working with Binary Objects Test
Evgeniya Vdovets created IGNITE-14050: - Summary: [Ducktape: Thin client] Working with Binary Objects Test Key: IGNITE-14050 URL: https://issues.apache.org/jira/browse/IGNITE-14050 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Need to check Binary Objects API works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14049) [Ducktape: Thin client] Transactions Test
Evgeniya Vdovets created IGNITE-14049: - Summary: [Ducktape: Thin client] Transactions Test Key: IGNITE-14049 URL: https://issues.apache.org/jira/browse/IGNITE-14049 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Assignee: Evgeniya Vdovets Need to check transactions api works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14048) [Ducktape: Thin client] Executing Scan Queries
Evgeniya Vdovets created IGNITE-14048: - Summary: [Ducktape: Thin client] Executing Scan Queries Key: IGNITE-14048 URL: https://issues.apache.org/jira/browse/IGNITE-14048 Project: Ignite Issue Type: Sub-task Reporter: Evgeniya Vdovets Assignee: Evgeniya Vdovets Need to check Executing Scan Queries api works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Re[2]: [DISCUSS] Page replacement improvement
Mirza, sure. Will wait for your review. пн, 25 янв. 2021 г. в 11:06, Mirza Aliev : > Hello, Alexey! > > Thank you for your effort, the feature looks great! > > Could you please give a bit more time to review it? > > Best regards, > Mirza Aliev > > пт, 22 янв. 2021 г. в 10:19, Alex Plehanov : > > > Hello, Igniters! > > > > Zhenya has already approved the patch that adds segmented-LRU and CLOCK > > page replacement modes [1] (thanks for the review!). Would anyone else > like > > to review it? > > I have plans to merge it next Monday if nobody else will be interested in > > reviewing it. > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-13761 > > > > пт, 25 дек. 2020 г. в 12:26, Alex Plehanov : > > > > > Guys, > > > > > > I've implemented Segmented-LRU page replacement algorithm and > benchmarked > > > results, it gives some boost (5-10%) when page replacement is > > > heavily used, but, unfortunately, when replacement is not used it gives > > > about 2% drop compared to the current Random-LRU page replacement > > > implementation. Due to this, I think Segmented-LRU can't be used as the > > > only option or option by default. > > > > > > Also, I've implemented CLOCK page replacement algorithm (basic, > > > not scan-resistant version) and benchmark results are much better. It > > gives > > > about the same performance as Segmented-LRU when page replacement is > used > > > and about the same performance as Random-LRU where there is no page > > > replacement. There are advanced modifications of CLOCK algorithm > exists, > > > but usually, they require additional maintenance cost and we can again > > get > > > drop on environments without page replacements compared to Random-LRU. > > I've > > > written a benchmark with background full cache scans and even in this > > case > > > basic CLOCK version looks promising. > > > > > > So, my proposals: > > > 1. Include all 3 implementations (Random-LRU, Segmented-LRU, CLOCK) to > > the > > > product. > > > 2. Make page replacement algorithm configurable. > > > 3. Recommend to use Random-LRU for environments with no page > replacements > > > (as it has zero maintenance cost). Recommend to use Segmented-LRU for > > > environments with a high page replacement rate and a large amount of > > > one-time scans (as it has near to optimal page to replace selection > > policy > > > and scan-resistant). Recommend to use CLOCK for all other cases (as it > > has > > > near to zero maintenance cost and efficiency of page replacement near > to > > > Segmented-LRU). > > > 4. Set CLOCK as the default page replacement algorithm. > > > > > > WDYT? > > > > > > I've filled the IEP [1] for this discussion and create the pull request > > > [2] for the last proposal. I would appreciate for review of the patch. > > > > > > [1]: > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-62+Page+replacement+improvements > > > [2]: https://github.com/apache/ignite/pull/8513 > > > > > > пн, 23 нояб. 2020 г. в 11:12, Zhenya Stanilovsky > > > : > > > > > >> > > >> > > >> Nikolay, i hope such case ignite users already observed) > > >> I suggest to: put data bigger then available, full scan, get data only > > >> for available inmem data in loop, check PageReplacement metric, how > > match > > >> iterations will bring to zero this metric. > > >> > > >> >Hello, Alex. > > >> > > > >> >> Perhaps we can implement a special benchmark for this case with > > >> manually triggered "batch page replacement" using yardstick (but I'm > not > > >> sure if ducktape can help here). > > >> > > > >> >I think we should carefully describe the issues with the current > > >> approach and then we can choose right tool to benchmark improvements. > > >> >You said: > > >> > > > >> >> we use Random-LRU algorithm … it has many disadvantages and affects > > >> performance very much when replacement is started > > >> > > > >> >Can you list disadvantages of the Random-LRU? > > >> > > > >> >AFAIU the first benchmark should be: > > >> > > > >> >1. Start cluster with persistence and put data bigger then available > > RAM > > >> to it. > > >> >2. Measure performance of the queries that selects one entry from the > > >> cache. > > >> >3. Make some queries that will iterate throw all data - `SELECT > SUM(x) > > >> FROM t` or something similar. > > >> >4. Repeat step 2. in this time performance of random queries should > be > > >> lower due to the page replacement. > > >> > > > >> >Is this scenario correct? > > >> > > > >> >> 23 нояб. 2020 г., в 09:12, Alex Plehanov < plehanov.a...@gmail.com > > > > >> написал(а): > > >> >> > > >> >> Nikolay, Zhenya, > > >> >> > > >> >> Benchmark from IGNITE-13034 is fully synthetic, it makes random > puts > > >> >> uniformly. It can be used to compare different page replacement > > >> algorithms > > >> >> (random-LRU vs segmented-LRU), but it is totally inapplicable to > > >> benchmark > > >> >> batch page replacement. > > >> >> Perhaps we can implement a special benchmark for this case
Re: Access to Ignite Extensions TeamCity project
Hi, Petr. Now I have access. Thanks! пн, 25 янв. 2021 г. в 11:28, Petr Ivanov : > Hi, Sergey. > > > Check you permissions, please. > > > On 24 Jan 2021, at 21:00, Sergey D wrote: > > > > Hi Igniters, > > > > I want to start work on a ticket in ignite extension project, but it > seems > > that i don`t have permission to this project in TeamCity. > > "You do not have enough permissions to access project with id > > IgniteExtensions_Tests" > > > > My username is stalkxt . > > > > Can you help me please? > > > > -- > > *Best regards, Sergey.* > > -- *Best regards, Sergey.*
[jira] [Created] (IGNITE-14047) .NET: Release build fails because of missing nuget executable
Pavel Tupitsyn created IGNITE-14047:
---
Summary: .NET: Release build fails because of missing nuget
executable
Key: IGNITE-14047
URL: https://issues.apache.org/jira/browse/IGNITE-14047
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
NuGet executable is not downloaded when {{-skipNuGet}} is specified, but it is
required for .NET Framework build.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Access to Ignite Extensions TeamCity project
Hi, Sergey. Check you permissions, please. > On 24 Jan 2021, at 21:00, Sergey D wrote: > > Hi Igniters, > > I want to start work on a ticket in ignite extension project, but it seems > that i don`t have permission to this project in TeamCity. > "You do not have enough permissions to access project with id > IgniteExtensions_Tests" > > My username is stalkxt . > > Can you help me please? > > -- > *Best regards, Sergey.*
Re: Re[2]: [DISCUSS] Page replacement improvement
Hello, Alexey! Thank you for your effort, the feature looks great! Could you please give a bit more time to review it? Best regards, Mirza Aliev пт, 22 янв. 2021 г. в 10:19, Alex Plehanov : > Hello, Igniters! > > Zhenya has already approved the patch that adds segmented-LRU and CLOCK > page replacement modes [1] (thanks for the review!). Would anyone else like > to review it? > I have plans to merge it next Monday if nobody else will be interested in > reviewing it. > > [1]: https://issues.apache.org/jira/browse/IGNITE-13761 > > пт, 25 дек. 2020 г. в 12:26, Alex Plehanov : > > > Guys, > > > > I've implemented Segmented-LRU page replacement algorithm and benchmarked > > results, it gives some boost (5-10%) when page replacement is > > heavily used, but, unfortunately, when replacement is not used it gives > > about 2% drop compared to the current Random-LRU page replacement > > implementation. Due to this, I think Segmented-LRU can't be used as the > > only option or option by default. > > > > Also, I've implemented CLOCK page replacement algorithm (basic, > > not scan-resistant version) and benchmark results are much better. It > gives > > about the same performance as Segmented-LRU when page replacement is used > > and about the same performance as Random-LRU where there is no page > > replacement. There are advanced modifications of CLOCK algorithm exists, > > but usually, they require additional maintenance cost and we can again > get > > drop on environments without page replacements compared to Random-LRU. > I've > > written a benchmark with background full cache scans and even in this > case > > basic CLOCK version looks promising. > > > > So, my proposals: > > 1. Include all 3 implementations (Random-LRU, Segmented-LRU, CLOCK) to > the > > product. > > 2. Make page replacement algorithm configurable. > > 3. Recommend to use Random-LRU for environments with no page replacements > > (as it has zero maintenance cost). Recommend to use Segmented-LRU for > > environments with a high page replacement rate and a large amount of > > one-time scans (as it has near to optimal page to replace selection > policy > > and scan-resistant). Recommend to use CLOCK for all other cases (as it > has > > near to zero maintenance cost and efficiency of page replacement near to > > Segmented-LRU). > > 4. Set CLOCK as the default page replacement algorithm. > > > > WDYT? > > > > I've filled the IEP [1] for this discussion and create the pull request > > [2] for the last proposal. I would appreciate for review of the patch. > > > > [1]: > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-62+Page+replacement+improvements > > [2]: https://github.com/apache/ignite/pull/8513 > > > > пн, 23 нояб. 2020 г. в 11:12, Zhenya Stanilovsky > > : > > > >> > >> > >> Nikolay, i hope such case ignite users already observed) > >> I suggest to: put data bigger then available, full scan, get data only > >> for available inmem data in loop, check PageReplacement metric, how > match > >> iterations will bring to zero this metric. > >> > >> >Hello, Alex. > >> > > >> >> Perhaps we can implement a special benchmark for this case with > >> manually triggered "batch page replacement" using yardstick (but I'm not > >> sure if ducktape can help here). > >> > > >> >I think we should carefully describe the issues with the current > >> approach and then we can choose right tool to benchmark improvements. > >> >You said: > >> > > >> >> we use Random-LRU algorithm … it has many disadvantages and affects > >> performance very much when replacement is started > >> > > >> >Can you list disadvantages of the Random-LRU? > >> > > >> >AFAIU the first benchmark should be: > >> > > >> >1. Start cluster with persistence and put data bigger then available > RAM > >> to it. > >> >2. Measure performance of the queries that selects one entry from the > >> cache. > >> >3. Make some queries that will iterate throw all data - `SELECT SUM(x) > >> FROM t` or something similar. > >> >4. Repeat step 2. in this time performance of random queries should be > >> lower due to the page replacement. > >> > > >> >Is this scenario correct? > >> > > >> >> 23 нояб. 2020 г., в 09:12, Alex Plehanov < plehanov.a...@gmail.com > > >> написал(а): > >> >> > >> >> Nikolay, Zhenya, > >> >> > >> >> Benchmark from IGNITE-13034 is fully synthetic, it makes random puts > >> >> uniformly. It can be used to compare different page replacement > >> algorithms > >> >> (random-LRU vs segmented-LRU), but it is totally inapplicable to > >> benchmark > >> >> batch page replacement. > >> >> Perhaps we can implement a special benchmark for this case with > >> manually > >> >> triggered "batch page replacement" using yardstick (but I'm not sure > >> >> if ducktape can help here). > >> >> > >> >>> I understand case you described, but who will pull the switch ? > Human, > >> >> artificial intelligence ? > >> >> As I described before, we can implement both manual and automatic > >> "batch > >> >>
[jira] [Created] (IGNITE-14046) Update ducktape version to 0.8.2 in ignite-ducktape module
Ivan Daschinskiy created IGNITE-14046: - Summary: Update ducktape version to 0.8.2 in ignite-ducktape module Key: IGNITE-14046 URL: https://issues.apache.org/jira/browse/IGNITE-14046 Project: Ignite Issue Type: Task Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
