[jira] [Commented] (IGNITE-14572) Include metastorage into snapshot
[ https://issues.apache.org/jira/browse/IGNITE-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346456#comment-17346456 ] Maxim Muzafarov commented on IGNITE-14572: -- [~xtern] Merged to the master branch, thank you for the review. > Include metastorage into snapshot > - > > Key: IGNITE-14572 > URL: https://issues.apache.org/jira/browse/IGNITE-14572 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 10h 40m > Remaining Estimate: 0h > > Currently, only cache and cache groups with CacheType.USER included into a > snapshot. We must also include into snapshot the metastorage data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14572) Include metastorage into snapshot
[
https://issues.apache.org/jira/browse/IGNITE-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346455#comment-17346455
]
Ignite TC Bot commented on IGNITE-14572:
{panel:title=Branch: [pull/9047/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9047/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 3{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6011416]]
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
IgniteSnapshotWithMetastorageTest.testClusterSnapshotWithMetastorage -
PASSED{color}
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
IgniteSnapshotWithMetastorageTest.testMetastorageUpdateDuringSnapshot -
PASSED{color}
* {color:#013220}IgniteBasicWithPersistenceTestSuite:
IgniteSnapshotWithMetastorageTest.testMetastorageUpdateOnSnapshotFail -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6011061buildTypeId=IgniteTests24Java8_RunAll]
> Include metastorage into snapshot
> -
>
> Key: IGNITE-14572
> URL: https://issues.apache.org/jira/browse/IGNITE-14572
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.11
>
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> Currently, only cache and cache groups with CacheType.USER included into a
> snapshot. We must also include into snapshot the metastorage data.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14544) Calcite engine. Support DISTINCT aggregates
[
https://issues.apache.org/jira/browse/IGNITE-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346316#comment-17346316
]
Taras Ledkov commented on IGNITE-14544:
---
[~alex_pl], [~korlov], please review the patch.
I've added the {{AggregateExpandDistinctAggregatesRule.Config.JOIN}} and the
hint {{EXPAND_DISTINCT_AGG}} to disable convert LogicalAggretate to Ignite
aggregates when it contains distinct AggCall.
> Calcite engine. Support DISTINCT aggregates
> ---
>
> Key: IGNITE-14544
> URL: https://issues.apache.org/jira/browse/IGNITE-14544
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now, DISTINCT aggregates not implemented.
> (e.g. {{SELECT COUNT (DISTINCT lastName) FROM person}})
> Tests:
> {{aggregate/aggregates/test_count.test}}
> {{aggregate/aggregates/test_avg.test}}
> {{aggregate/aggregates/test_distinct_aggr.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14292) Change permissions required to create/destroy caches in GridRestProcessor
[
https://issues.apache.org/jira/browse/IGNITE-14292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346241#comment-17346241
]
Ignite TC Bot commented on IGNITE-14292:
{panel:title=Branch: [pull/9098/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9098/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6010665buildTypeId=IgniteTests24Java8_RunAll]
> Change permissions required to create/destroy caches in GridRestProcessor
> -
>
> Key: IGNITE-14292
> URL: https://issues.apache.org/jira/browse/IGNITE-14292
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.9.1
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{GridRestProcessor}} authorizes {{ADMIN_CACHE}} permission before cache
> creation/destruction. This is inconsistent with thin client connector
> behavior and looks counterintuitive. {{ADMIN_CACHE}} should be replaced with
> {{CACHE_CREATE}} and {{CACHE_DESTROY}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346239#comment-17346239 ] Maxim Muzafarov commented on IGNITE-14575: -- [~sergeychugunov] Sure, make sense. I think we can wait even more just to be sure that the fix is fine. > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14733) NativeType and ColumnType names should matches.
[ https://issues.apache.org/jira/browse/IGNITE-14733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14733: -- Labels: iep-54 ignite-3 (was: ) > NativeType and ColumnType names should matches. > --- > > Key: IGNITE-14733 > URL: https://issues.apache.org/jira/browse/IGNITE-14733 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Trivial > Labels: iep-54, ignite-3 > > For now, column types names contains their sizes like ColumnType.INT8, > ColumnType.INT16 and so on, to abstract from the platform Ignite can be used > on (via thin-clients). > But we use Java-specific notation for internal types: NativeType.BYTE, > NativeType.LONG. > Let's rename NativeTypes to easily match them to/from column type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14733) NativeType and ColumnType names should matches.
Andrey Mashenkov created IGNITE-14733: - Summary: NativeType and ColumnType names should matches. Key: IGNITE-14733 URL: https://issues.apache.org/jira/browse/IGNITE-14733 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov For now, column types names contains their sizes like ColumnType.INT8, ColumnType.INT16 and so on, to abstract from the platform Ignite can be used on (via thin-clients). But we use Java-specific notation for internal types: NativeType.BYTE, NativeType.LONG. Let's rename NativeTypes to easily match them to/from column type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346223#comment-17346223 ] Sergey Chugunov commented on IGNITE-14575: -- [~mmuzaf], Lets take a short timeout (say, one extra day) and give the proper fix a chance. It is already in progress and now waiting just for green visa. If everything goes smoothly we'll get the issue fixed and preserve clean master history without revert commits. If the fix isn't merged till the end of tomorrow, I'm OK with reverting current patch and integrating it with the fix. Does it make sense to you? > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14732) Use enum sort order in index columns configuration.
Andrey Mashenkov created IGNITE-14732:
-
Summary: Use enum sort order in index columns configuration.
Key: IGNITE-14732
URL: https://issues.apache.org/jira/browse/IGNITE-14732
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Mashenkov
Fix For: 3.0
Now SortedIndexColumn interface has method that returns boolean for sort order.
{code:java}
boolean asc();{code}
Let's introduce a enum Sort with ASC/DESC values for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14675) Refactor IgniteAuthenticationProcessor callbacks
[ https://issues.apache.org/jira/browse/IGNITE-14675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346206#comment-17346206 ] Mikhail Petrov commented on IGNITE-14675: - [~NSAmelchev], Thanks a lot for the review. > Refactor IgniteAuthenticationProcessor callbacks > > > Key: IGNITE-14675 > URL: https://issues.apache.org/jira/browse/IGNITE-14675 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Since IgniteAuthenticationProcessor is not treated as a separate processor, > it is needed to refactor explicit IgniteAuthenticationProcessor callbacks > from other processors. Many of them can be eliminated. > For example onActivate method can be replaced with > PartitionsExchangeAware#onDoneBeforeTopologyUnlock > Explicit onLocalJoin method call can be replaced with > discoMgr.localJoinFuture().listen(fut -> onLocalJoin()); > and so on. > It is also possible that this will require changing the startup order of the > IgniteAuthenticationProcessor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14555) Calcite engine. Create table from query result
[
https://issues.apache.org/jira/browse/IGNITE-14555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-14555:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Create table from query result
> --
>
> Key: IGNITE-14555
> URL: https://issues.apache.org/jira/browse/IGNITE-14555
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Minor
>
> Provide ability to create table from the result of the query: {{CREATE TABLE
> my_tbl AS }}.
> Affected tests:
> {{modules/calcite/src/test/sql/types/decimal/decimal_aggregates.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14731) .NET node may occasionally catch SIGSEGV in managed code
Ilya Kasnacheev created IGNITE-14731:
Summary: .NET node may occasionally catch SIGSEGV in managed code
Key: IGNITE-14731
URL: https://issues.apache.org/jira/browse/IGNITE-14731
Project: Ignite
Issue Type: Bug
Components: platforms
Reporter: Ilya Kasnacheev
{code}
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `dotnet exec
/home/ikasnacheev/14733/bin/Debug/netcoreapp2.0/14733.dll 12'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f971c2cc7b9 in CONTEXTFromNativeContext () from
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.5/libclrjit.so
Missing separate debuginfos, use: debuginfo-install dotnet-host-5.0.5-1.x86_64
(gdb) bt
#0 0x7f971c2cc7b9 in CONTEXTFromNativeContext () from
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.5/libclrjit.so
#1 0x7f971c2a1de8 in common_signal_handler(int, siginfo_t*, void*, int,
...) () from /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.5/libclrjit.so
#2 0x7f971c2a1c16 in signal_handler_worker () from
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.5/libclrjit.so
#3 0x7f971c2de7ce in CallSignalHandlerWrapper0 () from
/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.5/libclrjit.so
#4 0x7f96a6a1291d in ?? ()
#5 0x7f9410a56fd0 in ?? ()
#6 0x7f92ef5611e8 in ?? ()
#7 0x000a in ?? ()
#8 0x7f95d420c0e0 in ?? ()
#9 0x7f9410a57030 in ?? ()
#10 0x7f96a69f6cb6 in ?? ()
#11 0x7f9410a57000 in ?? ()
#12 0x7f96800256c0 in ?? ()
#13 0x in ?? ()
{code}
Please note that it happens once a few days on three node setup. Maybe if will
happen more often if null dereference is simulated explicitly.
COMPlus_EnableAlternateStackCheck=1 is set.
.NET Core SDK (3.1.408), Linux.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12291) Create controllable paged query requests / responses for TextQuery similar to current SQL result processing
[
https://issues.apache.org/jira/browse/IGNITE-12291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346175#comment-17346175
]
Andrey Mashenkov commented on IGNITE-12291:
---
[~timonin.maksim], you wrote:
{noformat}
So, I think, that number of pages to load can be limited with different
approach that described in the ticket description. We can move check of limit
to the `next()` call instead of `enqueue()`. After `next()` returns NULL
iterator automatically closes and send cancel requests to all nodes. {noformat}
You saves data into collection that will be never used.
What issue does the logic moving fix?
Lucene returns result sorted by relevance/score, but we might miss this
information somewhere.
> Create controllable paged query requests / responses for TextQuery similar to
> current SQL result processing
> ---
>
> Key: IGNITE-12291
> URL: https://issues.apache.org/jira/browse/IGNITE-12291
> Project: Ignite
> Issue Type: Improvement
>Reporter: Yuriy Shuliha
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now query initiator node sends 1 _GridCacheQueryRequest_ and can get
> multiple _GridCacheQueryResponse_-s per remote.
> TextQuery processing finishes when all remotes send _GridCacheQueryResponse_
> with 'finished' flag.
> _TextQuery_ processing should be reworked like it was done for SQL queries.
> Ignite has _GridQueryNextPageRequest \ Response_ classes for SQL result
> processing.
> Similar processing should be implemented for _TextQueries_:
> *GridTextQueryNextPageRequest*
> *GridTextQueryNextPageResponse*
> Proper _TextQuery_ response processing should be implemented in
> _GridCacheQueryFutureAdapter._
> This will allow us to add correct sorting and apply limit correctly on reduce.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13509) Support encrypted caches in ducktape tests
[ https://issues.apache.org/jira/browse/IGNITE-13509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-13509: -- Description: Add support for encrypted caches in ignite ducktape tests. Add PDS compatibility test for encrypted caches. It may be worth adding a setting so that you can run all the available encryption tests (similar to SSL). was: Add support for encrypted caches in ignite ducktape tests. Add PDS compatibility test for encrypted caches. > Support encrypted caches in ducktape tests > -- > > Key: IGNITE-13509 > URL: https://issues.apache.org/jira/browse/IGNITE-13509 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Add support for encrypted caches in ignite ducktape tests. > Add PDS compatibility test for encrypted caches. > It may be worth adding a setting so that you can run all the available > encryption tests (similar to SSL). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346174#comment-17346174 ] Maxim Muzafarov commented on IGNITE-14575: -- [~sdanilov] I suggest revert this patch and fix all issues in a calm manner. Failing the test suite leads to the waste of agent resources and blocks testing other patches. > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14692) Validate tuple for STRICT schema
[ https://issues.apache.org/jira/browse/IGNITE-14692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346161#comment-17346161 ] Andrey Mashenkov commented on IGNITE-14692: --- [~tledkov-gridgain], I've left few comments to the PR. > Validate tuple for STRICT schema > > > Key: IGNITE-14692 > URL: https://issues.apache.org/jira/browse/IGNITE-14692 > Project: Ignite > Issue Type: Improvement >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Labels: iep-54, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > The part of the IGNITE-14556. > At a point of Table public method is called by a user, we need to validate > user input > Description. > We can add this logic to check if value fields match the current schema > version (no new fields). > For STRICT-Schema. If Tuple has one or more additional columns, then we > should fail the user operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly
[
https://issues.apache.org/jira/browse/IGNITE-14248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346150#comment-17346150
]
Vladimir Pligin commented on IGNITE-14248:
--
[~slava.koptilin] could please have a look? I've prepared a patch.
> Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock
> properly
> ---
>
> Key: IGNITE-14248
> URL: https://issues.apache.org/jira/browse/IGNITE-14248
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Vladimir Pligin
>Assignee: Vladimir Pligin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an exception (or even Error) is thrown inside of the method then the node
> turns into some unrecoverable state. Here's an example.
> # an exchange is about to finish, it's time to invalidate partition
> reservations.
> # exchange thread delegates it to a thread in the management pool
> # management pool tries to allocate a new thread (maybe it's idle and
> therefore empty)
> # for example ulimit is reached, the error is
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> # It's being logged, no further action is taken
> # partitions are reserved forever
> Message:
>
> {code:java}
> 2021-02-25 05:52:03.242 [exchange-worker-#182] ERROR
> o.a.i.i.p.q.h.t.PartitionReservationManager - Unexpected exception on start
> reservations cleanup
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:803)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runLocal(GridClosureProcessor.java:847)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.PartitionReservationManager.onDoneAfterTopologyUnlock(PartitionReservationManager.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2617)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1064)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3375)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3194)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> Code of PartitionReservationManager.onDoneAfterTopologyUnlock:
> {code:java}
> @Override public void onDoneAfterTopologyUnlock(final
> GridDhtPartitionsExchangeFuture fut) {
> try {
> // Must not do anything at the exchange thread. Dispatch to the
> management thread pool.
> ctx.closure().runLocal(() -> {
> AffinityTopologyVersion topVer =
> ctx.cache().context().exchange()
>
> .lastAffinityChangedTopologyVersion(fut.topologyVersion());
> reservations.forEach((key, r) -> {
> if (r != REPLICATED_RESERVABLE &&
> !F.eq(key.topologyVersion(), topVer)) {
> assert r instanceof GridDhtPartitionsReservation;
>((GridDhtPartitionsReservation)r).invalidate();
> }
> });
> },
> GridIoPolicy.MANAGEMENT_POOL);
> }
> catch (Throwable e) {
> log.error("Unexpected exception on start reservations cleanup",
> e);
> }
> }
> {code}
>
>
> My vision is that there are two basic approaches:
> * to kill the node (it's already non-functional at this point), seems to be
> a FH job.
> * try to recover somehow (to be honest it's not clear how exactly)
> This particular OOM situation seems unrecoverable in fact. It's an
> environment misconfiguration. It would be
[jira] [Commented] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly
[
https://issues.apache.org/jira/browse/IGNITE-14248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346146#comment-17346146
]
Ignite TC Bot commented on IGNITE-14248:
{panel:title=Branch: [pull/9094/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9094/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6003739]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
ReservationsOnDoneAfterTopologyUnlockFailTest.testFailureHandlerTriggeredOnTopologyUnlockError
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6003781buildTypeId=IgniteTests24Java8_RunAll]
> Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock
> properly
> ---
>
> Key: IGNITE-14248
> URL: https://issues.apache.org/jira/browse/IGNITE-14248
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Vladimir Pligin
>Assignee: Vladimir Pligin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If an exception (or even Error) is thrown inside of the method then the node
> turns into some unrecoverable state. Here's an example.
> # an exchange is about to finish, it's time to invalidate partition
> reservations.
> # exchange thread delegates it to a thread in the management pool
> # management pool tries to allocate a new thread (maybe it's idle and
> therefore empty)
> # for example ulimit is reached, the error is
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> # It's being logged, no further action is taken
> # partitions are reserved forever
> Message:
>
> {code:java}
> 2021-02-25 05:52:03.242 [exchange-worker-#182] ERROR
> o.a.i.i.p.q.h.t.PartitionReservationManager - Unexpected exception on start
> reservations cleanup
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:803)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runLocal(GridClosureProcessor.java:847)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.PartitionReservationManager.onDoneAfterTopologyUnlock(PartitionReservationManager.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2617)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1064)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3375)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3194)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> Code of PartitionReservationManager.onDoneAfterTopologyUnlock:
> {code:java}
> @Override public void onDoneAfterTopologyUnlock(final
> GridDhtPartitionsExchangeFuture fut) {
> try {
> // Must not do anything at the exchange thread. Dispatch to the
> management thread pool.
> ctx.closure().runLocal(() -> {
> AffinityTopologyVersion topVer =
> ctx.cache().context().exchange()
>
> .lastAffinityChangedTopologyVersion(fut.topologyVersion());
> reservations.forEach((key, r) -> {
> if (r != REPLICATED_RESERVABLE &&
> !F.eq(key.topologyVersion(), topVer)) {
> assert r instanceof GridDhtPartitionsReservation;
>((GridDhtPartitionsReservation)r).invalidate();
>
[jira] [Commented] (IGNITE-14545) Calcite engine. Unicode literal not supported
[
https://issues.apache.org/jira/browse/IGNITE-14545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346144#comment-17346144
]
Aleksey Plekhanov commented on IGNITE-14545:
[~tledkov-gridgain], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Unicode literal not supported
> -
>
> Key: IGNITE-14545
> URL: https://issues.apache.org/jira/browse/IGNITE-14545
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unicode literal not supported.
> e.g. {{SELECT }}
> Tests:
> {{aggregate/aggregates/test_aggr_string.test}}
> {{types/string/test_unicode.test_ignored}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14730) Calcite engine. Cast to INTERVAL data type is not working
[
https://issues.apache.org/jira/browse/IGNITE-14730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14730:
---
Description:
Cast of any expression to INTERVAL data type, for example:
{noformat}
select null::interval
{noformat}
Fails with the exception:
{noformat}
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:539)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:402)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:250)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:512)
... 3 more
Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered " "::"
":: "" at line 1, column 12.
Was expecting:
{noformat}
was:
Cast of any expression to INTERVAL data type, for example:
{noformat}
select null::interval
{noformat}
Fails with the exception:
{noformat}
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:539)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:402)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:250)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:512)
... 3 more
Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered " "::"
":: "" at line 1, column 12.
Was expecting:
{noformat}
> Calcite engine. Cast to INTERVAL data type is not working
> -
>
> Key: IGNITE-14730
> URL: https://issues.apache.org/jira/browse/IGNITE-14730
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Minor
>
> Cast of any expression to INTERVAL data type, for example:
> {noformat}
> select null::interval
> {noformat}
> Fails with the exception:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:539)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:402)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:250)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:512)
> ... 3 more
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "
> "::" ":: "" at line 1, column 12.
> Was expecting:
>
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14730) Calcite engine. Cast to INTERVAL data type is not working
[
https://issues.apache.org/jira/browse/IGNITE-14730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-14730:
---
Priority: Minor (was: Major)
> Calcite engine. Cast to INTERVAL data type is not working
> -
>
> Key: IGNITE-14730
> URL: https://issues.apache.org/jira/browse/IGNITE-14730
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Minor
>
> Cast of any expression to INTERVAL data type, for example:
>
> {noformat}
> select null::interval
> {noformat}
> Fails with the exception:
>
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:539)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:402)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:250)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:512)
> ... 3 more
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered "
> "::" ":: "" at line 1, column 12.
> Was expecting:
>
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14730) Calcite engine. Cast to INTERVAL data type is not working
Aleksey Plekhanov created IGNITE-14730:
--
Summary: Calcite engine. Cast to INTERVAL data type is not working
Key: IGNITE-14730
URL: https://issues.apache.org/jira/browse/IGNITE-14730
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Cast of any expression to INTERVAL data type, for example:
{noformat}
select null::interval
{noformat}
Fails with the exception:
{noformat}
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query.
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:539)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:402)
at
org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:250)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:512)
... 3 more
Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered " "::"
":: "" at line 1, column 12.
Was expecting:
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12747) Calcite integration. Correlated queries support.
[ https://issues.apache.org/jira/browse/IGNITE-12747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346128#comment-17346128 ] Stanilovsky Evgeny commented on IGNITE-12747: - fix ready for review, [~korlov], [~alex_pl] plz take a look? > Calcite integration. Correlated queries support. > > > Key: IGNITE-12747 > URL: https://issues.apache.org/jira/browse/IGNITE-12747 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Andrey Mashenkov >Priority: Critical > Time Spent: 0.5h > Remaining Estimate: 0h > > Rewrite correlated subqueries. > Useful links: > [https://zhuanlan.zhihu.com/p/60380557] > [https://zhuanlan.zhihu.com/p/62338250] > [https://zhuanlan.zhihu.com/p/66227661] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346121#comment-17346121 ] Semyon Danilov commented on IGNITE-14575: - [~mmuzaf] I think I tracked down the problem: https://issues.apache.org/jira/browse/IGNITE-14729 > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14729) Fix JDBC test suite flakiness after IGNITE-14575
Semyon Danilov created IGNITE-14729: --- Summary: Fix JDBC test suite flakiness after IGNITE-14575 Key: IGNITE-14729 URL: https://issues.apache.org/jira/browse/IGNITE-14729 Project: Ignite Issue Type: Bug Reporter: Semyon Danilov Assignee: Semyon Danilov JDBC test suite went flaky after IGNITE-14575. On the first look it seems like there is a race condition: ClientImpl notifies listeners (notably, DistributedMetaStorage) about `EVT_NODE_JOINED` before `state` is set to `CONNECTED`. This way, distributed meta storage tries to perform write operations and ClientImpl is not ready yet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14545) Calcite engine. Unicode literal not supported
[
https://issues.apache.org/jira/browse/IGNITE-14545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346118#comment-17346118
]
Taras Ledkov commented on IGNITE-14545:
---
[~alex_pl], the patch is OK with me. Please merge
> Calcite engine. Unicode literal not supported
> -
>
> Key: IGNITE-14545
> URL: https://issues.apache.org/jira/browse/IGNITE-14545
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unicode literal not supported.
> e.g. {{SELECT }}
> Tests:
> {{aggregate/aggregates/test_aggr_string.test}}
> {{types/string/test_unicode.test_ignored}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14353) Ability to specify application name for IgniteLogger instead of nodeId
[
https://issues.apache.org/jira/browse/IGNITE-14353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346089#comment-17346089
]
Nikolay Izhikov commented on IGNITE-14353:
--
Hello, [~av].
Can you, please, take a look at my change -
https://github.com/apache/ignite/pull/9101
> Ability to specify application name for IgniteLogger instead of nodeId
> --
>
> Key: IGNITE-14353
> URL: https://issues.apache.org/jira/browse/IGNITE-14353
> Project: Ignite
> Issue Type: New Feature
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Right now, user can't change IgniteLogger file name.
> CDC application should use it's own files for logging, something like
> {{ignite-cdc-[cdc-consumer-id].log}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (IGNITE-14353) Ability to specify application name for IgniteLogger instead of nodeId
[
https://issues.apache.org/jira/browse/IGNITE-14353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reopened IGNITE-14353:
--
After a private discussion with [~av] we decided to introduce the "application
name" configuration for IgniteLogger instead of postfix.
It's looking more natural with the ability to specify "node id".
> Ability to specify application name for IgniteLogger instead of nodeId
> --
>
> Key: IGNITE-14353
> URL: https://issues.apache.org/jira/browse/IGNITE-14353
> Project: Ignite
> Issue Type: New Feature
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Right now, user can't change IgniteLogger file name.
> CDC application should use it's own files for logging, something like
> {{ignite-cdc-[cdc-consumer-id].log}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346086#comment-17346086 ] Semyon Danilov commented on IGNITE-14575: - [~mmuzaf] thanks for the notice, I will get right to it > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346082#comment-17346082 ] Maxim Muzafarov commented on IGNITE-14575: -- Tests passed successfully in the branch with reverted commit: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JdbcDriver=buildTypeStatusDiv_IgniteTests24Java8=pull%2F9100%2Fhead > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14353) Ability to specify application name for IgniteLogger instead of nodeId
[
https://issues.apache.org/jira/browse/IGNITE-14353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14353:
-
Summary: Ability to specify application name for IgniteLogger instead of
nodeId (was: Ability to specify postfix for IgniteLogger instead of nodeId)
> Ability to specify application name for IgniteLogger instead of nodeId
> --
>
> Key: IGNITE-14353
> URL: https://issues.apache.org/jira/browse/IGNITE-14353
> Project: Ignite
> Issue Type: New Feature
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Right now, user can't change IgniteLogger file name.
> CDC application should use it's own files for logging, something like
> {{ignite-cdc-[cdc-consumer-id].log}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Rakhmankulov updated IGNITE-14728: - Description: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. The next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. # If there is no value, then the old system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. # If a system property is not defined then the default value from java will be written to DMS (*500*). # On property check print to log value and source of value. Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. was: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. The next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. # If there is no value, then the old system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. # If a system property is not defined then the default value from java will be written to DMS (*500*). Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Priority: Minor > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most > part of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Rakhmankulov reassigned IGNITE-14728: Assignee: Eduard Rakhmankulov > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Assignee: Eduard Rakhmankulov >Priority: Minor > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most > part of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Rakhmankulov updated IGNITE-14728: - Description: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. The next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. # If there is no value, then the old system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. # If a system property is not defined then the default value from java will be written to DMS (*500*). Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. was: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. Next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. If there are no value, then old system property > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Priority: Minor > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most > part of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Rakhmankulov updated IGNITE-14728: - Description: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. Next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. If there are no value, then old system property > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Priority: Minor > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most part > of users. > I propose the creation of a new DMS property *wal.rebalance.threshold* > instead of a system property. > Next algorithm will be used: > # On node start *wal.rebalance.threshold* property will be checked. If there > are no value, then old system property -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
Eduard Rakhmankulov created IGNITE-14728: Summary: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property Key: IGNITE-14728 URL: https://issues.apache.org/jira/browse/IGNITE-14728 Project: Ignite Issue Type: Improvement Reporter: Eduard Rakhmankulov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14723) Add CLI command to restore a cache group from the snapshot.
[ https://issues.apache.org/jira/browse/IGNITE-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-14723: - Assignee: Pavel Pereslegin > Add CLI command to restore a cache group from the snapshot. > --- > > Key: IGNITE-14723 > URL: https://issues.apache.org/jira/browse/IGNITE-14723 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.11 > > > Add CLI command to restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14553) Calcite engine. Duplicated result on insert
[
https://issues.apache.org/jira/browse/IGNITE-14553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345992#comment-17345992
]
Konstantin Orlov commented on IGNITE-14553:
---
[~alex_pl], I've added more tests and apply tree rewriting to an UPDATE too.
> Calcite engine. Duplicated result on insert
> ---
>
> Key: IGNITE-14553
> URL: https://issues.apache.org/jira/browse/IGNITE-14553
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Please see the test
> {{modules/calcite/src/test/sql/types/string/test_scan_big_varchar.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14727) SSL test should work with custom persistance root
Mikhail Filatov created IGNITE-14727: Summary: SSL test should work with custom persistance root Key: IGNITE-14727 URL: https://issues.apache.org/jira/browse/IGNITE-14727 Project: Ignite Issue Type: Task Reporter: Mikhail Filatov Assignee: Mikhail Filatov In test modules/ducktests/tests/ignitetest/tests/ssl_test.py we have hard-coded path to the folder with certificates. A situation when this folder does not exist is possible . We should get a folder through globals in this test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14720) Remove warning about disabling explicit GC
[
https://issues.apache.org/jira/browse/IGNITE-14720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345965#comment-17345965
]
Ilya commented on IGNITE-14720:
---
[~ilyak] please take a look to dev list
[discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Proposal-to-remove-explicit-quot-GC-disable-quot-startup-suggestion-td52624.html].
I assume that we can move forward.
> Remove warning about disabling explicit GC
> --
>
> Key: IGNITE-14720
> URL: https://issues.apache.org/jira/browse/IGNITE-14720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Ilya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now we suggest the following
> {code:java}
> INFO: ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options){code}
> It does not make sense anymore (people don't call gc() when not needed) and
> may actually prevent JVM from reclaiming heap and the failing due to running
> out of direct memory buffers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14720) Remove warning about disabling explicit GC
[
https://issues.apache.org/jira/browse/IGNITE-14720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345961#comment-17345961
]
Ignite TC Bot commented on IGNITE-14720:
{panel:title=Branch: [pull/9096/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9096/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6007697buildTypeId=IgniteTests24Java8_RunAll]
> Remove warning about disabling explicit GC
> --
>
> Key: IGNITE-14720
> URL: https://issues.apache.org/jira/browse/IGNITE-14720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Pligin
>Assignee: Ilya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now we suggest the following
> {code:java}
> INFO: ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options){code}
> It does not make sense anymore (people don't call gc() when not needed) and
> may actually prevent JVM from reclaiming heap and the failing due to running
> out of direct memory buffers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14726) [Log4j2] Omitted start character [ in default log pattern
Fedor Malchikov created IGNITE-14726:
-
Summary: [Log4j2] Omitted start character [ in default log pattern
Key: IGNITE-14726
URL: https://issues.apache.org/jira/browse/IGNITE-14726
Project: Ignite
Issue Type: Bug
Components: extensions
Affects Versions: 2.10
Reporter: Fedor Malchikov
{code:java}.withPattern("%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
should be:
{code:java}.withPattern("[%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
code:
https://github.com/apache/ignite/blob/master/modules/log4j2/src/main/java/org/apache/ignite/logger/log4j2/Log4J2Logger.java#L363
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345951#comment-17345951
]
Ignite TC Bot commented on IGNITE-12911:
{panel:title=Branch: [pull/7742/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/7742/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache (Restarts) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5992993]]
* {color:#013220}IgniteCacheRestartTestSuite2:
IgniteCachePutKeyAttachedBinaryObjectTest.testAttachedBinaryKeyStoredSuccessfullyToNotEmptyCache
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6001357buildTypeId=IgniteTests24Java8_RunAll]
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Assignee: Sergey Chugunov
>Priority: Blocker
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
>
[jira] [Updated] (IGNITE-14725) Cluster crashes when the client has a higher byte code version than server
[
https://issues.apache.org/jira/browse/IGNITE-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Surkov Aleksandr updated IGNITE-14725:
--
Description:
When the version of byte code on server(1.8) is older than on the client(11),
then some operations can lead to the fall of the cluster.
Reproducer is attached. Logs from the server and client are located in the
_errors_ folder.
Steps to reproduce the situation:
1. Start the server using Java 8(target byte code version
8)(org.apache.ignite.SimpleServer#main)
2. Start the client using Java 11(target byte code version 11), which will run
ScanQuery(org.apache.ignite.ThickClient#main)
{code:java}
SEVERE: Failed to process message
[senderId=53c4266d-8b74-480b-bbf5-670bd94c4192, msg=GridCacheQueryRequest
[id=13, cacheName=cache_scan, type=SCAN, fields=false, clause=null, limit=0,
clsName=null, keyValFilter=null, rdc=null, trans=null, pageSize=1024,
incBackups=false, cancel=false, incMeta=false, all=false, keepBinary=false,
subjId=53c4266d-8b74-480b-bbf5-670bd94c4192, taskHash=0, part=-1,
topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], mvccSnapshot=null,
flags=0, super=GridCacheIdMessage [cacheId=29045018, super=GridCacheMessage
[msgId=14, depInfo=GridDeploymentInfoBean
[clsLdrId=74845d87971-53c4266d-8b74-480b-bbf5-670bd94c4192, depMode=SHARED,
userVer=0, locDepOwner=false, participants=null],
lastAffChangedTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1],
err=null, skipPrepare=false
java.lang.UnsupportedClassVersionError: org/apache/ignite/ThickClient has been
compiled by a more recent version of the Java Runtime (class file version
55.0), this version of the Java Runtime only recognizes class file versions up
to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:543)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:461)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9014)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8945)
at
org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:460)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:441)
at
org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:517)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.tryToloadClassFromCacheDep(GridCacheDeploymentManager.java:816)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.findClass(GridCacheDeploymentManager.java:783)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.loadClass(GridCacheDeploymentManager.java:760)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9012)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8957)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:376)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:693)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1641)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1578)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1555)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:383)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:907)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:932)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1769)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1721)
at
[jira] [Updated] (IGNITE-14725) Cluster crashes when the client has a higher byte code version than server
[ https://issues.apache.org/jira/browse/IGNITE-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Surkov Aleksandr updated IGNITE-14725: -- Summary: Cluster crashes when the client has a higher byte code version than server (was: Different versions of Java on client and server) > Cluster crashes when the client has a higher byte code version than server > -- > > Key: IGNITE-14725 > URL: https://issues.apache.org/jira/browse/IGNITE-14725 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Surkov Aleksandr >Priority: Major > Attachments: different-java.zip > > > When the version of Java on server(1.8) is older than on the client(11), then > some operations can lead to the fall of the cluster. > Reproducer is attached. Logs from the server and client are located in the > _errors_ folder. > Steps to reproduce the situation: > 1. Start the server using Java 8(org.apache.ignite.SimpleServer#main) > 2. Start the client using Java 11, which will run > ScanQuery(org.apache.ignite.ThickClient#main) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14724) Calcite engine. Create table with DATE column creates INTEGER column
[
https://issues.apache.org/jira/browse/IGNITE-14724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-14724:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Create table with DATE column creates INTEGER column
>
>
> Key: IGNITE-14724
> URL: https://issues.apache.org/jira/browse/IGNITE-14724
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t(d DATE)", true);
> sql("INSERT INTO t VALUES (date '2021-01-01')", true);
> {code}
> Fails with:
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Cannot assign to target field 'D' of type INTEGER from source field 'DATE
> '2021-01-01'' of type DATE{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17345889#comment-17345889 ] Stanilovsky Evgeny commented on IGNITE-8719: [~ktkale...@gridgain.com] plz check one more comment from my side, overall looks good. > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexey Goncharuk >Assignee: Kirill Tkalenko >Priority: Critical > Fix For: 2.11 > > Attachments: IndexRebuildAfterNodeCrashTest.java, > IndexRebuildingTest.java > > Time Spent: 3h 50m > Remaining Estimate: 0h > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
