CompactFooter for ClientBinaryMarshaller
Igniters, After putting some data with a user-defined key with a thick client, it's impossible to retrieve it with a thin client.https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was a bug, so I first reported the issue to the user ml, Mikhail thanks for checking and the jira issue) That happens because for Ignite `compactFooter` is `true` by default, but `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is not created explicitly (see ClientBinaryMarshaller#createImpl). Any reason to force it to false? I would like to align it with Ignite defaults (by setting to true). -- Roman
[jira] [Created] (IGNITE-10961) Web console: add more countries
Ilya Borisov created IGNITE-10961: - Summary: Web console: add more countries Key: IGNITE-10961 URL: https://issues.apache.org/jira/browse/IGNITE-10961 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Countries to add: * Taiwan * Hong Kong * Singapore -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: How to update Documentation 2.8 docs? - IGNITE-8532 [ML] GA Grid - Implement Roulette Wheel Selection
Dmitriy, Thanks. I will update ML documentation when it is available for my. ticket: https://issues.apache.org/jira/browse/IGNITE-8532 Thanks. Turik -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-10960) Thin client cannot retrieve data that was inserted with the Thick Ignite client when using a composite key
Mikhail Cherkasov created IGNITE-10960:
--
Summary: Thin client cannot retrieve data that was inserted with
the Thick Ignite client when using a composite key
Key: IGNITE-10960
URL: https://issues.apache.org/jira/browse/IGNITE-10960
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Mikhail Cherkasov
Attachments: ThinClientGets.java
Thin client cannot retrieve data that was inserted with the Thick Ignite client
when using a composite key.
See the attached reproducer:
ThinClientGets.java
thickCache.put(new TestKey("a", "0"), 1);
thickCache.get(new TestKey("a", "0")); // returns 1
thinCache.get(new TestKey("a", "0")) // returns null
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10959) Memory leaks in continuous query handlers
Denis Mekhanikov created IGNITE-10959: - Summary: Memory leaks in continuous query handlers Key: IGNITE-10959 URL: https://issues.apache.org/jira/browse/IGNITE-10959 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Denis Mekhanikov Assignee: Denis Mekhanikov Fix For: 2.8 Attachments: CacheContinuousQueryMemoryUsageTest.java Continuous query handlers don't clear internal data structures after cache events are processed. A test, that reproduces the problem, is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: SQL views for IO statistics
Wouldn't disk_read and memory_read be better naming? - Denis On Wed, Jan 16, 2019 at 7:38 AM Юрий wrote: > Denis, > > Physical reads is load page from storage to memory. > Logical reads is read page which already in memory. > > We gather IO statistics on CACHE_GROUP level due to Ignite use one page to > keep all caches related to one cache group. Unfortunately gathering on > table level will be expensive due to the reason. That's way name of view > contains words cache and groups. > > ср, 16 янв. 2019 г. в 17:52, Denis Magda : > > > Yury, > > > > How do we differentiate between logical and physical reads? > > > > Also, it looks counter-intuitive when "CACHE" is used in the name of the > > views for SQL table related statistics. It's still hard to explain the > user > > the relations between caches and tables. Hopefully, this will be fixed in > > 3.0 with renaming but as for the statistics can we use anything neutral > for > > the view names? > > > > - > > Denis > > > > > > On Tue, Jan 15, 2019 at 5:57 AM Юрий > wrote: > > > > > Hi Igniters! > > > > > > As part of IEP-27 > > > < > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-27%3A+Page+IO+statistics > > > > > > > we > > > already gathering IO statistics and expose it through JMX. > > > > > > User who use only SQL should have access to the statistics also. So > > let's > > > discuss about how such SQL view should looks. > > > > > > My proposal it is two SQL views: > > > 1) STATIO_CACHE_GRP > > > > > > cache_grp_name - Name of cache group > > > physical_read - Number of physical read of pages > > > logical_read - Number of logical read of pages > > > > > > > > > The view can be filtered by name, like SELECT * from > > > IGNITE.STATIO_CACHE_GRP where cache_grp_name='cache1' > > > 2) STATIO_IDX > > > > > > cache_grp_name - Name of cache group > > > > > > idx_name - Name of index > > > physical_read - Common number of physical reads of pages > > for > > > the index > > > logical_read - Common number of logical reads of pages > > for > > > the index > > > > > > leaf_logical_read - Number of logical reads of index leaf > pages > > > > > > leaf_physical_read - Number of physical reads of index leaf pages > > > > > > inner_logical_read- Number of logical reads of index inner > pages > > > > > > inner_physical_read - Number of physical reads of index leaf pages > > > > > > > > > The view can be filtered by cache group name or by index name, > like > > > SELECT * from IGNITE.STATIO_IDX where idx_name='cache1_name_idx' > > > > > > We also have time of start gathering statistics, but I'm not sure that > it > > > should be exposed here. > > > > > > > > > WDYT about proposed format for the SQL views? > > > > > > > > > > > > > > > > > > > > > -- > > > Живи с улыбкой! :D > > > > > > > > -- > Живи с улыбкой! :D >
[jira] [Created] (IGNITE-10958) Migrate from Junit 4 to 5
Ivan Fedotov created IGNITE-10958: - Summary: Migrate from Junit 4 to 5 Key: IGNITE-10958 URL: https://issues.apache.org/jira/browse/IGNITE-10958 Project: Ignite Issue Type: Task Reporter: Ivan Fedotov Assignee: Ivan Fedotov Starting with maven-surefire-plugin version 2.22.0 there is full support for JUnit 5 [1]. Migration to the JUnit 5 includes multiple steps: 1. adding new JUnit dependencies to pom files. By artifactId: junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, junit-platform-runner 2. Replace all imports of old JUnit annotations by the newest: from org.junit.Test to org.junit.jupiter.api.Test 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore 4. Replace concept rules by extension model where it is necessary: ExpectedException to assertThrows 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension 6. Update the maven surefire plugin to make it works with JUnit 5. Investigation about migration to JUnit5 was in ticket IGNITE-10180. [1] https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: SQL views for IO statistics
Denis, Physical reads is load page from storage to memory. Logical reads is read page which already in memory. We gather IO statistics on CACHE_GROUP level due to Ignite use one page to keep all caches related to one cache group. Unfortunately gathering on table level will be expensive due to the reason. That's way name of view contains words cache and groups. ср, 16 янв. 2019 г. в 17:52, Denis Magda : > Yury, > > How do we differentiate between logical and physical reads? > > Also, it looks counter-intuitive when "CACHE" is used in the name of the > views for SQL table related statistics. It's still hard to explain the user > the relations between caches and tables. Hopefully, this will be fixed in > 3.0 with renaming but as for the statistics can we use anything neutral for > the view names? > > - > Denis > > > On Tue, Jan 15, 2019 at 5:57 AM Юрий wrote: > > > Hi Igniters! > > > > As part of IEP-27 > > < > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-27%3A+Page+IO+statistics > > > > > we > > already gathering IO statistics and expose it through JMX. > > > > User who use only SQL should have access to the statistics also. So > let's > > discuss about how such SQL view should looks. > > > > My proposal it is two SQL views: > > 1) STATIO_CACHE_GRP > > > > cache_grp_name - Name of cache group > > physical_read - Number of physical read of pages > > logical_read - Number of logical read of pages > > > > > > The view can be filtered by name, like SELECT * from > > IGNITE.STATIO_CACHE_GRP where cache_grp_name='cache1' > > 2) STATIO_IDX > > > > cache_grp_name - Name of cache group > > > > idx_name - Name of index > > physical_read - Common number of physical reads of pages > for > > the index > > logical_read - Common number of logical reads of pages > for > > the index > > > > leaf_logical_read - Number of logical reads of index leaf pages > > > > leaf_physical_read - Number of physical reads of index leaf pages > > > > inner_logical_read- Number of logical reads of index inner pages > > > > inner_physical_read - Number of physical reads of index leaf pages > > > > > > The view can be filtered by cache group name or by index name, like > > SELECT * from IGNITE.STATIO_IDX where idx_name='cache1_name_idx' > > > > We also have time of start gathering statistics, but I'm not sure that it > > should be exposed here. > > > > > > WDYT about proposed format for the SQL views? > > > > > > > > > > > > > > -- > > Живи с улыбкой! :D > > > -- Живи с улыбкой! :D
Re: Suggestion to improve deadlock detection
Hi, According to plan described in corresponding ticket [1] we are going to extend TransactionConfiguration with parameters related to deadlock detection. As you might remember suggested deadlock detection approach is going to be enabled for MVCC caches only. Let's discuss what properties should be introduced. In one of previous emails I wrote about configuration: Now I would like to discuss options for configuring deadlock detection. From a usability standpoint following need to be supported: 1. Turn deadlock detection on/off (on by default). 2. Configure a delay between starting waiting for a lock and sending first deadlock detection message (e.g. 1 second by default). 3. Something else? I can suggest following options: 1. Use a single long for configuration. Values < 0 means disabled deadlock detection. 0 means starting detection without a delay. Values > 0 specifies a delay in milliseconds before starting detection. 2. Use a boolean flag for turning detection on/off. Use a long value for configuring delay. Personally, I like to have separate properties. On the other hand we already have couple of timeout properties in TransactionConfiguration and they follow an approach with single long value. But there can be a difference for deadlock detection. E.g. for "dfltTxTimeout" property value of 0 means that transaction should never time out. And for deadlock detection 0 can mean starting detection without delay. But starting detection instantly might have no sense in practice. Apparently, it seems that we should go with single property. Each property should have a good name. I went through different vendor approaches for configuring deadlock detection: * Postgres has neat "deadlock_timeout" option. * DB2 uses tricky "dlchktime". * SQL Server does not allow to configure any timeout for deadlock detection. It uses some adoptive value instead. * MySQL claims that "InnoDB detects deadlocks immediately" [2]. I credit to simple "deadlockTimeout" here. Each property should have a good default value. As discussed it can be 10 seconds. Also I do not have much experience with adding new configuration parameters for Ignite. Perhaps I am missing some other good practices. Please share your thoughts. [1] https://issues.apache.org/jira/browse/IGNITE-9322 [2] https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_lock_wait_timeout ср, 9 янв. 2019 г. в 09:47, Павлухин Иван : > > Hi, > > In continuation of discussion summarized in [1] I would like to > highlight some points related to avoidance of non-deadlocked > transactions rollback. In [1] maintaining a lock counter for > transaction is suggested in order to avoid rolling back a transaction > which have made progress since a deadlock was detected. One example > when a deadlocked transaction can made a progress is abort by timeout > of another transaction involved in the same deadlock cycle. > > But I suppose that such approach will work for sure only in one case > when a transaction aborted by timeout was direct blocker of a > transaction determined as a victim during deadlock detection. Let's > say we have following deadlock cycle: > Ta -> Tb -> Tc -> Ta > And Ta is determined as a victim. If Tc was aborted by timeout then > most likely Ta has not made any progress and has the same lock counter > and therefore is rolled back. > > So, currently I do not see good enough reason for using lock counter > in order to determine should a victim be aborted or not. Key points > are: > 1. In case of rollbacks by timeout we still can have multiple > transaction aborts. > 2. In case of relaxing 2PL condition we still can have false deadlocks > detected (idea is similar, it works only when direct blocker unlocks > some key, I can bring more details if anyone wants). > > WDYT? > > [1] > https://issues.apache.org/jira/browse/IGNITE-9322?focusedCommentId=16729634=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16729634 > > пн, 24 дек. 2018 г. в 15:55, Павлухин Иван : > > > > Igor, thanks for your feedback! Let's do according to your proposal. > > > > пн, 24 дек. 2018 г. в 14:57, Seliverstov Igor : > > > > > > Ivan, > > > > > > We have to design configuration carefully. > > > There are possible issues with compatibility and this API is public, it > > > might be difficult to redesign it after while. > > > > > > Since there is a ticket about MVCC related configuration parts [1] (TxLog > > > memory region/size, vacuum thread count and intervals, etc) > > > I suggest solving the issue in scope of that ticket. > > > > > > At now, let's introduce a couple of system variables for an ability to > > > change the behavior while development phase. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7966 > > > > > > Regards, > > > Igor > > > > > > чт, 20 дек. 2018 г. в 16:29, Павлухин Иван : > > > > > > > Hi, > > > > > > > > I prepared a patch with deadlock detection algorithm implementation > > > > (you can find
Re: proposed realization KILL QUERY command
Yury, I do support the latter concatenation approach. It's simple and correlates with what other DBs do. Plus, it can be passed to KILL command without complications. Thanks for thinking this through! As for the killing of all queries on a particular node, not sure that's a relevant use case. I would put this off. Usually, you want to stop a specific query (it's slow or resources consuming) and have to know its id, the query runs across multiple nodes and a single KILL command with the id can halt it everywhere. If someone decided to shut all queries on the node, then it sounds like the node is experiencing big troubles and it might be better just to shut it down completely. - Denis On Tue, Jan 15, 2019 at 8:00 AM Юрий wrote: > Denis and other Igniters, do you have any comments for proposed approach? > Which of these ones will be better to use for us - simple numeric or hex > values (shorter id, but with letters)? > > As for me hex values preferable due to it shorter and looks more unique > across a logs > > > > вт, 15 янв. 2019 г. в 18:35, Vladimir Ozerov : > >> Hi, >> >> Concatenation through a letter looks like a good approach to me. As far as >> killing all queries on a specific node, I would put it aside for now - >> this >> looks like a separate command with possibly different parameters. >> >> On Tue, Jan 15, 2019 at 1:30 PM Юрий wrote: >> >> > Thanks Vladimir for your thoughts. >> > >> > Based on it most convenient ways are first and third. >> > But with some modifications: >> > For first variant delimiter should be a letter, e.g. 123X15494, then it >> > could be simple copy by user. >> > For 3rd variant can be used convert both numeric to HEX and use a letter >> > delimiter not included to HEX symbols (ABCDEF), in this case query id >> will >> > be shorter and also can be simple copy by user. e.g. 7BX3C86 ( it the >> same >> > value as used for first variant), instead of convert all value as >> string to >> > base16 due to it will be really long value. >> > >> > Possible realization for the cases: >> > 1) Concatenation node order id with query id with a letter delimiter. >> > >> > query_id = 1234X8753 , where *1234* - node order, *8753* - local node >> query >> > counter. *X* - delimeter >> > >> > 2) Converting both node order id and query id to HEX. >> > >> > query_id = 7BX3C86, value is concat(hex(node),"X",hex(queryID)) >> > >> > For both variants we can use either simple or copmlex KILL QUERY syntax. >> > Simple: >> > >> > KILL QUERY 7BX3C86 - for kill concrete query >> > KILL QUERY 7B - for killing all queries on a node. May be need extra >> > symbols for such queries to avoid fault of user and kill all queries by >> > mistake, like KILL QUERY 7B* >> > >> > Complex: >> > >> > KILL QUERY WHERE queryId=7BX3C86 - for killing concrete query. >> > >> > KILL QUERY WHERE nodeId=37d7afd8-b87d-4aa1-b3d1-c1c03380 - for kill >> > all running queries on a given node. >> > >> > >> > >> > What do you think? >> > >> > >> > вт, 15 янв. 2019 г. в 11:20, Vladimir Ozerov : >> > >> > > Hi Yuriy, >> > > >> > > I think all proposed approaches might work. The question is what is >> the >> > > most convenient from user perspective. Encoded values without special >> > > characters are good because they are easy to copy with mouse >> > (double-click) >> > > or keyboard (Ctrl+Shift+arrow). On the other hand, ability to identify >> > > ID/name of suspicious node from query ID is also a good thing. Several >> > > examples of query ID: >> > > >> > > CockroachDB: 14dacc1f9a781e3d0001 >> > > MongoDB: shardB:79014 >> > > >> > > Also it is important that the same query ID is printed in various log >> > > messages. This will be very useful for debugging purposes, e.g. grep >> over >> > > logs. So ideally query ID should not have any symbols which interfere >> > with >> > > grep syntax. >> > > >> > > >> > > On Mon, Jan 14, 2019 at 3:09 PM Юрий >> > wrote: >> > > >> > > > Hi Igniters, >> > > > >> > > > Earlier we discuss about columns for running queries. Let's >> summarize >> > it >> > > > and continue discussion for not closed questions. >> > > > >> > > > What we had: >> > > > *name of view**: *running_queries >> > > > *columns and meaning*: >> > > >query_id - unique id of query on node >> > > >node_id - initial node of request. >> > > >sql - text of query >> > > >schema_name - name of sql schema >> > > >duration - duration in milliseconds from >> start >> > of >> > > > execution. >> > > > >> > > > All of this columns are clear, except query_id. >> > > > Let's keep in mind that the query_id column of the view coupled with >> > KILL >> > > > QUERY command. >> > > > >> > > > We have the following variants what is query_id: >> > > > 1) It's string, internally with two parts separated by '.'(it can be >> > > other >> > > > separator): numeric node order and numeric query counter
Re: SQL views for IO statistics
Yury, How do we differentiate between logical and physical reads? Also, it looks counter-intuitive when "CACHE" is used in the name of the views for SQL table related statistics. It's still hard to explain the user the relations between caches and tables. Hopefully, this will be fixed in 3.0 with renaming but as for the statistics can we use anything neutral for the view names? - Denis On Tue, Jan 15, 2019 at 5:57 AM Юрий wrote: > Hi Igniters! > > As part of IEP-27 > < > https://cwiki.apache.org/confluence/display/IGNITE/IEP-27%3A+Page+IO+statistics > > > we > already gathering IO statistics and expose it through JMX. > > User who use only SQL should have access to the statistics also. So let's > discuss about how such SQL view should looks. > > My proposal it is two SQL views: > 1) STATIO_CACHE_GRP > > cache_grp_name - Name of cache group > physical_read - Number of physical read of pages > logical_read - Number of logical read of pages > > > The view can be filtered by name, like SELECT * from > IGNITE.STATIO_CACHE_GRP where cache_grp_name='cache1' > 2) STATIO_IDX > > cache_grp_name - Name of cache group > > idx_name - Name of index > physical_read - Common number of physical reads of pages for > the index > logical_read - Common number of logical reads of pages for > the index > > leaf_logical_read - Number of logical reads of index leaf pages > > leaf_physical_read - Number of physical reads of index leaf pages > > inner_logical_read- Number of logical reads of index inner pages > > inner_physical_read - Number of physical reads of index leaf pages > > > The view can be filtered by cache group name or by index name, like > SELECT * from IGNITE.STATIO_IDX where idx_name='cache1_name_idx' > > We also have time of start gathering statistics, but I'm not sure that it > should be exposed here. > > > WDYT about proposed format for the SQL views? > > > > > > > -- > Живи с улыбкой! :D >
[jira] [Created] (IGNITE-10957) Reduce EnsuredMessageHistory heap occupation
Alexei Scherbakov created IGNITE-10957: -- Summary: Reduce EnsuredMessageHistory heap occupation Key: IGNITE-10957 URL: https://issues.apache.org/jira/browse/IGNITE-10957 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Fix For: 2.8 EnsuredMessageHistory can hold up to 512 discovery messages to ensure message delivery on client reconnect and clears lazily. With large topology and a large amount caches/partitions this can take up to several Gbs of heap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10956) MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState
Igor Seliverstov created IGNITE-10956: - Summary: MVCC TX: Move queryEnlisted flag from IgniteTxLocalAdapter to IgniteTxState Key: IGNITE-10956 URL: https://issues.apache.org/jira/browse/IGNITE-10956 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov queryEnlisted flag represents a transaction state (like txState.empty(), in other words shows whether there were some updates on MVCC caches or not). It makes sense to move such flag to IgniteTxState. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10954) MVCC: Umute fixed tests.
Andrew Mashenkov created IGNITE-10954: - Summary: MVCC: Umute fixed tests. Key: IGNITE-10954 URL: https://issues.apache.org/jira/browse/IGNITE-10954 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Check if next tests passes on TC and unmute them, otherwise re-mute with correct ticket. IgnitePdsDataRegionMetricsTest.testUsedCheckpointBuffer TxRollbackAsyncWithPersistenceTest.testSynchronousRollback -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Hello everyone
Hi, Prehistoricpenguin! It would be great if you will be able to finish a solution [1]. But I'm not sure that it's a good ticket to start contributing because of interplatform complexity. Anyway, feel free to contact me in case of working on the task. [1] https://issues.apache.org/jira/browse/IGNITE-8283 On Wed, Jan 16, 2019 at 3:05 PM Igor Sapego wrote: > > Welcome to the community! > > Feel free to mention me in mails and tickets related to C++ to draw > my attention, if you need any advice. > > Best Regards, > Igor > > > On Tue, Jan 15, 2019 at 9:42 PM Denis Magda wrote: > > > Hello, > > > > Welcome to the community! Added you to the contributors' list in JIRA. Feel > > free to take over tickets of your interest. > > > > Just in case, Igor Sapego can help you to pick good starting C++ tasks. > > > > - > > Denis > > > > > > On Tue, Jan 15, 2019 at 12:12 AM 泰然 wrote: > > > > > Hello Ignite Community! > > > > > > > > > This is prehistoricpenguin. I want to contribute to Apache Ignite, I am a > > > senior c++ server engineer, and I also write some Java, Node, and Python, > > > my JIRA username is "prehistoricpenguin". > > > > > > > > > Thanks! > > -- Best Regards, Vyacheslav D.
Re: Hello everyone
Welcome to the community! Feel free to mention me in mails and tickets related to C++ to draw my attention, if you need any advice. Best Regards, Igor On Tue, Jan 15, 2019 at 9:42 PM Denis Magda wrote: > Hello, > > Welcome to the community! Added you to the contributors' list in JIRA. Feel > free to take over tickets of your interest. > > Just in case, Igor Sapego can help you to pick good starting C++ tasks. > > - > Denis > > > On Tue, Jan 15, 2019 at 12:12 AM 泰然 wrote: > > > Hello Ignite Community! > > > > > > This is prehistoricpenguin. I want to contribute to Apache Ignite, I am a > > senior c++ server engineer, and I also write some Java, Node, and Python, > > my JIRA username is "prehistoricpenguin". > > > > > > Thanks! >
Re: Best Effort Affinity for thin clients
Pavel, Yeah, it makes sense, but to me it seems that this approach can lead to more complicated client logic, as it will require to make additional call to every server, that reports affinity topology change. Guys, WDYT? Best Regards, Igor On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn wrote: > Igor, > > > It is proposed to add flag to every response, that shows whether the > Affinity Topology Version of the cluster has changed since the last request > from the client. > I propose to keep this flag. So no need for periodic checks. Makes sense? > > On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego wrote: > > > Pavel, > > > > This will require from client to send this new request periodically, I'm > > not > > sure this will make clients simpler. Anyway, let's discuss it. > > > > Vladimir, > > > > With current proposal, we will have affinity info in message header. > > > > Best Regards, > > Igor > > > > > > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov > > wrote: > > > > > Igor, > > > > > > I think that "Cache Partitions Request" should contain affinity > topology > > > version. Otherwise we do not know what distribution is returned - the > one > > > we expected, or some newer one. The latter may happen in case topology > > > changed or late affinity assignment happened between server response > and > > > subsequent client partitions request. > > > > > > Vladimir. > > > > > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego > wrote: > > > > > > > Hello guys, > > > > > > > > I've updated IEP page [1] describing proposed solution in more > details > > > and > > > > proposing some changes for a protocol. > > > > > > > > Please, take a look and let me know what you think. > > > > > > > > [1] - > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > > > > > > > Best Regards, > > > > Igor > > > > > > > > > > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov < > voze...@gridgain.com > > > > > > > wrote: > > > > > > > > > Denis, > > > > > > > > > > Yes, in principle we can extend it. We are going to implement it in > > > > > subsequent phases of this IEP. > > > > > > > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan < > > > > dsetrak...@apache.org> > > > > > wrote: > > > > > > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda > > > > > wrote: > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > Feel that this functionality can be extended to the automatic > > > > > reconnect, > > > > > > > can't it? Presently we require to provide a static list of IPs > to > > > be > > > > > used > > > > > > > at a reconnect time. By having a partition map of all the > nodes, > > > the > > > > > thin > > > > > > > client should be able to automate this piece. > > > > > > > > > > > > > > > > > > > Not sure if static IP list can be avoided. What Igor is > suggesting > > is > > > > > that > > > > > > we try to pick the best node out of the static IP list. > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > >
Re: Service grid redesign
The wiki's article [1] has been updated according to the merged solution [2]. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584 [2] https://issues.apache.org/jira/browse/IGNITE-9607 On Fri, Dec 28, 2018 at 1:10 PM Vyacheslav Daradur wrote: > > Igniters, > > to have an opportunity to test both new and old service grid > implementations, we added new config-plans on TC: > - Service Grid [1] - runs tests in new (default) mode > - Service Grid (legacy mode) [2] - runs tests in old (legacy) mode > > Both plans contain the following test-suites: > - IgniteServiceGridTestSuite (newly added suite) > - IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic 2") > > Also, the plans have been included in RunAll. > > [1] > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid > [2] > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode > > On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov wrote: > > > > Hello, Igniters. > > > > I've merged Service Grid Redesign - Phase 1 to the master. > > Vyacheslav, great contribution! > > > > Thanks for all Ignite veterans both for the code and design review. > > > > В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет: > > > Hello, Igniters. > > > > > > Please, let us know, if someone want to do additional review of this PR. > > > > > > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет: > > > > Igniters, especially future reviewers, > > > > > > > > Discovery listener registered by 'IgniteServiceProcessor' become > > > > implemented 'HighPriorityListener', seems it's best lock-free > > > > solutions discussed during the review. This change is covered by > > > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should > > > > protect us if the order of listeners will be changed. > > > > > > > > It's about the problem of custom messages which are nullified by PME > > > > [1] and are listened by service deployment to manage the lifecycle of > > > > affinity services. This guarantees that service deployment discovery > > > > listener will be notified earlier than PME's discovery listener and > > > > will be able to capture custom messages which may be nullified in PME > > > > process. > > > > > > > > Looks like we do not have any controversial questions now. > > > > > > > > Thanks! > > > > > > > > [1] > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html > > > > > > > > > > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur > > > > wrote: > > > > > > > > > > Stanislav, thank you for the notes, most of them have been resolved. I > > > > > answered on GitHub. > > > > > > > > > > > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov > > > > > wrote: > > > > > > > > > > > > I’ve done a quick superficial review. Didn’t look at the tests, > > > > > > didn’t dive into the design, etc, just the code. > > > > > > I’ve left some comments – almost all are about minor issues, > > > > > > grammar and code style. > > > > > > > > > > > > Stan > > > > > > > > > > > > From: Vyacheslav Daradur > > > > > > Sent: 21 декабря 2018 г. 14:58 > > > > > > To: dev@ignite.apache.org > > > > > > Subject: Re: Service grid redesign > > > > > > > > > > > > Igniters, > > > > > > > > > > > > Please, let us know if someone is going to do an additional review? > > > > > > > > > > > > We should know can we merge the PR since it has been approved by > > > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for other > > > > > > community members. > > > > > > > > > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur > > > > > > wrote: > > > > > > > > > > > > > > I think I found names which should satisfy me and Denis, and > > > > > > > possibly Nikolay ) > > > > > > > > > > > > > > See the following names (Actual name <- Previously used): > > > > > > > > > > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager > > > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions > > > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId > > > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask > > > > > > > > > > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange > > > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange > > > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange > > > > > > > > > > > > > > - ServiceSingleNodeDeploymentResult <- > > > > > > > ServiceSingleDeploymentsResults > > > > > > > - ServiceSingleNodeDeploymentResultBatch <- > > > > > > > ServicesSingleDeploymentsMessage > > > > > > > > > > > > > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults > > > > > > > - ServiceClusterDeploymentResultBatch <- > > > > > > > ServicesFullDeploymentsMessage > > > > > > > > > > > > > > - ServiceProcessorCommonDiscoveryData <- > > > > > > >
[jira] [Created] (IGNITE-10953) Cassandra examples should not use test classes
Ilya Kasnacheev created IGNITE-10953: Summary: Cassandra examples should not use test classes Key: IGNITE-10953 URL: https://issues.apache.org/jira/browse/IGNITE-10953 Project: Ignite Issue Type: Bug Components: cassandra, documentation Affects Versions: 2.7, 2.0 Reporter: Ilya Kasnacheev https://apacheignite-mix.readme.io/docs/examples "org.apache.ignite.tests.utils" are test classes, not shipped anywhere. Probably copied from tests, but should not be in examples as such examples will not run. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10952) Document SET STREAMING command options
Stanislav Lukyanov created IGNITE-10952: --- Summary: Document SET STREAMING command options Key: IGNITE-10952 URL: https://issues.apache.org/jira/browse/IGNITE-10952 Project: Ignite Issue Type: Task Components: documentation Reporter: Stanislav Lukyanov SET STREAMING command (https://apacheignite-sql.readme.io/docs/set) has a number of supported options related to the underlying data streamer configuration. However, they are not documented. Need to add documentation (BNFs and examples) for all of the options. The list of options can be found in the SqlSetStreamingCommand source code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
