Hi Erlan,
Added you to the contributors role in JIRA.
Welcome to the Apache Ignite community!
Pavel
On Mon, Dec 6, 2021 at 9:36 AM Erlan Aytpaev wrote:
> Hi, Igniters,
>
> My name is Erlan. I'm a seasoned full-stack developer (PHP/JS) with over 10
> years experience.
>
> I'd like to join the
Hi, Taras!
I get critical system failure when I tried to explicitly set inline size
with negative value. WDYT, if we restrict it with only positive numbers for
public API?
Also, I put some minor comments. Can you please have a look?
On Fri, Dec 3, 2021 at 6:09 PM Taras Ledkov wrote:
> Hi Ignit
Hello Nikolay,
>> plugin framework allows to implement internal components and use the
internal API.
> Can you please, point out to documentation or place in Ignite code that
describe this behaviour?
Looks like it states here https://ignite.apache.org/docs/latest/plugins
> The Ignite plugin sys
Let's move all GCC-related parts to ignite-extensions, release, and use
them as a maven dependency.
On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky wrote:
> Ok, TC suite is ready [1].
> If there is no objections, I will merge it soon.
>
> Possible concerns -- now it is required to install build-
Slava, I don’t get it.
> Plugins have access to different internal Ignite components, such as security
> processor and others, and can extend the programmatic API of Ignite.
Where docs say that we, as a community, take responsibility to keep internals
in the way plugin expect?
> 6 дек. 2021 г.
Anton, I disagree.
1. This should be released with main distro.
2. This should not be abandoned.
3. There is not any release process in ignite-extensions.
4. Everything is working now and working good.
So lets do not do this :)
пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov :
> Let's move all GC
+1 with Ivan, let`s store it in core product just because it looks like
inalienable functionality and release cycle of extensions a little bit
different.
>Anton, I disagree.
>
>1. This should be released with main distro.
>2. This should not be abandoned.
>3. There is not any release proces
Hello,
I am working on a requirement wherein I want to use Apache Ignite.
Queries-
1. Whether Ignite Server Node is started in synchronous or asynchronous
mode
2. Sometimes warning org.apache.ignite.logger.java.JavaLogger.warning
Possible too long JVM pause is coming. Not able to
Any reason to release the same cpp sources for each release?
Any reason to increase the requirements amount for each new release?
Any reason to increase release complexity and duration?
All answers are "definitely no"
What we should do is to release cpp part once and use it as a dependency.
Extens
Hi,
> Plugins have access to different internal Ignite components, such as
security processor and others, and can extend the programmatic API of
Ignite.
> Where docs say that we, as a community, take responsibility to keep
internals in the way plugin expect?
Nikolay, it seems to me, that quoted t
That's correct.
Folks, can we agree on how we want to approach the removal of the system
cache? Any objections to the plan I've suggested earlier? As a reminder,
here it is:
1. Write down the differences between the system cache and the metastorage,
and provide a transition guide for plugin develo
Valentin,
> However, changes like system cache removal are much more critical, because a
> plugin might rely on it.
I’m still don’t understand - what is the difference between system cache and
any other Ignite cache except the name?
Do we have some special guarantees for system cache?
> Any o
Val,
The plan should be more precise. So at the very high level:
1. Deprecate the system cache in 2.13.
2. Remove the system cache in 2.14.
2.14 should happen in the mid of the next year I suppose.
I don't think we should write guides for the system cache >
metastorage migration process. This i
Only one reason -- nowadays amost all hardware platforms uses NUMA
Another reason -- there is no any release process of extensions.
BTW, apache ignite release is shipped with odbc binary installer for
windows. And nobody complains about it.
But may be listen to others?
пн, 6 дек. 2021 г., 19:4
Hello!
Maybe I am wrong, but ODBC installer is built from source and may be
improved from release to release.
Regards,
--
Ilya Kasnacheev
пн, 6 дек. 2021 г. в 20:41, Ivan Daschinsky :
> Only one reason -- nowadays amost all hardware platforms uses NUMA
>
> Another reason -- there is no any re
You are not wrong, it is built from source, every night. And every TC run.
I don't understand why numa allocator cannot be treated the same. Moreover,
it is built using maven, with maven plugin and just needs gcc and
libnuma-dev. All of theese are already on TC agents and build are ready. I
didn't
16 matches
Mail list logo
