Hello, Yaroslav.
Looks like we have fixVersion 2.9.1 in Jira.
Let’s mark all tickets with label «2.9.1-rc1» with fixVersion=2.9.1 and use
fixVersion instead of label further.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.9.1
> 2 нояб. 2020 г., в
Igniters,
I tried to build the docs today using the instructions from README.adoc [1]
Bare Jekyll:
/usr/lib/ruby/vendor_ruby/rouge.rb:55:in `block in ':
asciidoctor: FAILED:
/home/pavel/w/ignite/docs/_docs/SQL/JDBC/error-codes.adoc: Failed to load
AsciiDoc document - uninitialized constant
+1 on having a separate repo. Make the work cleaner and more effective.
--
Nikita Ivanov
On Mon, Nov 2, 2020 at 11:09 PM Nikolay Izhikov wrote:
> Igniters, should we have a call for this topic?
>
> > 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn
> написал(а):
> >
> >> not intend to rewrite
Igniters, should we have a call for this topic?
> 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn написал(а):
>
>> not intend to rewrite everything from scratch
>
>> Every single test from Ignite 2.x should be moved to Ignite 3
>> regardless of how we choose to proceed.
>
> Alexey, thank you for the
Dipak jadhav created IGNITE-13656:
-
Summary: Getting Caused by: class
org.apache.ignite.binary.BinaryInvalidTypeException: in ignite 2.9.0
Key: IGNITE-13656
URL: https://issues.apache.org/jira/browse/IGNITE-13656
Alexey,
Just to clarify before we start the discussion:
this proposal seems to introduce some breaking changes, so we are talking
about Ignite 3.0, correct?
Pavel
On Tue, Nov 3, 2020 at 12:13 AM Alexey Kukushkin
wrote:
> Igniters,
>
> What do you think about changing .NET API to read/write
Igniters,
What do you think about changing .NET API to read/write portable dates by
default and making that really portable?
*The Problem*
Presently .NET API writes dates as composite Ignite objects. Only .NET
clients can read such dates: any other client (JDBC, Java, etc) does not
understand it
Hi!
I've updated PR: https://github.com/apache/ignite/pull/8367. Anton, Ivan,
Ivan could you please review it?
Some moments to mention:
1. I've added new suites: SerializerSuite (ignite-cassandra-serializers),
DistanceTestSuite, NaiveBayesTestSuite (ignite-ml). Should we configure a
TeamCity to
Alexander Korenshteyn created IGNITE-13655:
--
Summary: Implement readiness probe REST endpoint
Key: IGNITE-13655
URL: https://issues.apache.org/jira/browse/IGNITE-13655
Project: Ignite
Thanks for the clarification.
There was no intention to remove the customizable key to partition mapping.
Difficulties arise when mapping partitions to nodes, so it's desirable to
have internally tested implementation with a way to customize it's behavior
without additional coding on the user
Just to be clear, the affinity functions we are using convert keys to
partitions, we do not map partitions to nodes and leave that to Ignite.
On Tue, Nov 3, 2020 at 8:48 AM Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:
> Hello.
>
> Custom affinity functions can cause weird bugs and
Hello.
Custom affinity functions can cause weird bugs and data loss if implemented
wrongly.
There is an intention to keep a backup filter based on user attributes
(with additional validation logic to ensure correctness) for controllable
data placement.
Can you describe more precisely why you
We also use custom affinity functions (vis the C# client).
The wish list mentions use of a particular annotation
(@CentralizedAffinityFunction):
Is the wish to remove just this annotation, or the ability to define custom
affinity functions at all?
In our case we use affinity functions to ensure
Ilya, yes, there is an option TcpDiscoverySpi#soLinger. The main question
is why the default value is true, 5 instead of false,0
пн, 2 нояб. 2020 г., 20:14 Ilya Kasnacheev :
> Hello!
>
> Is there any option to re-enable linger on SSL sockets?
>
> Telling people to re-configure does not help if
Maxim Muzafarov created IGNITE-13654:
Summary: Add snapshot commands to REST API
Key: IGNITE-13654
URL: https://issues.apache.org/jira/browse/IGNITE-13654
Project: Ignite
Issue Type:
Hello!
Is there any option to re-enable linger on SSL sockets?
Telling people to re-configure does not help if they can't.
Regards,
--
Ilya Kasnacheev
пт, 30 окт. 2020 г. в 15:21, Anton Vinogradov :
> > When TLS 1.3 is introduced, whole sun.security.ssl.SSLSocketImpl was
> > rewritten.
>
Guys,
should you agree that issues with the 2.9.1-rc tag are good enough
for a maintenance release, i'd like to give it a go.
On Thu, Oct 29, 2020 at 5:33 PM Alexey Zinoviev
wrote:
> Let's discuss the possible planning dates for feature freeze for 2.10, for
> example? Do you have any plans or
I saw at
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist
that custom affinity functions are on the potential wishlist for removal.
The way we're using it's very critical that we be able to control the
placement of data quite precisely - as part of that we specify
> not intend to rewrite everything from scratch
> Every single test from Ignite 2.x should be moved to Ignite 3
> regardless of how we choose to proceed.
Alexey, thank you for the explanation, this addresses all of my concerns.
On Mon, Nov 2, 2020 at 6:43 PM Andrey Mashenkov
wrote:
> Hi,
Hi, Igniters.
* AFAIU, we need a new repo if we want to apply different restrictions to
pull requests,
otherwise I see no difference for myself.
E.g. make static analysis (do we have?), compile, styles, and javadoc
checks mandatory.
I think that relaxed requirements here will lead to bad product
Hello!
In my opinion, what you are actually proposing is writing a new
IMDG/distributed database.
I'm not sure why one would assume that this new product will be
particularly successful with users. We have some very good developers out
there now, but some of the people who actually wrote Ignite
Nikolay, Pavel,
Thanks for the feedback! First of all, I wanted to stress that I do not
intend to rewrite everything from scratch (I never used this phrase). There
are significant parts of code that would be moved with minimal
modifications. Second, I never said that we will get rid of the old
Hello!
Okay, that's not very cool. I hope to get some response from development
side at this point.
Sans reaction, I will file a ticket.
Regards,
--
Ilya Kasnacheev
пн, 2 нояб. 2020 г. в 15:03, ssansoy :
> Apologies I may have spoken to soon (I was looking at the wrong process).
>
> It
1. Rewriting from scratch is never a good idea.
We don't want to follow the path of Netscape and lose all our users
by the time we have a working 3.0 [1]
2. Not sure about new repo - seems like some pain and no gain, what's the
problem with a branch?
3. We should keep existing integration tests
Aleksey Plekhanov created IGNITE-13653:
--
Summary: Don't print warning if unordered map used for bulk update
operation on atomic cache
Key: IGNITE-13653
URL: https://issues.apache.org/jira/browse/IGNITE-13653
Hello, Alexey.
I think that «rewriting from scratch» approach has a high risk to make new
features unusable.
At the time Ignite2 was started no-one wants to do bad UX or bad features.
Nevertheless, it happen.
I think we can avoid it with the Ignite3 and successors if we will move step by
step
Alexey,
Do we have any estimates of how fast we'll be able to gain production-ready
AI 3.0 in case of a "new repo" choice?
On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk
wrote:
> Nikolay,
>
> What new features are we planning to implement for Ignite 2.x? I think once
> we commence working on
Nikolay,
What new features are we planning to implement for Ignite 2.x? I think once
we commence working on Ignite 3.0, we should gradually cease the activity
on Ignite 2.x to mere bugfixes because such parallel development will be
overwhelming regardless of how we choose to proceed.
пн, 2 нояб.
To be clear:
> I would suggest creating a new repository for Ignite 3.0 (perhaps, a new
> clean branch, but a new repo looks nicer to me) and a new Ignite 3.0 TeamCity
> project.
+1 for new Team City project.
+1 for new branch for Ignite3.
-1 for new repo.
> 2 нояб. 2020 г., в 13:35,
Hello, Alexey.
I think it will hurt our project more than help.
Developing new features for 2 separate branches with the different APIs and
internal structure is overwhelming
Maybe we should relax a bit requirements for Ignite3?
Maybe we should move step by step and make Ignite3 with new
Igniters,
I wanted to pitch a rather radical idea regarding the Ignite 3.0
development which has occurred to me some time ago.
We already have several IEPs targeted to Ignite 3.0 which imply major
changes to the codebase (the change in replication protocol and thus
transactions, change in binary
Denis Garus created IGNITE-13652:
Summary: Wrong GitHub link for Apache Ignite With Spring
Data/Example
Key: IGNITE-13652
URL: https://issues.apache.org/jira/browse/IGNITE-13652
Project: Ignite
> As I understand we
> can't just move suites between modules, as TeamCity may depend on the path
> to them.
See no problem to update TC as well.
On Fri, Oct 30, 2020 at 4:32 PM Ivan Daschinsky wrote:
> I suggests to mark these tests with @Ignore and file tickets to fix them.
>
> пт, 30 окт.
YuJue Li created IGNITE-13651:
-
Summary: Ignite Docs: Port Apache Zeppelin docs from readme.io
Key: IGNITE-13651
URL: https://issues.apache.org/jira/browse/IGNITE-13651
Project: Ignite
Issue
34 matches
Mail list logo
