Igniters,
During the meetup dedicated to Ignite 3.0 [1], one of the items I've
mentioned was JAR based code deployment, as an alternative to peer class
loading and other mechanisms for code deployment.
As promised, I've started drafting the IEP for this change [2]. Please let
me know your
Pavel, thanks for preparing the list of the missing pages. Do you want me
to port those pages or are you going to do it yourself?
Btw, what's wrong with the 3rd-party integrations? Are you saying the .NET
community no longer uses those?
-
Denis
On Fri, Sep 18, 2020 at 5:45 AM Pavel Tupitsyn
Igor Sapego created IGNITE-13484:
Summary: C++ odbc-example losing some values if run with 1
additional node
Key: IGNITE-13484
URL: https://issues.apache.org/jira/browse/IGNITE-13484
Project: Ignite
Let's try to simplify the project's messaging - not introduce new
sub-component naming or synthetic shelving to it :-)
--
Nikita Ivanov
On Thu, Sep 24, 2020 at 12:01 PM Denis Magda wrote:
> If "Apache Ignite" remains then another option is to keep defining Ignite
> as an in-memory computing
@Alex Plehanov
Are you interested in writing a blog post that covers the major
improvements of the 2.9 release? It will be referenced from the
announcement email and distributed through other channels. Examples of
previous articles: https://blogs.apache.org/ignite/
It happened that I was the
Good Afternoon Denis,
We came across ignite in very similar ways to everyone else. We had our
existing application that we were looking to ramp up and scale inside
Kubernetes. It is an internal ML Platform that was developed largely as a
monolithic application, we wanted work on it to be more
Denis A. Magda created IGNITE-13483:
---
Summary: New Docs: navigation menu folds and browser cache issues
Key: IGNITE-13483
URL: https://issues.apache.org/jira/browse/IGNITE-13483
Project: Ignite
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
Adam,
Like your way of thinking. It makes sense to me.
For me, a computing platform comprises two essential components - a storage
engine and compute APIs (not only compute grid, but also streaming, SQL,
etc.). Under this definition, Ignite fits the "compute platform" category
for sure, but the
"Apache Ignite" will remain the same... We are just going to refer to it as
"IgniteDB" everywhere where it doesn't technically conflict with "Apache
Ignite". We are also not changing the package structure (i.e. the packaging
will remain 'org.apache.ignite.xxx').
Or... we can go and rename the
Nikita, Cos,
Agree, IgniteDB would be a much better option if the project would be
launched these days with the current set of capabilities. But, as of now,
the renaming won't be a benign move, it can do more bad than good. "Apache
Ignite" is already a brand and even a trademark, the organic
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
Юрий, can you take a look?
JIRA - https://issues.apache.org/jira/browse/IGNITE-13450
PR - https://github.com/apache/ignite/pull/8252
вт, 15 сент. 2020 г. в 08:59, Dmitrii Ryabov :
>
> Ok, I created a ticket [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13450
>
> пн, 14 сент. 2020 г. в
Why does the control.sh use JVM_OPTS in the first place? Is there a case
when a user might need to modify them? I can't think of one.
-Val
On Thu, Sep 24, 2020 at 6:42 AM Evgenii Zhuravlev
wrote:
> Ilya,
>
> You can get absolutely the same behaviour when you set JVM_OPTS even
> without Docker.
Ilya,
You can get absolutely the same behaviour when you set JVM_OPTS even
without Docker.
Evgenii
чт, 24 сент. 2020 г. в 05:44, Ilya Kasnacheev :
> Hello!
>
> If the issue is with docker only, then maybe we should get rid of JVM_OPTS
> with docker entirely? E.g. pass them as parameters.
>
>
Hello!
If the issue is with docker only, then maybe we should get rid of JVM_OPTS
with docker entirely? E.g. pass them as parameters.
I'm not sold on this change yet, it breaks backward compatibility for
marginal benefit.
Regards,
--
Ilya Kasnacheev
чт, 24 сент. 2020 г. в 15:35, Данилов
Hello, Igniters!
I recently discovered, that control.sh and ignite.sh both use JVM_OPTS
environment variable. This can lead to various issues (especially in docker),
such as:
* Control utility will have the same xms/xmx parameters.
* Control utility won't launch due to JMX port being in use
Igniters,
I'e prepared an IEP [1], please review and let me know what you think.
In particular, I'd like to discuss the new subsystem to collect statistics
to optimize sql queries execution.
[1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-58+Statistics
Ilya Kasnacheev created IGNITE-13482:
Summary: Client node cannot ALTER TABLE if it was created on a
different node
Key: IGNITE-13482
URL: https://issues.apache.org/jira/browse/IGNITE-13482
Ivan Daschinskiy created IGNITE-13481:
-
Summary: Decorators @version_if and @ignite_versions injects
incorrect variables.
Key: IGNITE-13481
URL: https://issues.apache.org/jira/browse/IGNITE-13481
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
If your changes can lead to this failure(s): We're grateful that you were a
volunteer to make the contribution to this project, but things change and you
may no longer be able to
Igniters,
The PR is ready for review
https://github.com/apache/ignite/pull/8174
On Tue, Sep 22, 2020 at 11:51 AM Pavel Tupitsyn
wrote:
> Yes, this makes a lot of sense (and can be applied to Services, too).
>
> I've filed the ticket: https://issues.apache.org/jira/browse/IGNITE-13471
> This
22 matches
Mail list logo
