Ivan, if Petr can`t help here, how can we change it out own ?
May be we need some help from pmc chair or someone else ?
>
>>
>>Igniters. Almost half of a year passed since this thread begun. We
>>released 0.4.0, we adopted travis-ci and use it as primary source for
>>test results but nothing
Igniters. Almost half of a year passed since this thread begun. We
released 0.4.0, we adopted travis-ci and use it as primary source for
test results but nothing changed in TC
1. We use deprecated pytest-runner (even here
(https://pypi.org/project/pytest-runner) you can see deprecation
notice and
Ilya, hi.
+1 from me. We should not worry about weird user actions. Direct calling
of GC looks unusual today. Suggestion of forced disabling manual
System.gc() looks useless.
14.05.2021 15:06, Ilya Korol пишет:
Hi, everyone.
There is a proposal to remove suggestion that user should disable
Gmail treated this as spam for me. Bump.
2021-05-18 14:39 GMT+03:00, Данилов Семён :
> Hello, Igniters!
>
> I've recently stumbled across an issue where some tests can't be run locally
> due to the absence of some entries in "classnames.properties" file.
> For example, TcpRestUnmarshalVulnerabilit
Hello, Igniters!
I've recently stumbled across an issue where some tests can't be run locally
due to the absence of some entries in "classnames.properties" file.
For example, TcpRestUnmarshalVulnerabilityTest can't be run locally because
"classnames.properties" lacks
org.apache.ignite.configura
Hi Ignites,
I ran into in-consistency data issues on version 2.8.1. I have three nodes run
as a cluster and the cache configuration as:
CacheConfiguration cacheConfiguration = new
CacheConfiguration<>(Balance.class.getSimpleName());
cacheConfiguration.setIndexedTypes(String.clas
Hello.
> BTW, was there any progress with this?
Patch is ready, please, join the review -
https://github.com/apache/ignite/pull/9106
> 10 мая 2021 г., в 09:47, Ivan Pavlukhin написал(а):
>
> +1 for 140 lines compromise.
> +1 if someone is ready to fix everything to fit 120.
>
> BTW, was ther
Pavel,
+1 from me for a stateless approach. We could definitely invent something
here to make a stateful approach working but that would make this feature
too complex and error-prone, IMO. It makes sense to file an improvement
ticket with benchmark results and maybe code draft if we decide to move
Igniters,
I've implemented a "stateful" approach (see IEP) in .NET Thin Client:
client-side flush adds data to server-side streamer, but does not flush it
immediately.
It provides ~35% perf improvement over stateless approach (where every
client request opens a new streamer, adds data, closes stre
