Re: newbie + kubernetes IpFinder
Hi Balazs, I've added you to the list of contributors, so now you can assign the issue. Ignite does not have any strict/detailed conventions about tickets (probably someday we'll create some). Main requirements can be found in https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-TicketsandVersions My vision about tickets - it is just common sense: Summary in the title, and in description: Why this ticket should be done (problem), (optional: ) How this change can be done. Reference points: dev lists discussions, test failures, logs, etc. This particular ticket is quite well described. Sincerely, Dmitriy Pavlov чт, 18 апр. 2019 г. в 10:39, Péterfi, Balázs : > Hi Denis, > > Thanks for your reply. I've created a ticket ( > https://issues.apache.org/jira/browse/IGNITE-11771) for the first part of > my email. Could you please have a look at it to make sure it follows your > conventions? If all good can you please assign to me so I can start working > on it? > > As for the second part of my email: is there any way to control which pods > should form a cluster, or will always all of them join to one big cluster? > > Thanks, > Balazs > > On Wed, 17 Apr 2019 at 19:19, Denis Magda wrote: > > > Hello Balazs, > > > > Thanks for reaching the community out. Certainly, we'll appreciate if you > > contribute your changes back. Could you please create a ticket in JIRA > and > > open the pull-request? Someone from the community will review and accept > > your improvements. > > > > Just in case, you can find more on contribution here: > > https://ignite.apache.org/community/contribute.html#contribute > > > > - > > Denis > > > > > > On Wed, Apr 17, 2019 at 8:03 AM Péterfi, Balázs > > wrote: > > > > > Hi All, > > > > > > First of all I wanted to say hi as I've just joined to the list! > > > > > > Secondly, I'm moving one of my apps to Kubernetes and found > > > the ignite-kubernetes lib for finding the pods for the cluster. After > > > playing with it a bit I found out that it won't work for me, because it > > > only collects the IPs for the pods that are in a ready state. My > problem > > > with that is when my app is starting it warms up the cache which takes > > some > > > time and only when this is done will it have a ready state in k8s. But > at > > > that point all my pods have started a single node cluster and they end > up > > > in a split-brain scenario (not to mention that they all did the cache > > > warm-up which is a waste). In Hazelcast they have a flag to include > > > non-ready pods as well which solves the issue. I have an implementation > > for > > > that and would be happy to add it in the original IpFinder with some > > > configuration to control that behavior, unless someone here tells me > > > otherwise. > > > > > > There is another change I did on the original version which is to > prevent > > > two ReplicaSets of the same app joining to each-other's cluster. This > is > > a > > > must have for me when deploying a new version while leaving the old one > > > running until the warm-up finishes. I couldn't find any configuration > > that > > > prevents this happening so I changed the IpFinder to only look for pods > > > from the same ReplicaSet. I wonder if there is any other solution for > > this > > > issue? > > > > > > Best regards, > > > Balazs > > > > > >
[jira] [Created] (IGNITE-11784) Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Sergey Antonov created IGNITE-11784:
---
Summary: Replace TcpDiscoveryNode to nodeId in TcpDiscoveryMessages
Key: IGNITE-11784
URL: https://issues.apache.org/jira/browse/IGNITE-11784
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Fix For: 2.8
{{TcpDiscoveryDuplicateIdMessage}} and {{TcpDiscoveryStatusCheckMessage}} have
TcpDiscoveryNode filed. TcpDiscoveryNode could be huge object due to node
attributes. We could sent only nodeId and get TcpDiscoveryNode from DiscoCache
on target node.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11783) Open file limit for deb distribution
Alexander Belyak created IGNITE-11783:
-
Summary: Open file limit for deb distribution
Key: IGNITE-11783
URL: https://issues.apache.org/jira/browse/IGNITE-11783
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.7
Environment: ubuntu-16.04
Reporter: Alexander Belyak
Step to reproduce:
1) Install ignite from deb package on ubuntu 16.04
2) Start with persistence
3) Create 5 caches (or one with 4000+ partitions)
Error text:
{noformat}
[18:29:44,369][INFO][exchange-worker-#43][GridCacheDatabaseSharedManager]
Restoring partition state for local groups [cntPartStateWal=0,
lastCheckpointId=bd24ff23-da6f-46e5-bafd-b643db3870d4]
[18:29:51,864][SEVERE][exchange-worker-#43][] Critical system error detected.
Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureH
andler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.StorageException: Failed to initialize
partition file: /usr/s
hare/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_VERTEX_TBL/part-913.bin]]
class org.apache.ignite.internal.processors.cache.persistence.StorageException:
Failed to initialize partition file:
/usr/share/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_
VERTEX_TBL/part-913.bin
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.init(FilePageStore.java:444)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.ensure(FilePageStore.java:650)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.ensure(FilePageStoreManager.java:712)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2472)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2419)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1628)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1302)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1453)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:806)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.nio.file.FileSystemException:
/usr/share/apache-ignite/work/db/node00-f49af718-48da-4186-b664-62aca736bdc9/cache-SQL_PUBLIC_VERTEX_TBL/part-913.bin:
Too many open files
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:91)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.newAsynchronousFileChannel(UnixFileSystemProvider.java:196)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
at
java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:301)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIO.(AsyncFileIO.java:57)
at
org.apache.ignite.internal.processors.cache.persistence.file.AsyncFileIOFactory.create(AsyncFileIOFactory.java:53)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.init(FilePageStore.java:416)
... 12 more
{noformat}
It happen because systemd service description
(/etc/systemd/system/apache-ignite@.service) didn't contain
{noformat}
LimitNOFILE=50
(possible with) LimitNPROC=50
{noformat}
see: https://fredrikaverpil.github.io/2016/04/27/systemd-and-resource-limits/
Possible, installation script should also add:
* "fs.file-max = 2097152" to "/etc/sysctl.conf"
* into /etc/security/limits.conf:
{noformat}
* hardnofile 50
* softnofile 50
root hardnofile 50
root
[jira] [Created] (IGNITE-11782) WAL iterator for collect per-pageId info
Anton Kalashnikov created IGNITE-11782: -- Summary: WAL iterator for collect per-pageId info Key: IGNITE-11782 URL: https://issues.apache.org/jira/browse/IGNITE-11782 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Implement WAL iterator for collect per-pageId info (page is root) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11781) Invalid mode while deserializing JTS geometry objects with binary marshaller
Martin Raifer created IGNITE-11781:
--
Summary: Invalid mode while deserializing JTS geometry objects
with binary marshaller
Key: IGNITE-11781
URL: https://issues.apache.org/jira/browse/IGNITE-11781
Project: Ignite
Issue Type: Bug
Components: binary, clients, compute
Affects Versions: 2.7
Environment: Tested on a 64 bit Ubuntu 18.04, with OpenJDK 1.8.0_191,
running Ignite 2.7
Reporter: Martin Raifer
JTS Geometry objects can't be used as return types of compute jobs. Instead,
_null_ is returned. Here's a minimal example showing the bug (and one example
that shows that the bug is sometimes not triggered under slightly different
conditions):
{code:java}
// this prints "null" (wrong – the expected result would be "POINT EMPTY"):
igniteCompute.broadcast(() -> (new
GeometryFactory()).createPoint()).forEach(System.out::println);
// this prints "[POINT EMPTY]" (correct):
igniteCompute.broadcast(() -> Collections.singletonList((new
GeometryFactory()).createPoint())).forEach(System.out::println);
{code}
This is caused by an invalid _BinaryWriteMode_ of _OPTIMIZED_ in
[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L852]
which then leads to a null value to be returned a few lines further down:
[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L882]
>From what I can see, the _OPTIMIZED_ mode is set in
>[https://github.com/apache/ignite/blob/ignite-2.7/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryClassDescriptor.java#L161]
> where the objects are explicitly tested against the
>_org.locationtech.jts.geom.Geometry_ class. This could be a regression
>introduced in https://issues.apache.org/jira/browse/IGNITE-4259 ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11780) Command handler refactoring
Eduard Shangareev created IGNITE-11780: -- Summary: Command handler refactoring Key: IGNITE-11780 URL: https://issues.apache.org/jira/browse/IGNITE-11780 Project: Ignite Issue Type: Improvement Reporter: Eduard Shangareev Now it is just a big ball of mud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11779) [TC Bot] Support configurable notifications for non-master branches
Dmitriy Pavlov created IGNITE-11779: --- Summary: [TC Bot] Support configurable notifications for non-master branches Key: IGNITE-11779 URL: https://issues.apache.org/jira/browse/IGNITE-11779 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Now dev.list notifications performed using fake common user and its settings. Need to add this rule to branches.json config and support other branches (e.g. release) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11778) [TC Bot] Implement unconditional blockers and add license check suites to blockers
Dmitriy Pavlov created IGNITE-11778: --- Summary: [TC Bot] Implement unconditional blockers and add license check suites to blockers Key: IGNITE-11778 URL: https://issues.apache.org/jira/browse/IGNITE-11778 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov License by RAT plugin validation should be also - considered as a blocker in PR validation - introduced failure should cause notification on tracked branches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11777) [TC Bot] Send a notification in case test count in suite goes down and does not change during 4 runs in a row
Dmitriy Pavlov created IGNITE-11777: --- Summary: [TC Bot] Send a notification in case test count in suite goes down and does not change during 4 runs in a row Key: IGNITE-11777 URL: https://issues.apache.org/jira/browse/IGNITE-11777 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov In case tests stopped from being executed by a configuration error, the community can miss it because there are no notifications generated. Test count may be a floating value because of timeouts and exit codes, so we can compare only the successful run of suites. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11776) IgnitePdsStartWIthEmptyArchive is flaky
Vyacheslav Koptilin created IGNITE-11776:
Summary: IgnitePdsStartWIthEmptyArchive is flaky
Key: IGNITE-11776
URL: https://issues.apache.org/jira/browse/IGNITE-11776
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
It looks like the root cause of the issue is late registration of the listener.
It should be done statically via {{IgniteConfiguration}} I think.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Hi Dmitry, Maybe if it will turn out that all tests fail because of functionality we should ignore or mute these tests in the context of the ticket IGNITE-11708? ср, 17 апр. 2019 г. в 23:20, Dmitriy Pavlov : > Hi Ivan F. > > Thank you for finding it and bringing it here. > > Please feel free to fix test to run (and fail) if the code it tests is > faulty now. If the community knows the moment when tests run will be > enabled, it is absolutely not an issue, that TeamCity Bot will complain > about new failures. I strongly believe that we should see a true picture of > tests output rather than having these tests not running. > > Sincerely, > Dmitriy Pavlov > > ср, 17 апр. 2019 г. в 22:05, Ivan Rakov : > > > Hi Ivan, > > > > I've checked your branch. Seems like these tests fail due to real issue > > in functionality. > > I'll take a look. > > > > Best Regards, > > Ivan Rakov > > > > On 17.04.2019 13:54, Ivan Fedotov wrote: > > > Hi, Igniters! > > > > > > During work on iep-30[1] I discovered that > > > IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > > tests[2] > > > - do not work. > > > You can check it just run one of the tests with log output, for example > > > ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > > > There is no warning notification in the console. The same situation > with > > > other IgniteConfigVariationsAbstractTest subclasses - tests run, but > they > > > simply represent empty code. > > > > > > So, I created a ticket on such issue [4] and it turned out that the > > problem > > > is with ruleChain in IgniteConfigVariationsAbstractTest [5]. > > > The rule that is responsible for running a test statement does not > start > > > indeed [6] under ruleChain runRule. I suggested a solution - move > > testsCfg > > > initialization to > > > IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After > such > > > changes ruleChain becomes not necessary. > > > > > > But I faced another problem - multiple failures on TeamCity [7]. From > > logs, > > > it seems that failures are related to what tests check, but not JUnit > > error. > > > I can not track TeamCity history on that fact were tests failed or not > on > > > the previous JUnit version - the oldest log is dated the start of the > > March > > > when JUnit4 > > > already was implemented (for example, this [8] test). > > > Moreover, there are not so much failed tests, but because of running > with > > > multiple configurations > > (InterceptorCacheConfigVariationsFullApiTestSuite_0 > > > ..._95) it turns out about 400 failed tests. TeamCity results also > > confirm > > > that tests do not work in the master branch - duration time is less > than > > > 1ms. Now all tests are green and that is not surprising - under @Test > > > annotation, nothing happens. > > > > > > Could some of us confirm or disprove my guess that tests are red > because > > of > > > its functionality, but not JUnit implementation? > > > And if it is true, how should I take such fact into account in this > > ticket? > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > > > [2] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java > > > [3] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 > > > [4] https://issues.apache.org/jira/browse/IGNITE-11708 > > > [5] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 > > > [6] > > > > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > > > [7] > > > > > > https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest > > > [8] > > > > > > https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 > > > > > > -- Ivan Fedotov. ivanan...@gmail.com
[jira] [Created] (IGNITE-11775) IgnitePdsWithTtlTest is flaky
Vyacheslav Koptilin created IGNITE-11775:
Summary: IgnitePdsWithTtlTest is flaky
Key: IGNITE-11775
URL: https://issues.apache.org/jira/browse/IGNITE-11775
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
It seems the reason for test failure is the fact that TTL manager cannot clean
up all entries because of TTL throttling (see {{GridCacheTtlManager#expire}}
and {{GridCacheOffheapManager.GridCacheDataStore#purgeExpired}}). It does not
seem a bug/problem, it just required to set the
{{IgniteSystemProperties.IGNITE_UNWIND_THROTTLING_TIMEOUT}} to a smaller value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11774) NPE TxDeadlockDetection in case of concurrent cache stop and tx.
Stanilovsky Evgeny created IGNITE-11774:
---
Summary: NPE TxDeadlockDetection in case of concurrent cache stop
and tx.
Key: IGNITE-11774
URL: https://issues.apache.org/jira/browse/IGNITE-11774
Project: Ignite
Issue Type: Bug
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
In process of working under :
[IGNITE-11592|https://issues.apache.org/jira/browse/IGNITE-11592] reproduced
NPE, need further research, reproducer commented in upper ticket code.
{code:java}
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.primary(TxDeadlockDetection.java:400)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.mapTxKeys(TxDeadlockDetection.java:376)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.map(TxDeadlockDetection.java:275)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.init(TxDeadlockDetection.java:267)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection$TxDeadlockFuture.access$100(TxDeadlockDetection.java:158)
at
org.apache.ignite.internal.processors.cache.transactions.TxDeadlockDetection.detectDeadlock(TxDeadlockDetection.java:91)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.detectDeadlock(IgniteTxManager.java:2155)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onTimeout(GridNearOptimisticTxPrepareFuture.java:776)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11773) JDBC suite hangs due to cleared non-serializable proxy objects
Pavel Kovalenko created IGNITE-11773:
Summary: JDBC suite hangs due to cleared non-serializable proxy
objects
Key: IGNITE-11773
URL: https://issues.apache.org/jira/browse/IGNITE-11773
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.8
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
Fix For: 2.8
{noformat}
[01:53:02]W: [org.apache.ignite:ignite-clients]
java.lang.AssertionError
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.testframework.junits.GridAbstractTest$SerializableProxy.readResolve(GridAbstractTest.java:2419)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.lang.reflect.Method.invoke(Method.java:498)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1260)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2078)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:141)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:163)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10039)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.deserialize(CacheConfigurationEnricher.java:151)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.enrich(CacheConfigurationEnricher.java:122)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.CacheConfigurationEnricher.enrichFully(CacheConfigurationEnricher.java:143)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.getConfigFromTemplate(GridCacheProcessor.java:3776)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor.dynamicTableCreate(GridQueryProcessor.java:1549)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommandH2(CommandProcessor.java:437)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.CommandProcessor.runCommand(CommandProcessor.java:195)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeCommand(IgniteH2Indexing.java:954)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1038)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2292)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2288)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
[01:53:02]W: [org.apache.ignite:ignite-clients] at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2804)
[01:53:02]W:
[jira] [Created] (IGNITE-11772) [ML] Broken javadoc
Yury Babak created IGNITE-11772: --- Summary: [ML] Broken javadoc Key: IGNITE-11772 URL: https://issues.apache.org/jira/browse/IGNITE-11772 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Yury Babak Fix For: 2.7.5 [08:56:09][WARNING] Javadoc Warnings [08:56:09][WARNING] /opt/buildagent/work/5688f4d35e09c9c2/modules/ml/src/main/java/org/apache/ignite/ml/composition/boosting/convergence/simple/ConvergenceCheckerStub.java:51: warning - @param argument "vectorizer" is not a parameter name. [08:56:09][WARNING] /opt/buildagent/work/5688f4d35e09c9c2/modules/ml/src/main/java/org/apache/ignite/ml/structures/DatasetRow.java:119: warning - @return tag cannot be used in method with void return type. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: newbie + kubernetes IpFinder
Hi Denis, Thanks for your reply. I've created a ticket ( https://issues.apache.org/jira/browse/IGNITE-11771) for the first part of my email. Could you please have a look at it to make sure it follows your conventions? If all good can you please assign to me so I can start working on it? As for the second part of my email: is there any way to control which pods should form a cluster, or will always all of them join to one big cluster? Thanks, Balazs On Wed, 17 Apr 2019 at 19:19, Denis Magda wrote: > Hello Balazs, > > Thanks for reaching the community out. Certainly, we'll appreciate if you > contribute your changes back. Could you please create a ticket in JIRA and > open the pull-request? Someone from the community will review and accept > your improvements. > > Just in case, you can find more on contribution here: > https://ignite.apache.org/community/contribute.html#contribute > > - > Denis > > > On Wed, Apr 17, 2019 at 8:03 AM Péterfi, Balázs > wrote: > > > Hi All, > > > > First of all I wanted to say hi as I've just joined to the list! > > > > Secondly, I'm moving one of my apps to Kubernetes and found > > the ignite-kubernetes lib for finding the pods for the cluster. After > > playing with it a bit I found out that it won't work for me, because it > > only collects the IPs for the pods that are in a ready state. My problem > > with that is when my app is starting it warms up the cache which takes > some > > time and only when this is done will it have a ready state in k8s. But at > > that point all my pods have started a single node cluster and they end up > > in a split-brain scenario (not to mention that they all did the cache > > warm-up which is a waste). In Hazelcast they have a flag to include > > non-ready pods as well which solves the issue. I have an implementation > for > > that and would be happy to add it in the original IpFinder with some > > configuration to control that behavior, unless someone here tells me > > otherwise. > > > > There is another change I did on the original version which is to prevent > > two ReplicaSets of the same app joining to each-other's cluster. This is > a > > must have for me when deploying a new version while leaving the old one > > running until the warm-up finishes. I couldn't find any configuration > that > > prevents this happening so I changed the IpFinder to only look for pods > > from the same ReplicaSet. I wonder if there is any other solution for > this > > issue? > > > > Best regards, > > Balazs > > >
[jira] [Created] (IGNITE-11771) Kubernetes discovery support for non-ready pods
Balazs Peterfi created IGNITE-11771: --- Summary: Kubernetes discovery support for non-ready pods Key: IGNITE-11771 URL: https://issues.apache.org/jira/browse/IGNITE-11771 Project: Ignite Issue Type: Improvement Affects Versions: 2.7 Reporter: Balazs Peterfi I have a use case where Ignite is running in embedded mode and on start-up there is a time consuming task to warm-up the cache. During that time Kubernetes sees the pods as not ready due to the loading, thus the current implementation doesn't return them as potential members. Eventually they would become ready and see each-other but by then it would be a split-brain situation. The idea is to return IPs not only for "ready" pods but for "not ready" ones as well in case the discovery client is configured that way. See more details here: [https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#endpointsubset-v1-core] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11770) Document PARTITON_SUPPLIED and PARTITION_MISSED events
Ilya Kasnacheev created IGNITE-11770: Summary: Document PARTITON_SUPPLIED and PARTITION_MISSED events Key: IGNITE-11770 URL: https://issues.apache.org/jira/browse/IGNITE-11770 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Ilya Kasnacheev Assignee: Artem Budnikov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
