Several points from my side: 1) Java 9 support - Unsafe removal, modules, etc.. 2) Rework our "messages" subsystem - we always read/write all fields, thus transferring lots of zeros without any reason. We should support branching. 3) Review all messages (especially cache, double-especially - atomic) in terms of performance. Most probably we will refactor/split some of them.
14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <yzhda...@apache.org> написал: > Alex, a lot of excitement for Ignite-2.0 from my side! =) > > I agree with your points and I will take a close look at them in the > nearest future. > > Here are some suggestions from me. > > I don't remember if I shared my thoughts on moving to single TCP port per > node. So, I filed a new ticket - > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have > another one let's merge them. > > I would also think over removing communication SPI and discovery SPI and > introducing communication and discovery processors instead. In some places > Ignite pretty much relies on internal implementation details of these SPIs > which makes implementation of any other SPI pretty complex task. Btw, did > anyone did that? Removing SPIs will allow us to cleanup the code and use > common abstractions and logic. > > I will give some more ideas going forward. > > Thanks! > > --Yakov > > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > So, no excitement about Ignite 2.0? :) > > > > I went ahead and created a 2.0 version in Ignite Jira, and included the > > following tickets so far based on the chance that this ticket will > require > > breaking changes in APIs/Configuration > > - IGNITE-3469 - Get rid of deprecated APIs and code > > - IGNTIE-3477 - Rework offheap storage > > - IGNITE-3478 - Transactional SQL > > - IGNITE-1605 - Provide stronger data loss check > > - IGNITE-3306 - Extend IgniteCluster interface with the methods to send > > and receive custom discovery events > > > > I believe that there are many more changes that we wanted to make but > > delayed because they would break binary compatibility, so if you have > > something in mind - it's time to create a ticket or assign it to 2.0 if > it > > exists. It's good to know the scope of work. > > > > Also, it would be great if you review/comment the above-mentioned > tickets. > > > > Thanks, > > AG > > >
