[jira] [Commented] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044041#comment-16044041
]
Roman Shtykh commented on IGNITE-4431:
--
TC looks good (errors are only on timeout and flaky tests).
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043923#comment-16043923
]
Roman Shtykh commented on IGNITE-4431:
--
[~kuaw26] Can you please review this change? It also changes log4j configs in
visor and webconsole, so it would be nice if you have a look.
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043851#comment-16043851
]
Roman Shtykh edited comment on IGNITE-4431 at 6/9/17 4:07 AM:
--
+1 for ISO8601.
It would be particularly useful for long-running evaluation tests when users
don't care about changing log settings.
was (Author: roman_s):
+1 for ISO8601.
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043873#comment-16043873
]
ASF GitHub Bot commented on IGNITE-4431:
GitHub user shroman opened a pull request:
https://github.com/apache/ignite/pull/2109
IGNITE-4431: Include date into the default format of the ignite log.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shroman/ignite IGNITE-4431
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2109.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2109
commit de9afe8c9642616fadf29c9fabf3743a0b34bd10
Author: shroman
Date: 2017-06-09T03:28:12Z
IGNITE-4431: Include date into the default format of the ignite log.
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-5415) Web console: Implement support of 2.1 configuration version.
[ https://issues.apache.org/jira/browse/IGNITE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043862#comment-16043862 ] Vasiliy Sisko edited comment on IGNITE-5415 at 6/9/17 3:24 AM: --- Updated configuration generation to version 2.1 Added: Cache -> groupName Cluster -> Atomic configuration -> Affinity function. Cluster -> ODBC -> Missed fields for version 1.x, 2.0 Cluster -> Memory configuration -> Memory policies -> subIntervals and rateTimeInterval Cluster -> Sql connector configuration (Query configuration section). Cluster -> Persistence store configuration Removed: Cache -> longQueryWarningTimeout Cluster -> ODBC Additionally to check cache Affinity function was (Author: vsisko): Updated configuration generation to version 2.1 Added: Cache -> groupName Cluster -> Atomic configuration -> Affinity function. Cluster -> ODBC -> Missed fields for version 1.x, 2.0 Cluster -> Memory configuration -> Memory policies -> subIntervals and rateTimeInterval Cluster -> Sql connector configuration (Query configuration section). Cluster -> Persistence store configuration Removed: Cache -> longQueryWarningTimeout Cluster -> ODBC > Web console: Implement support of 2.1 configuration version. > > > Key: IGNITE-5415 > URL: https://issues.apache.org/jira/browse/IGNITE-5415 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.0 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-5415) Web console: Implement support of 2.1 configuration version.
[ https://issues.apache.org/jira/browse/IGNITE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-5415: - Assignee: Andrey Novikov (was: Vasiliy Sisko) > Web console: Implement support of 2.1 configuration version. > > > Key: IGNITE-5415 > URL: https://issues.apache.org/jira/browse/IGNITE-5415 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.0 >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5415) Web console: Implement support of 2.1 configuration version.
[ https://issues.apache.org/jira/browse/IGNITE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043862#comment-16043862 ] Vasiliy Sisko commented on IGNITE-5415: --- Updated configuration generation to version 2.1 Added: Cache -> groupName Cluster -> Atomic configuration -> Affinity function. Cluster -> ODBC -> Missed fields for version 1.x, 2.0 Cluster -> Memory configuration -> Memory policies -> subIntervals and rateTimeInterval Cluster -> Sql connector configuration (Query configuration section). Cluster -> Persistence store configuration Removed: Cache -> longQueryWarningTimeout Cluster -> ODBC > Web console: Implement support of 2.1 configuration version. > > > Key: IGNITE-5415 > URL: https://issues.apache.org/jira/browse/IGNITE-5415 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 2.0 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043851#comment-16043851
]
Roman Shtykh commented on IGNITE-4431:
--
+1 for ISO8601.
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (IGNITE-5368) Cassandra store should support private/public fields serialization for POJO persistence strategy
[ https://issues.apache.org/jira/browse/IGNITE-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Rudyak closed IGNITE-5368. --- > Cassandra store should support private/public fields serialization for POJO > persistence strategy > > > Key: IGNITE-5368 > URL: https://issues.apache.org/jira/browse/IGNITE-5368 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Reporter: Igor Rudyak >Assignee: Igor Rudyak > > As for now for POJO persistence strategy, Cassandra cache store supports only > java classes following JavaBeans convention (having getters & setters). > It should also support serialization/deserialization for public/private class > fields which are not following JavaBeans convention but: > - Annotated with @QuerySqlField and @AffinityKeyMapped > - Manually specified in persistence descriptor -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5368) Cassandra store should support private/public fields serialization for POJO persistence strategy
[ https://issues.apache.org/jira/browse/IGNITE-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043848#comment-16043848 ] Igor Rudyak commented on IGNITE-5368: - Reviewed and merged to master. > Cassandra store should support private/public fields serialization for POJO > persistence strategy > > > Key: IGNITE-5368 > URL: https://issues.apache.org/jira/browse/IGNITE-5368 > Project: Ignite > Issue Type: Improvement > Components: cassandra >Reporter: Igor Rudyak >Assignee: Igor Rudyak > > As for now for POJO persistence strategy, Cassandra cache store supports only > java classes following JavaBeans convention (having getters & setters). > It should also support serialization/deserialization for public/private class > fields which are not following JavaBeans convention but: > - Annotated with @QuerySqlField and @AffinityKeyMapped > - Manually specified in persistence descriptor -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4431) Default format of the ignite log doesn't contain a date.
[
https://issues.apache.org/jira/browse/IGNITE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh reassigned IGNITE-4431:
Assignee: Roman Shtykh
> Default format of the ignite log doesn't contain a date.
>
>
> Key: IGNITE-4431
> URL: https://issues.apache.org/jira/browse/IGNITE-4431
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Taras Ledkov
>Assignee: Roman Shtykh
> Fix For: 2.1
>
>
> Ignite uses the default pattern layout for the log4j loggers with the
> {{ABSOLUTE}} date format.
> May be the {{ISO8601}} for default is more useful because {{ABSOLUTE}}
> doesn't contain date.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-5457:
--
Description:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by connect
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
connect timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
Number of nodes is same as before kick attempt.
was:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by connect
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
connect timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node wil
[jira] [Comment Edited] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[ https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043237#comment-16043237 ] Sergey Kalashnikov edited comment on IGNITE-5204 at 6/8/17 6:54 PM: Reproduced with attached java test. Just added 'ccfg.setSqlIndexMaxInlineSize(4)' line to my initial java test. was (Author: skalashnikov): Reproduced > The Unicode character in the value of a field which are included in an > un-unique index will cause "stack overhead" exception > > > Key: IGNITE-5204 > URL: https://issues.apache.org/jira/browse/IGNITE-5204 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.0 > Environment: windows server 2012, JDK 1.8, X64 >Reporter: Chris Wang >Assignee: Sergey Kalashnikov >Priority: Critical > Fix For: 2.1 > > Attachments: IgniteSqlIssue5204Test.java > > > When put "草DX009090" as the value of BillId, which is a field of entity > Bill. If I define a index includes the BillId, and execute the query like > "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there > throws an exception by the H2 with a code 5000. > another scenario is, I have two entities, "Bill" and "Detail", both have > field "BillId". If either of them have value like "草DX009090" and execute the > query like "select bill.* from bill left join detail on > bill.billid=detail.billid", the whole ignite cache node will halt ( suppose > there should be an stack overhead exception, dead loop). > == > I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[ https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov updated IGNITE-5204: --- Attachment: IgniteSqlIssue5204Test.java Reproduced > The Unicode character in the value of a field which are included in an > un-unique index will cause "stack overhead" exception > > > Key: IGNITE-5204 > URL: https://issues.apache.org/jira/browse/IGNITE-5204 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.0 > Environment: windows server 2012, JDK 1.8, X64 >Reporter: Chris Wang >Assignee: Sergey Kalashnikov >Priority: Critical > Fix For: 2.1 > > Attachments: IgniteSqlIssue5204Test.java > > > When put "草DX009090" as the value of BillId, which is a field of entity > Bill. If I define a index includes the BillId, and execute the query like > "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there > throws an exception by the H2 with a code 5000. > another scenario is, I have two entities, "Bill" and "Detail", both have > field "BillId". If either of them have value like "草DX009090" and execute the > query like "select bill.* from bill left join detail on > bill.billid=detail.billid", the whole ignite cache node will halt ( suppose > there should be an stack overhead exception, dead loop). > == > I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5170) .NET: Compute peer deployment example
[ https://issues.apache.org/jira/browse/IGNITE-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043163#comment-16043163 ] Denis Magda commented on IGNITE-5170: - [~ptupitsyn], thanks! Please see minor documentation related notes from me in the pull-request. > .NET: Compute peer deployment example > - > > Key: IGNITE-5170 > URL: https://issues.apache.org/jira/browse/IGNITE-5170 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.1 > > > * Add example for IGNITE-2492. > * Enable peer loading in LINQPad compute example so it works with a > standalone node (update docs there), explain how to run Apache.Ignite.exe > from NuGet -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043092#comment-16043092
]
Yakov Zhdanov commented on IGNITE-5457:
---
[~agura] can you please take a look at this?
> Weird discovery behavior on split brain.
>
>
> Key: IGNITE-5457
> URL: https://issues.apache.org/jira/browse/IGNITE-5457
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Priority: Critical
> Fix For: 2.2
>
>
> I observe buggy behavior in case of simulated split brain.
> Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
> while nodes in DataCenter2 stay in grid forever.
> In logs I see multiple attemps to kick coordinator by communcation by connect
> timeout, but number of nodes does not change.
> Note what my failureDetectionTimeout is significantly higher than
> communication connect timeout.
> Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
> {noformat}
> 19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
> out (consider increasing 'connTimeout' configuration property)
> [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
> 19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
> TcpCommunicationSpi failed to establish connection to node, node will be
> dropped from cluster [rmtNode=TcpDiscoveryNode
> [id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
> sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1496936257121, loc=false,
> ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
> org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
> still alive?). Make sure that each ComputeTask and cache Transaction has a
> timeout set in order to prevent parties from waiting forever in case of
> network issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
> addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
> to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
> [ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
> ... 6 common frames omitted
> Caused by: java.net.SocketTimeoutException: null
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
> ... 6 common frames omitted
> 19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
> ^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
> ^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
> ^-- PageMemory [pages=604144]
> ^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
> ^-- Non heap [used=171MB, free=-1%, comm=173MB]
> ^-- Public thread pool [active=0, idle=0, qSize=0]
> ^-- System thread pool [active=0, idle=0, qSize=0]
> ^-- Outbound messages queue [size=0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5437) SQL: Incorrect partition is derived from query when argument type differs from column type
[ https://issues.apache.org/jira/browse/IGNITE-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043019#comment-16043019 ] Sergey Kalashnikov commented on IGNITE-5437: [~vozerov], Could you please review the changes? Tests look good. > SQL: Incorrect partition is derived from query when argument type differs > from column type > -- > > Key: IGNITE-5437 > URL: https://issues.apache.org/jira/browse/IGNITE-5437 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.1 > > Attachments: BugReproducer5437.java > > > Ignite SQL attempts to derive partition from the query in certain cases and > sends the map queries only to nodes which have those calculated partitions. > Such queries are limited to contain equality conditions over key or affinity > key columns at the left and constant or parameter at the right. > When the type of argument does not match the column type, the calculation > leads to wrong result. > For example, the following query produces incomplete results when _key column > is INTEGER and the argument is CHAR. > select * from test where _key = ? > However, this is valid and resultive query for H2, which does implicit > conversion in such cases. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-5457:
--
Description:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by connect
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
connect timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
was:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
socket timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNod
[jira] [Updated] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-5457:
--
Description:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
socket timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
was:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
socket timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:13:53.978 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=131ms, reason='timeout']
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout
[jira] [Updated] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-5457:
--
Description:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
Note what my failureDetectionTimeout is significantly higher than communication
socket timeout.
Looks like coordinator cannot be kicked from topology by TcpCommuncationSpi.
{noformat}
19:13:53.978 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=131ms, reason='timeout']
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:23.989 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=130ms, reason='timeout']
19:14:34.078 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=211ms, reason='timeout']
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
was:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
[jira] [Updated] (IGNITE-5457) Weird discovery behavior on split brain.
[
https://issues.apache.org/jira/browse/IGNITE-5457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-5457:
--
Description:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see multiple attemps to kick coordinator by communcation by socket
timeout, but number of nodes does not change.
{noformat}
19:13:53.978 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=131ms, reason='timeout']
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:23.989 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=130ms, reason='timeout']
19:14:34.078 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=211ms, reason='timeout']
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
was:
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see attempts multiple attemps to kick coordinator by communcation by
socket timeout, but number of nodes does not change.
{noformat}
19:13:53.978 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpoin
[jira] [Created] (IGNITE-5457) Weird discovery behavior on split brain.
Alexei Scherbakov created IGNITE-5457:
-
Summary: Weird discovery behavior on split brain.
Key: IGNITE-5457
URL: https://issues.apache.org/jira/browse/IGNITE-5457
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.0
Reporter: Alexei Scherbakov
Priority: Critical
Fix For: 2.2
I observe buggy behavior in case of simulated split brain.
Nodes in DataCenter1 (where coordinator is located) are slowly leave grid,
while nodes in DataCenter2 stay in grid forever.
In logs I see attempts multiple attemps to kick coordinator by communcation by
socket timeout, but number of nodes does not change.
{noformat}
19:13:53.978 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=131ms, reason='timeout']
19:14:03.289 [WARN ] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] - Connect timed
out (consider increasing 'connTimeout' configuration property)
[addr=grid457.ca.sbrf.ru/10.116.206.193:47100, connTimeout=12]
19:14:03.289 [ERROR] [o.a.i.s.c.tcp.TcpCommunicationSpi] [T:] -
TcpCommunicationSpi failed to establish connection to node, node will be
dropped from cluster [rmtNode=TcpDiscoveryNode
[id=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb, addrs=[10.116.206.193],
sockAddrs=[grid457.ca.sbrf.ru/10.116.206.193:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1496936257121, loc=false,
ver=1.10.3#20170604-sha1:30521a17, isClient=false]]
org.apache.ignite.IgniteCheckedException: Failed to connect to node (is node
still alive?). Make sure that each ComputeTask and cache Transaction has a
timeout set in order to prevent parties from waiting forever in case of network
issues [nodeId=a8ac1b24-8377-4064-a3d9-02bad9c6f2bb,
addrs=[grid457.ca.sbrf.ru/10.116.206.193:47100]]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3022)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2636)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2528)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$5800(TcpCommunicationSpi.java:245)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.processDisconnect(TcpCommunicationSpi.java:3830)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$CommunicationWorker.body(TcpCommunicationSpi.java:3656)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
Suppressed: org.apache.ignite.IgniteCheckedException: Failed to connect
to address [addr=grid457.ca.sbrf.ru/10.116.206.193:47100, err=null]
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3027)
[ignite-core-1.10.3.ea10.jar:1.10.3.ea10]
... 6 common frames omitted
Caused by: java.net.SocketTimeoutException: null
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:118)
at
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:2884)
... 6 common frames omitted
19:14:23.989 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=130ms, reason='timeout']
19:14:34.078 [INFO ] [o.g.g.i.p.c.d.GridCacheDatabaseSharedManager] [T:] -
Skipping checkpoint (no pages were modified) [checkpointLockWait=0ms,
checkpointLockHoldTime=211ms, reason='timeout']
19:14:37.967 [INFO ] [o.a.i.i.IgniteKernal%DPL_GRID%grid880] [T:] -
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=21e01ea7, name=DPL_GRID%grid880, uptime=00:37:00:200]
^-- H/N/C [hosts=144, nodes=160, CPUs=8064]
^-- CPU [cur=0.2%, avg=2.37%, GC=0%]
^-- PageMemory [pages=604144]
^-- Heap [used=33396MB, free=49.04%, comm=65536MB]
^-- Non heap [used=171MB, free=-1%, comm=173MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=0, qSize=0]
^-- Outbound messages queue [size=0]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5455) .NET: Incorrect binary object hash code calculation
[
https://issues.apache.org/jira/browse/IGNITE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042971#comment-16042971
]
Pavel Tupitsyn commented on IGNITE-5455:
Fixed, improved tests, waiting for TC:
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2108%2Fhead
> .NET: Incorrect binary object hash code calculation
> ---
>
> Key: IGNITE-5455
> URL: https://issues.apache.org/jira/browse/IGNITE-5455
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.1
>
>
> Hash code is calculated over binary object data with the following code in
> Java and .NET:
> {code}
> for (int i = start; i <= end; i++)
> hash = 31 * hash + data[i];
> {code}
> Where {{data}} is {{byte[]}} in Java and .NET.
> And {{byte}} is signed in Java and unsigned in .NET.
> So in our simple tests on small values it works, but fails on real world data.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5455) .NET: Incorrect binary object hash code calculation
[
https://issues.apache.org/jira/browse/IGNITE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042956#comment-16042956
]
ASF GitHub Bot commented on IGNITE-5455:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/2108
IGNITE-5455 .NET: Fix binary hash code calculation
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-5455
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2108.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2108
commit df1e9d6431a2e9fb61789b3c56c1c9b5d3fc114a
Author: Pavel Tupitsyn
Date: 2017-06-08T14:36:54Z
wip
commit 8da992f3fdbbbfd536d042c4d2dcfa709cddd1e6
Author: Pavel Tupitsyn
Date: 2017-06-08T14:37:59Z
wip
commit 8ddbf99b7b1c2d26d208bc1bdf1ca45591736f1d
Author: Pavel Tupitsyn
Date: 2017-06-08T14:40:08Z
wip
commit 1af859b04b81ef1a9c4daa776c8d5e98df125144
Author: Pavel Tupitsyn
Date: 2017-06-08T15:16:07Z
fix hash code computation and tests
commit d3fb2c47005231cbdcc4860718b218f2af4bf1f6
Author: Pavel Tupitsyn
Date: 2017-06-08T15:22:21Z
wip
commit 19775feb0c5ab56033f8dffc45b74fd7b48738ef
Author: Pavel Tupitsyn
Date: 2017-06-08T15:24:22Z
wip
commit 845dd12c47fac9caff5a4ba170fae11725d752eb
Author: Pavel Tupitsyn
Date: 2017-06-08T15:56:58Z
Improving tests
commit d6cc6d13cf485f2d5f4d0e146ccdadca096dd1dd
Author: Pavel Tupitsyn
Date: 2017-06-08T16:01:51Z
wip
commit 393b946a0a344ab853407005552b5ecba1e08ad3
Author: Pavel Tupitsyn
Date: 2017-06-08T16:02:46Z
wip tests
commit c090323b4f819b68b3ba20a008763a2d654af88e
Author: Pavel Tupitsyn
Date: 2017-06-08T16:07:53Z
wip
commit 29f3024b681a615715e46aaf0c08b052f1b7e8cd
Author: Pavel Tupitsyn
Date: 2017-06-08T16:08:36Z
wip tests
commit f8e76ae370692f45a98a9ceaf1180fc8d90d3160
Author: Pavel Tupitsyn
Date: 2017-06-08T16:14:39Z
Adding tests
> .NET: Incorrect binary object hash code calculation
> ---
>
> Key: IGNITE-5455
> URL: https://issues.apache.org/jira/browse/IGNITE-5455
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.1
>
>
> Hash code is calculated over binary object data with the following code in
> Java and .NET:
> {code}
> for (int i = start; i <= end; i++)
> hash = 31 * hash + data[i];
> {code}
> Where {{data}} is {{byte[]}} in Java and .NET.
> And {{byte}} is signed in Java and unsigned in .NET.
> So in our simple tests on small values it works, but fails on real world data.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization
[ https://issues.apache.org/jira/browse/IGNITE-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042952#comment-16042952 ] Vladislav Pyatkov commented on IGNITE-5038: --- [~vozerov] I have added some changes and think that will not leaking already. Please, view latest commit into the PR. > BinaryMarshaller might need to use context class loader for deserialization > --- > > Key: IGNITE-5038 > URL: https://issues.apache.org/jira/browse/IGNITE-5038 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Vladislav Pyatkov > Labels: features > Fix For: 2.1 > > > There is a special use case discussed on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224 > According to the use case, BinaryMarshaller might need to try to deserialize > an object using a context class loader if it failed to do so with a custom > classloader (`IgniteConfiguration.getClassLoader()`) or the system one. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-2202) Local server query result doesn't include versions in entries
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2202: Fix Version/s: (was: 2.1) 2.3 > Local server query result doesn't include versions in entries > - > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Minor > Labels: important > Fix For: 2.3 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-2202) Local server query result doesn't include versions in entries
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042921#comment-16042921 ] Denis Magda commented on IGNITE-2202: - Moved to 2.3 > Local server query result doesn't include versions in entries > - > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Minor > Labels: important > Fix For: 2.3 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[ https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042917#comment-16042917 ] Denis Magda commented on IGNITE-5204: - [~sergi.vladykin], [~vozerov], [~al.psc], please have a look. > The Unicode character in the value of a field which are included in an > un-unique index will cause "stack overhead" exception > > > Key: IGNITE-5204 > URL: https://issues.apache.org/jira/browse/IGNITE-5204 > Project: Ignite > Issue Type: Bug > Components: cache, sql >Affects Versions: 2.0 > Environment: windows server 2012, JDK 1.8, X64 >Reporter: Chris Wang >Assignee: Sergey Kalashnikov >Priority: Critical > Fix For: 2.1 > > > When put "草DX009090" as the value of BillId, which is a field of entity > Bill. If I define a index includes the BillId, and execute the query like > "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there > throws an exception by the H2 with a code 5000. > another scenario is, I have two entities, "Bill" and "Detail", both have > field "BillId". If either of them have value like "草DX009090" and execute the > query like "select bill.* from bill left join detail on > bill.billid=detail.billid", the whole ignite cache node will halt ( suppose > there should be an stack overhead exception, dead loop). > == > I think the issue should relate to hash computing on the unicode character. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5456) JDBC thin driver: the statement produces multiple result sets must be handled correct
Taras Ledkov created IGNITE-5456:
Summary: JDBC thin driver: the statement produces multiple result
sets must be handled correct
Key: IGNITE-5456
URL: https://issues.apache.org/jira/browse/IGNITE-5456
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Fix For: 2.2
Now the SQL query statement that produces is failed with:
{code}
[18:53:56,231][ERROR][sql-connector-#81%thin.JdbcThinStatementFullApiSelfTest0%][SqlListenerProcessor]
Runtime error caught during grid runnable execution: GridWorker
[name=message-received-notify,
igniteInstanceName=thin.JdbcThinStatementFullApiSelfTest0, finished=false,
hashCode=841829578, interrupted=false,
runner=sql-connector-#81%thin.JdbcThinStatementFullApiSelfTest0%]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.prepared(GridSqlQueryParser.java:435)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1298)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1834)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1830)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2271)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1838)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
at
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
at
org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
at
org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
This case must be handled and appropriate exception will be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5455) .NET: Incorrect binary object hash code calculation
Pavel Tupitsyn created IGNITE-5455:
--
Summary: .NET: Incorrect binary object hash code calculation
Key: IGNITE-5455
URL: https://issues.apache.org/jira/browse/IGNITE-5455
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
Fix For: 2.1
Hash code is calculated over binary object data with the following code in Java
and .NET:
{code}
for (int i = start; i <= end; i++)
hash = 31 * hash + data[i];
{code}
Where {{data}} is {{byte[]}} in Java and .NET.
And {{byte}} is signed in Java and unsigned in .NET.
So in our simple tests on small values it works, but fails on real world data.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5454) Tree is being concurrently destroyed error
Konstantin Dudkov created IGNITE-5454:
-
Summary: Tree is being concurrently destroyed error
Key: IGNITE-5454
URL: https://issues.apache.org/jira/browse/IGNITE-5454
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Dudkov
Assignee: Konstantin Dudkov
{code}
Caused by: java.lang.IllegalStateException: Tree is being concurrently
destroyed: p-305##CacheData
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.checkDestroyed(BPlusTree.java:928)
at
org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.find(BPlusTree.java:949)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1328)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1308)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.cursor(IgniteCacheOffheapManagerImpl.java:1302)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$6.onHasNext(IgniteCacheOffheapManagerImpl.java:619)
at
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.clearCache(IgniteCacheOffheapManagerImpl.java:432)
at
org.apache.ignite.internal.processors.cache.GridCacheClearAllRunnable.run(GridCacheClearAllRunnable.java:85)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.clearLocally(GridCacheAdapter.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.clearLocally(GridCacheProxyImpl.java:977)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$GlobalClearAllJob.localExecute(GridCacheAdapter.java:5136)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5306) Make sure that SQL context is persisted along with cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5306:
Labels: important (was: )
> Make sure that SQL context is persisted along with cache configuration
> --
>
> Key: IGNITE-5306
> URL: https://issues.apache.org/jira/browse/IGNITE-5306
> Project: Ignite
> Issue Type: Task
> Components: cache, persistence, sql
>Reporter: Vladimir Ozerov
>Assignee: Konstantin Dudkov
> Labels: important
> Fix For: 2.1
>
>
> This ticket should be implemented after IGNITE-5242 is ready. When we create
> cache using {{CREATE TABLE}} command, we set special {{sql}} flag to
> {{DynamicCacheDescriptor}}. This flag controls whether this cache can be
> dropped through {{DROP TABLE}} command or not.
> When persisting cache configuration we should also persist this flag, and
> restore it afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4651) Support CREATE TABLE and DROP TABLE commands
[
https://issues.apache.org/jira/browse/IGNITE-4651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-4651.
-
Resolution: Fixed
> Support CREATE TABLE and DROP TABLE commands
>
>
> Key: IGNITE-4651
> URL: https://issues.apache.org/jira/browse/IGNITE-4651
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Vladimir Ozerov
> Labels: important
> Fix For: 2.1
>
>
> This is an umbrella ticket for all tasks related to CREATE/DROP TABLE feature.
> Raw design:
> 1) {{CREATE TABLE}} is performed using {{createCache}}, {{DROP TABLE}} is
> performed using {{destroyCache}};
> 2) We need to extend H2 parser to support "AFFINITY KEY" attribute;
> 3) Caches will be created based on cache templates defined in
> {{IgniteConfiguration}}. There should be several predefined templates for the
> most common cases (e.g. {{PARTITIONED}}/{{REPLICATED}}). Template will be
> specified using {{WITH}} feature of H2 engine.
> 4) Currently every cache lives inside it's own H2 schema. For user
> convenience we will have to allow different caches to share the same schema.
> 5) Current SQL API are tightly coupled to particular cache. This leads to
> anecdotal situation when you cannot call {{CREATE TABLE}} on a cluster
> without caches. For this reason we will need better SQL API which is not
> bound to any cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5431) Better exception message when SQL cache flag doesn't match
[
https://issues.apache.org/jira/browse/IGNITE-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5431:
Labels: important (was: )
> Better exception message when SQL cache flag doesn't match
> --
>
> Key: IGNITE-5431
> URL: https://issues.apache.org/jira/browse/IGNITE-5431
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Labels: important
> Fix For: 2.1
>
>
> SQL flag configuration check is performed in
> {{ClusterCachesInfo>checkCache}}. Default validation mechanics is used and
> the following error message appears:
> {code}
> SQL flag mismatch (fix sql flag in cache configuration or set
> -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property)
> [cacheName=SQL_PUBLIC_Person, localSql=false, remoteSql=true,
> rmtNodeId=b975316b-ad6a-4f64-b8a4-9eaac642]
> {code}
> Apparently, it is misleading because there is no such config property. Need
> to fix that and make sure that
> {{DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK}} has no effect on this check.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5412) JDBC thin driver: review ResultSetMetadata implementation
[ https://issues.apache.org/jira/browse/IGNITE-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5412: Issue Type: Task (was: Bug) > JDBC thin driver: review ResultSetMetadata implementation > - > > Key: IGNITE-5412 > URL: https://issues.apache.org/jira/browse/IGNITE-5412 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov > Labels: important > Fix For: 2.1 > > > 1) Is it correct? > 2) Why do we have muted tests for it? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-4922) JDBC Driver: renew thin client based solution
[ https://issues.apache.org/jira/browse/IGNITE-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-4922. - Resolution: Fixed > JDBC Driver: renew thin client based solution > - > > Key: IGNITE-4922 > URL: https://issues.apache.org/jira/browse/IGNITE-4922 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Denis Magda > Labels: important > Fix For: 2.1 > > > This is a parent ticket for all the activities that are intended to improve > the thin client based implementation of the JDBC driver making it default one. > > Refer to the corresponding discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/jdbc-vs-jdbc2-packages-td14309.html > In a nutshell, depending on a type of a protocol to be used for the next-gen > version the options are the following: > - This type of driver might be a default driver for tools and applications > that don't need transactional support. Existing REST based protocol can be > used for this scenario. > - If we want to support transactions (which is optional at the beginning) > then Yakov solution (see discussion) can be applied. However, it makes sense > to implement it only after MVCC is ready. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5412) JDBC thin driver: review ResultSetMetadata implementation
[ https://issues.apache.org/jira/browse/IGNITE-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5412: Summary: JDBC thin driver: review ResultSetMetadata implementation (was: JDBC thin: review ResultSetMetadata implementation) > JDBC thin driver: review ResultSetMetadata implementation > - > > Key: IGNITE-5412 > URL: https://issues.apache.org/jira/browse/IGNITE-5412 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov > Labels: important > Fix For: 2.1 > > > 1) Is it correct? > 2) Why do we have muted tests for it? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5412) JDBC thin: review ResultSetMetadata implementation
[ https://issues.apache.org/jira/browse/IGNITE-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5412: Labels: important (was: ) > JDBC thin: review ResultSetMetadata implementation > -- > > Key: IGNITE-5412 > URL: https://issues.apache.org/jira/browse/IGNITE-5412 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov > Labels: important > Fix For: 2.1 > > > 1) Is it correct? > 2) Why do we have muted tests for it? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5339) JDBC thin driver: validate compliance
[ https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5339: Summary: JDBC thin driver: validate compliance (was: Thin JDBC driver: validate compliance) > JDBC thin driver: validate compliance > - > > Key: IGNITE-5339 > URL: https://issues.apache.org/jira/browse/IGNITE-5339 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Labels: important > Fix For: 2.1 > > > We need to make sure that all methods of our new driver are compliant with > JDBC spec, namely: > 1) Semantics of normal execution is correct > 2) Exceptions are thrown when excepted > I propose the following flow: > 1) Walk through interface classes (Connection -> Statement, PreparedStatement > -> ResultSet) > 2) For every method identify a set of tests to verify semantics (if any). > 3) Write those tests, even if they fail. > 4) Once all tests are ready, decide how to proceed with their fixes. > NB: we should write tests even for methods which throw "not-implemented > exception", so that we better understand the scope of remaining work. > Link to [JDBC > specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-4922) JDBC Driver: renew thin client based solution
[ https://issues.apache.org/jira/browse/IGNITE-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-4922: --- Assignee: (was: Vladimir Ozerov) > JDBC Driver: renew thin client based solution > - > > Key: IGNITE-4922 > URL: https://issues.apache.org/jira/browse/IGNITE-4922 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Denis Magda > Labels: important > Fix For: 2.1 > > > This is a parent ticket for all the activities that are intended to improve > the thin client based implementation of the JDBC driver making it default one. > > Refer to the corresponding discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/jdbc-vs-jdbc2-packages-td14309.html > In a nutshell, depending on a type of a protocol to be used for the next-gen > version the options are the following: > - This type of driver might be a default driver for tools and applications > that don't need transactional support. Existing REST based protocol can be > used for this scenario. > - If we want to support transactions (which is optional at the beginning) > then Yakov solution (see discussion) can be applied. However, it makes sense > to implement it only after MVCC is ready. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5339) Thin JDBC driver: validate compliance
[ https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5339: Labels: important (was: ) > Thin JDBC driver: validate compliance > - > > Key: IGNITE-5339 > URL: https://issues.apache.org/jira/browse/IGNITE-5339 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Labels: important > Fix For: 2.1 > > > We need to make sure that all methods of our new driver are compliant with > JDBC spec, namely: > 1) Semantics of normal execution is correct > 2) Exceptions are thrown when excepted > I propose the following flow: > 1) Walk through interface classes (Connection -> Statement, PreparedStatement > -> ResultSet) > 2) For every method identify a set of tests to verify semantics (if any). > 3) Write those tests, even if they fail. > 4) Once all tests are ready, decide how to proceed with their fixes. > NB: we should write tests even for methods which throw "not-implemented > exception", so that we better understand the scope of remaining work. > Link to [JDBC > specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5439:
Fix Version/s: (was: 2.2)
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-5126: --- Assignee: (was: Taras Ledkov) > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.9 >Reporter: Taras Ledkov > > Support batches operations for the thin JDBC driver. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5440) JDBC thin: support SQL escape processing
[
https://issues.apache.org/jira/browse/IGNITE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5440:
Fix Version/s: (was: 2.2)
> JDBC thin: support SQL escape processing
>
>
> Key: IGNITE-5440
> URL: https://issues.apache.org/jira/browse/IGNITE-5440
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The method {{Statement.setEscapeProcessing}} must be supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5453) JDBC thin: add "application" parameter to connection string.
Vladimir Ozerov created IGNITE-5453: --- Summary: JDBC thin: add "application" parameter to connection string. Key: IGNITE-5453 URL: https://issues.apache.org/jira/browse/IGNITE-5453 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ozerov Many other vendors provide means to assign application name to connection. This is done purely for monitoring purposes. That is, we can see on the server side which application uses the driver. Let's implement the same concept. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5126: Fix Version/s: (was: 2.2) > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > > Support batches operations for the thin JDBC driver. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5260) JDBC thin driver: implement SQLWarning support
[ https://issues.apache.org/jira/browse/IGNITE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5260: Fix Version/s: (was: 2.2) > JDBC thin driver: implement SQLWarning support > -- > > Key: IGNITE-5260 > URL: https://issues.apache.org/jira/browse/IGNITE-5260 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5435) JDBC thin: support statement close on completion
[
https://issues.apache.org/jira/browse/IGNITE-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5435:
Fix Version/s: (was: 2.2)
> JDBC thin: support statement close on completion
>
>
> Key: IGNITE-5435
> URL: https://issues.apache.org/jira/browse/IGNITE-5435
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The methods of JDBC {Statement} must be supported:
> - {{closeOnCompletion(boolean)}};
> - {{isCloseOnCompletion}};
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5234) JDBC thin driver: support connection timeout
[ https://issues.apache.org/jira/browse/IGNITE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5234: Fix Version/s: (was: 2.2) > JDBC thin driver: support connection timeout > > > Key: IGNITE-5234 > URL: https://issues.apache.org/jira/browse/IGNITE-5234 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5426) JDBC thin: support readOnly
[
https://issues.apache.org/jira/browse/IGNITE-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5426:
Fix Version/s: (was: 2.2)
> JDBC thin: support readOnly
> ---
>
> Key: IGNITE-5426
> URL: https://issues.apache.org/jira/browse/IGNITE-5426
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The {{is/setReadOnly}} methods must be supported by the JDBC {{Connection}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5438) JDBC thin: support query timeout
[
https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5438:
Fix Version/s: (was: 2.2)
> JDBC thin: support query timeout
>
>
> Key: IGNITE-5438
> URL: https://issues.apache.org/jira/browse/IGNITE-5438
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5425) JDBC thin: support client info
[
https://issues.apache.org/jira/browse/IGNITE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5425:
Fix Version/s: (was: 2.2)
> JDBC thin: support client info
> --
>
> Key: IGNITE-5425
> URL: https://issues.apache.org/jira/browse/IGNITE-5425
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>
> The methods of JDBC {{Connection}} must be supported:
> - {{setClientInfo(String,String)}};
> - {{getClientInfo(String)}};
> - {{setClientInfo(Properties)}};
> - {{getClientInfo()}};
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-5054) Support SQL schema sharing between different caches
[ https://issues.apache.org/jira/browse/IGNITE-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5054. - Resolution: Fixed > Support SQL schema sharing between different caches > --- > > Key: IGNITE-5054 > URL: https://issues.apache.org/jira/browse/IGNITE-5054 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important > Fix For: 2.1 > > > Current every cache "lives" in it's own schema. We need to allow different > caches to optionally share the same schema. This is an umbrella ticket for > all related activities. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5331) Investigate performance implications of SQL schema refactoring
[
https://issues.apache.org/jira/browse/IGNITE-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5331:
Fix Version/s: (was: 2.1)
2.2
> Investigate performance implications of SQL schema refactoring
> --
>
> Key: IGNITE-5331
> URL: https://issues.apache.org/jira/browse/IGNITE-5331
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> SQL is now decoupled from concrete cache. It means tha:
> 1) Special cache-agnostic implementation {{CacheQueryObjectValueContext}} is
> passed to binary objects, with {{copyOnGet}} always returning true.
> 2) {{GridH2ValueCacheObject.getObject(boolean)}} is now called with {{true}}
> argument more oftner (see usages and Git history).
> All in all it means that more object copying could occur than before. We need
> to understand whether performance is affected.
> One important thing to consider is immutability of binary object. That is,
> once created, {{BinaryObject}} never changes. It means that is
> {{BinaryMarshaller}} is enabled, we can always avoid copying safely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5331) Investigate performance implications of SQL schema refactoring
[
https://issues.apache.org/jira/browse/IGNITE-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5331:
Labels: performance (was: )
> Investigate performance implications of SQL schema refactoring
> --
>
> Key: IGNITE-5331
> URL: https://issues.apache.org/jira/browse/IGNITE-5331
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
> Labels: performance
> Fix For: 2.2
>
>
> SQL is now decoupled from concrete cache. It means tha:
> 1) Special cache-agnostic implementation {{CacheQueryObjectValueContext}} is
> passed to binary objects, with {{copyOnGet}} always returning true.
> 2) {{GridH2ValueCacheObject.getObject(boolean)}} is now called with {{true}}
> argument more oftner (see usages and Git history).
> All in all it means that more object copying could occur than before. We need
> to understand whether performance is affected.
> One important thing to consider is immutability of binary object. That is,
> once created, {{BinaryObject}} never changes. It means that is
> {{BinaryMarshaller}} is enabled, we can always avoid copying safely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5362) Improve test coverage of SQL schema-related changes
[
https://issues.apache.org/jira/browse/IGNITE-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5362:
Labels: important (was: )
> Improve test coverage of SQL schema-related changes
> ---
>
> Key: IGNITE-5362
> URL: https://issues.apache.org/jira/browse/IGNITE-5362
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
> Labels: important
> Fix For: 2.1
>
>
> Use {{SqlPublicSchemaSelfTest}} as a base. What to test:
> 1) Type name conflicts
> 2) Index and table name conflicts
> 3) Cleanup on cache destroy
> 4) Multinode tests
> 5) Different cache modes
> 6) Client and server nodes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-2202) Local server query result doesn't include versions in entries
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042733#comment-16042733 ] Vladimir Ozerov commented on IGNITE-2202: - [~vkulichenko], [~dmagda], same question :-) Can we move it to 2.2? > Local server query result doesn't include versions in entries > - > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Minor > Labels: important > Fix For: 2.1 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5452) Tx with timeout can make node can hang on stop.
[ https://issues.apache.org/jira/browse/IGNITE-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-5452: - Attachment: LockTimeoutFailedOnStop.java > Tx with timeout can make node can hang on stop. > --- > > Key: IGNITE-5452 > URL: https://issues.apache.org/jira/browse/IGNITE-5452 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.0 >Reporter: Andrew Mashenkov > Fix For: 2.1 > > Attachments: LockTimeoutFailedOnStop.java > > > PFA repro attached. > Actually, there are 2 issue. > 1. GridTimeoutProcessor can't be stopped if TimeoutObject eats > InterruptedException. We should handle this correctly. > 2. TX use TimeoutObjects to be rolled back by timeout. However, TXs doesn't > remove their TimeoutObjects on node stop. > Possible, TimeoutObject doesn't removed on TX rollback and this should be > investigated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-3614) Failed test: CacheContinuousQueryFailoverTxReplicatedSelfTest.testUpdatePartitionCounter
[
https://issues.apache.org/jira/browse/IGNITE-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgenii Zhuravlev resolved IGNITE-3614.
---
Resolution: Cannot Reproduce
> Failed test:
> CacheContinuousQueryFailoverTxReplicatedSelfTest.testUpdatePartitionCounter
>
>
> Key: IGNITE-3614
> URL: https://issues.apache.org/jira/browse/IGNITE-3614
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Tikhonov
>Priority: Minor
> Fix For: 2.1
>
>
> Test periodically fail with the following stack trace:
> {code}
> java.lang.Exception: Failed to find a server node.
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryFailoverAbstractSelfTest.testUpdatePartitionCounter(CacheContinuousQueryFailoverAbstractSelfTest.java:390)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Apparently, this is a bug in the test - somehow it cannot return cache
> reliably.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5451) .NET: Improve outer joins in LINQ
[
https://issues.apache.org/jira/browse/IGNITE-5451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042694#comment-16042694
]
Pavel Tupitsyn commented on IGNITE-5451:
{{LeftOuterJoin}} sounds reasonable to me, certainly more readable than
{{GroupJoin}}.
However, I think we should implement {{GroupJoin}} support as well, because
that is what most users would expect. Also some people may be migrating their
queries.
> .NET: Improve outer joins in LINQ
> -
>
> Key: IGNITE-5451
> URL: https://issues.apache.org/jira/browse/IGNITE-5451
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
> Labels: .NET, LINQ
> Fix For: 2.2
>
>
> Currently outer joins are supported in a convoluted way, via a regular join
> with {{DefaultIfEmpty()}} call:
> {code}
> var res = persons.Join(roles.DefaultIfEmpty(),
> person => person.Value.RoleId, role => role.Key,...)
> {code}
> This is not consistent with LINQ to objects, Entity Framework and other
> things out there, and unexpected for the users.
> Instead we should support {{GroupJoin}} properly, see
> https://stackoverflow.com/questions/584820/how-do-you-perform-a-left-outer-join-using-linq-extension-methods
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (IGNITE-5451) .NET: Improve outer joins in LINQ
[
https://issues.apache.org/jira/browse/IGNITE-5451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042690#comment-16042690
]
Sergey Stronchinskiy edited comment on IGNITE-5451 at 6/8/17 1:28 PM:
--
As for me LINQ, method syntax you need to use in EF is too cumbersome, and not
very obvious and I`ve seen some complaints about it.
My proposal would be to add specific LINQ method for {{CacheQueryable}} like
{{LeftOuterJoin(roles, person.Value.RoleId, role => role.Key,...)}}, may be
alongside with implementing handling for {{GroupJoin}} (but not necessarily).
Also argument about LINQ to objects doesn't seem to me very relevant because
LINQ to objects implementation has some design restrictions from language
itself and OOP paradigm, so not all SQL query syntax can be easily made
compliant with it(and our main goal is to generate correct SQL).
was (Author: gurustron):
As for me LINQ method syntax you need to use in EFis too cumbersome, and not
very obvious and I`ve seen some complaints about it My proposal would be to add
specific LINQ method for {{CacheQueryable}} like {{LeftOuterJoin(roles,
person.Value.RoleId, role => role.Key,...)}} may be alongside with implementing
handling for {{GroupJoin}}.
Also argument about LINQ to objects doesn't seem to me very relevant because
LINQ to objects implementation has some design restrictions from language
itself and OOP paradigm, so not all SQL query syntax can be easily made
compliant with it(and our main goal is to generate correct SQL).
> .NET: Improve outer joins in LINQ
> -
>
> Key: IGNITE-5451
> URL: https://issues.apache.org/jira/browse/IGNITE-5451
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
> Labels: .NET, LINQ
> Fix For: 2.2
>
>
> Currently outer joins are supported in a convoluted way, via a regular join
> with {{DefaultIfEmpty()}} call:
> {code}
> var res = persons.Join(roles.DefaultIfEmpty(),
> person => person.Value.RoleId, role => role.Key,...)
> {code}
> This is not consistent with LINQ to objects, Entity Framework and other
> things out there, and unexpected for the users.
> Instead we should support {{GroupJoin}} properly, see
> https://stackoverflow.com/questions/584820/how-do-you-perform-a-left-outer-join-using-linq-extension-methods
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5451) .NET: Improve outer joins in LINQ
[
https://issues.apache.org/jira/browse/IGNITE-5451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042690#comment-16042690
]
Sergey Stronchinskiy commented on IGNITE-5451:
--
As for me LINQ method syntax you need to use in EFis too cumbersome, and not
very obvious and I`ve seen some complaints about it My proposal would be to add
specific LINQ method for {{CacheQueryable}} like {{LeftOuterJoin(roles,
person.Value.RoleId, role => role.Key,...)}} may be alongside with implementing
handling for {{GroupJoin}}.
Also argument about LINQ to objects doesn't seem to me very relevant because
LINQ to objects implementation has some design restrictions from language
itself and OOP paradigm, so not all SQL query syntax can be easily made
compliant with it(and our main goal is to generate correct SQL).
> .NET: Improve outer joins in LINQ
> -
>
> Key: IGNITE-5451
> URL: https://issues.apache.org/jira/browse/IGNITE-5451
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
> Labels: .NET, LINQ
> Fix For: 2.2
>
>
> Currently outer joins are supported in a convoluted way, via a regular join
> with {{DefaultIfEmpty()}} call:
> {code}
> var res = persons.Join(roles.DefaultIfEmpty(),
> person => person.Value.RoleId, role => role.Key,...)
> {code}
> This is not consistent with LINQ to objects, Entity Framework and other
> things out there, and unexpected for the users.
> Instead we should support {{GroupJoin}} properly, see
> https://stackoverflow.com/questions/584820/how-do-you-perform-a-left-outer-join-using-linq-extension-methods
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5383) Do not perform cache key validation when BinaryMarshaller is used
[
https://issues.apache.org/jira/browse/IGNITE-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042685#comment-16042685
]
Vyacheslav Daradur commented on IGNITE-5383:
[~vozerov],
My ci.tests looks good to me, but latest default-build is too old.
I've run the default branch in TC.
([dev.ci.tests|http://ci.ignite.apache.org/viewQueued.html?itemId=654850])
I'll text you later, after their comparison.
> Do not perform cache key validation when BinaryMarshaller is used
> -
>
> Key: IGNITE-5383
> URL: https://issues.apache.org/jira/browse/IGNITE-5383
> Project: Ignite
> Issue Type: Task
> Components: binary, cache
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
> Labels: important
> Fix For: 2.1
>
>
> Currently whenever cache operation is performed, we invoke
> {{GridCacheAdapter.validateCacheKey}} to make sure that key overrides
> {{equals}} and {{hashCode}}.
> This check should not be performed when {{BinaryMarshaller}} is set, since we
> do not use these methods in binary mode.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5452) Tx with timeout can make node can hang on stop.
Andrew Mashenkov created IGNITE-5452: Summary: Tx with timeout can make node can hang on stop. Key: IGNITE-5452 URL: https://issues.apache.org/jira/browse/IGNITE-5452 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.0 Reporter: Andrew Mashenkov Fix For: 2.1 PFA repro attached. Actually, there are 2 issue. 1. GridTimeoutProcessor can't be stopped if TimeoutObject eats InterruptedException. We should handle this correctly. 2. TX use TimeoutObjects to be rolled back by timeout. However, TXs doesn't remove their TimeoutObjects on node stop. Possible, TimeoutObject doesn't removed on TX rollback and this should be investigated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5068) Redesign GridDhtPartitionTopologyImpl.part2node map to store only diff from affinity assignment
[ https://issues.apache.org/jira/browse/IGNITE-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5068: - Fix Version/s: 2.1 > Redesign GridDhtPartitionTopologyImpl.part2node map to store only diff from > affinity assignment > --- > > Key: IGNITE-5068 > URL: https://issues.apache.org/jira/browse/IGNITE-5068 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Ilya Lantukh >Assignee: Alexey Goncharuk > Labels: important > Fix For: 2.1 > > > This map can become very huge on large topologies, and rebuilding it on each > update is also costly. Some beneficial changes were made in the scope of > IGNITE-4626, but further improvement requires complete redesign. > This map always stores affinity nodes + some additional "temporary owners". > Those owners are only needed to complete rebalancing and they will evict > partition when rebalancing is finished. It seems that storing only those > non-affinity owners can greatly reduce memory required by this map (it will > be empty on stable topology) and effort needed to keep it consistent with > node2part. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5068) Redesign GridDhtPartitionTopologyImpl.part2node map to store only diff from affinity assignment
[ https://issues.apache.org/jira/browse/IGNITE-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5068: - Labels: important (was: ) > Redesign GridDhtPartitionTopologyImpl.part2node map to store only diff from > affinity assignment > --- > > Key: IGNITE-5068 > URL: https://issues.apache.org/jira/browse/IGNITE-5068 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Ilya Lantukh >Assignee: Alexey Goncharuk > Labels: important > Fix For: 2.1 > > > This map can become very huge on large topologies, and rebuilding it on each > update is also costly. Some beneficial changes were made in the scope of > IGNITE-4626, but further improvement requires complete redesign. > This map always stores affinity nodes + some additional "temporary owners". > Those owners are only needed to complete rebalancing and they will evict > partition when rebalancing is finished. It seems that storing only those > non-affinity owners can greatly reduce memory required by this map (it will > be empty on stable topology) and effort needed to keep it consistent with > node2part. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-4324) ScanQuery throws incomprehensible exception when topology does not contain data nodes
[
https://issues.apache.org/jira/browse/IGNITE-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042671#comment-16042671
]
Nikolay Tikhonov commented on IGNITE-4324:
--
[~williamdo],
Thank you for your contribution! I've reviewed your changes and have only minor
notes. I've fixed them (code style and added test for partition cache). I've
pushed changes to ignite-4324 branch. Could you look at it? If you don't have
any objections, I'll merge the branch to master.
> ScanQuery throws incomprehensible exception when topology does not contain
> data nodes
> -
>
> Key: IGNITE-4324
> URL: https://issues.apache.org/jira/browse/IGNITE-4324
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7, 1.8
>Reporter: Nikolay Tikhonov
>Assignee: William Do
> Labels: newbie
> Fix For: 2.1
>
> Attachments: Tests.patch
>
>
> ScanQuery throws incomprehensible exception when topology does not contain
> data nodes (for example with node filter). See attached test.
> {code}
> java.lang.IllegalArgumentException: bound must be positive
> at java.util.Random.nextInt(Random.java:388)
> at org.apache.ignite.internal.util.lang.GridFunc.rand(GridFunc.java:677)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.nodes(GridCacheQueryAdapter.java:582)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:527)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4119)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.igniteIterator(GridCacheAdapter.java:4094)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.iterator(IgniteCacheProxy.java:1979)
> at
> org.apache.ignite.internal.CacheFilterQueryTest.testScanQuery(CacheFilterQueryTest.java:90)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1768)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1706)
> at java.lang.Thread.run(Thread.java:745)
> [
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5383) Do not perform cache key validation when BinaryMarshaller is used
[
https://issues.apache.org/jira/browse/IGNITE-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042670#comment-16042670
]
Vladimir Ozerov commented on IGNITE-5383:
-
[~daradurvs], implementation looks good to me. Could you please confirm that
there are no new failures on TeamCity as compared to master ({{default}})
branch?
> Do not perform cache key validation when BinaryMarshaller is used
> -
>
> Key: IGNITE-5383
> URL: https://issues.apache.org/jira/browse/IGNITE-5383
> Project: Ignite
> Issue Type: Task
> Components: binary, cache
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
> Labels: important
> Fix For: 2.1
>
>
> Currently whenever cache operation is performed, we invoke
> {{GridCacheAdapter.validateCacheKey}} to make sure that key overrides
> {{equals}} and {{hashCode}}.
> This check should not be performed when {{BinaryMarshaller}} is set, since we
> do not use these methods in binary mode.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5451) .NET: Improve outer joins in LINQ
Pavel Tupitsyn created IGNITE-5451:
--
Summary: .NET: Improve outer joins in LINQ
Key: IGNITE-5451
URL: https://issues.apache.org/jira/browse/IGNITE-5451
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Fix For: 2.2
Currently outer joins are supported in a convoluted way, via a regular join
with {{DefaultIfEmpty()}} call:
{code}
var res = persons.Join(roles.DefaultIfEmpty(),
person => person.Value.RoleId, role => role.Key,...)
{code}
This is not consistent with LINQ to objects, Entity Framework and other things
out there, and unexpected for the users.
Instead we should support {{GroupJoin}} properly, see
https://stackoverflow.com/questions/584820/how-do-you-perform-a-left-outer-join-using-linq-extension-methods
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-5339) Thin JDBC driver: validate compliance
[ https://issues.apache.org/jira/browse/IGNITE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-5339: Assignee: Taras Ledkov (was: Sergey Kalashnikov) > Thin JDBC driver: validate compliance > - > > Key: IGNITE-5339 > URL: https://issues.apache.org/jira/browse/IGNITE-5339 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Fix For: 2.1 > > > We need to make sure that all methods of our new driver are compliant with > JDBC spec, namely: > 1) Semantics of normal execution is correct > 2) Exceptions are thrown when excepted > I propose the following flow: > 1) Walk through interface classes (Connection -> Statement, PreparedStatement > -> ResultSet) > 2) For every method identify a set of tests to verify semantics (if any). > 3) Write those tests, even if they fail. > 4) Once all tests are ready, decide how to proceed with their fixes. > NB: we should write tests even for methods which throw "not-implemented > exception", so that we better understand the scope of remaining work. > Link to [JDBC > specification|http://download.oracle.com/otn-pub/jcp/jdbc-4_1-mrel-spec/jdbc4.1-fr-spec.pdf?AuthParam=1496141650_c2ec45f13eb8c532632bbfaede64f351] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-1793:
Assignee: (was: Ilya Lantukh)
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs
> on TC sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
>Priority: Critical
> Labels: Muted_test
> Fix For: 2.1
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-1793:
Assignee: Ilya Lantukh
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs
> on TC sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Ilya Lantukh
>Priority: Critical
> Labels: Muted_test
> Fix For: 2.1
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-4455) Node restarts may hang grid on exchange process
[ https://issues.apache.org/jira/browse/IGNITE-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-4455. --- Resolution: Cannot Reproduce > Node restarts may hang grid on exchange process > --- > > Key: IGNITE-4455 > URL: https://issues.apache.org/jira/browse/IGNITE-4455 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.8 >Reporter: Dmitry Karachentsev >Assignee: Evgenii Zhuravlev > > Node connect or disconnect may force grid hang on exchange process. > Refer test that reproduces problem: > [PR#1360|https://github.com/apache/ignite/pull/1360] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-5126: - Description: Support batches operations for the thin JDBC driver. was: Support batches operations for the thin client based JDBC driver: https://apacheignite.readme.io/docs/jdbc-driver#hostname-based-jdbc-connection > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > > Support batches operations for the thin JDBC driver. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5126) JDBC thin driver: support batches
[ https://issues.apache.org/jira/browse/IGNITE-5126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-5126: - Summary: JDBC thin driver: support batches (was: Support batches for thin client based JDBC driver) > JDBC thin driver: support batches > -- > > Key: IGNITE-5126 > URL: https://issues.apache.org/jira/browse/IGNITE-5126 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 1.9 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > > Support batches operations for the thin client based JDBC driver: > https://apacheignite.readme.io/docs/jdbc-driver#hostname-based-jdbc-connection -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5234) JDBC thin driver: support connection timeout
[ https://issues.apache.org/jira/browse/IGNITE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-5234: - Summary: JDBC thin driver: support connection timeout (was: JDBC thin driver: support connectiom timeout) > JDBC thin driver: support connection timeout > > > Key: IGNITE-5234 > URL: https://issues.apache.org/jira/browse/IGNITE-5234 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5234) JDBC thin driver: support connectiom timeout
[ https://issues.apache.org/jira/browse/IGNITE-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-5234: - Summary: JDBC thin driver: support connectiom timeout (was: JDBC thin driver: support connection and query timeout) > JDBC thin driver: support connectiom timeout > > > Key: IGNITE-5234 > URL: https://issues.apache.org/jira/browse/IGNITE-5234 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-5237) JDBC thin driver: support client info
[ https://issues.apache.org/jira/browse/IGNITE-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-5237. -- Resolution: Duplicate > JDBC thin driver: support client info > - > > Key: IGNITE-5237 > URL: https://issues.apache.org/jira/browse/IGNITE-5237 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5260) JDBC thin driver: implement SQLWarning support
[ https://issues.apache.org/jira/browse/IGNITE-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-5260: - Fix Version/s: 2.2 > JDBC thin driver: implement SQLWarning support > -- > > Key: IGNITE-5260 > URL: https://issues.apache.org/jira/browse/IGNITE-5260 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5450) .NET: Update IDataStreamer.AllowOverwrite documentation
[
https://issues.apache.org/jira/browse/IGNITE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042637#comment-16042637
]
Pavel Tupitsyn commented on IGNITE-5450:
Fixed in master: {{e238d563bf374489b34e6c719d10f580e4eb7b14}}
> .NET: Update IDataStreamer.AllowOverwrite documentation
> ---
>
> Key: IGNITE-5450
> URL: https://issues.apache.org/jira/browse/IGNITE-5450
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{IDataStreamer.AllowOverwrite}} is false by default, which means
> {{SkipStore}} is implicitly true.
> This is explained in Java documentation, but not in .NET.
> Probably need to update readme.io as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-5450) .NET: Update IDataStreamer.AllowOverwrite documentation
[
https://issues.apache.org/jira/browse/IGNITE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-5450.
Resolution: Fixed
> .NET: Update IDataStreamer.AllowOverwrite documentation
> ---
>
> Key: IGNITE-5450
> URL: https://issues.apache.org/jira/browse/IGNITE-5450
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{IDataStreamer.AllowOverwrite}} is false by default, which means
> {{SkipStore}} is implicitly true.
> This is explained in Java documentation, but not in .NET.
> Probably need to update readme.io as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5229) Specify caches when using Redis protocol
[ https://issues.apache.org/jira/browse/IGNITE-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042606#comment-16042606 ] Roman Shtykh commented on IGNITE-5229: -- [~anovikov] Thank you for the review! Sorry, I am not sure I understand the problem you found. Do you think that registering caches other than "redis-ignite-internal-cache-0" (for instance, "redis-ignite-internal-cache-1", "redis-ignite-internal-cache-2") explicitly is the problem, and this has to be prevented? We end up with several caches with different configurations then, right? To me, it is ok -- if users really want it, there is no strong reason to stop them. Does it break anything I cannot see? Perhaps a Redis user won't expect this behavior, but probably we don't need to follow Redis rules very strictly and give users more freedom with caches. What do you think? Your understanding on how it works is correct. > Specify caches when using Redis protocol > > > Key: IGNITE-5229 > URL: https://issues.apache.org/jira/browse/IGNITE-5229 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > Fix For: 2.1 > > > Currently there's no way to switch caches -- all requests go to 'default'. > _Note that this is the switch needed only for a subset of Redis data > structures (currently only STRINGs) -- for SETs and HASHTABLEs caches will be > specified as keys (see IGNITE-5241)_ > The solution to be implemented: > 1. A user specifies the cache configuration (template) with predefined name > ‘redis-ignite-internal-cache’ > 2. Then issues ‘SELECT n’, and uses ‘redis-ignite-internal-cache-n’. > Caches are configurable by providing a template. > http://apache-ignite-developers.2346864.n4.nabble.com/Changing-cache-name-when-using-Redis-protocol-td17727.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5450) .NET: Update IDataStreamer.AllowOverwrite documentation
[
https://issues.apache.org/jira/browse/IGNITE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042577#comment-16042577
]
Pavel Tupitsyn commented on IGNITE-5450:
Readme pages updated:
https://apacheignite-net.readme.io/docs/data-streamers
https://apacheignite.readme.io/docs/data-streamers
> .NET: Update IDataStreamer.AllowOverwrite documentation
> ---
>
> Key: IGNITE-5450
> URL: https://issues.apache.org/jira/browse/IGNITE-5450
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{IDataStreamer.AllowOverwrite}} is false by default, which means
> {{SkipStore}} is implicitly true.
> This is explained in Java documentation, but not in .NET.
> Probably need to update readme.io as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5450) .NET: Update IDataStreamer.AllowOverwrite documentation
Pavel Tupitsyn created IGNITE-5450:
--
Summary: .NET: Update IDataStreamer.AllowOverwrite documentation
Key: IGNITE-5450
URL: https://issues.apache.org/jira/browse/IGNITE-5450
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.1
{{IDataStreamer.AllowOverwrite}} is false by default, which means {{SkipStore}}
is implicitly true.
This is explained in Java documentation, but not in .NET.
Probably need to update readme.io as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IGNITE-5450) .NET: Update IDataStreamer.AllowOverwrite documentation
[
https://issues.apache.org/jira/browse/IGNITE-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-5450:
---
Labels: .NET (was: )
> .NET: Update IDataStreamer.AllowOverwrite documentation
> ---
>
> Key: IGNITE-5450
> URL: https://issues.apache.org/jira/browse/IGNITE-5450
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> {{IDataStreamer.AllowOverwrite}} is false by default, which means
> {{SkipStore}} is implicitly true.
> This is explained in Java documentation, but not in .NET.
> Probably need to update readme.io as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5437) SQL: Incorrect partition is derived from query when argument type differs from column type
[ https://issues.apache.org/jira/browse/IGNITE-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042560#comment-16042560 ] ASF GitHub Bot commented on IGNITE-5437: GitHub user skalashnikov opened a pull request: https://github.com/apache/ignite/pull/2107 IGNITE-5437: Handling query argument type for query derived partitions You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-5437 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2107.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2107 commit db1e8b69f6bbd0a28aee638d63032ac0c3307d9e Author: skalashnikov Date: 2017-06-07T16:53:53Z IGNITE-5437: Fixed query argument type handling for query derived partitions. > SQL: Incorrect partition is derived from query when argument type differs > from column type > -- > > Key: IGNITE-5437 > URL: https://issues.apache.org/jira/browse/IGNITE-5437 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1 >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.1 > > Attachments: BugReproducer5437.java > > > Ignite SQL attempts to derive partition from the query in certain cases and > sends the map queries only to nodes which have those calculated partitions. > Such queries are limited to contain equality conditions over key or affinity > key columns at the left and constant or parameter at the right. > When the type of argument does not match the column type, the calculation > leads to wrong result. > For example, the following query produces incomplete results when _key column > is INTEGER and the argument is CHAR. > select * from test where _key = ? > However, this is valid and resultive query for H2, which does implicit > conversion in such cases. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5229) Specify caches when using Redis protocol
[ https://issues.apache.org/jira/browse/IGNITE-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042558#comment-16042558 ] Andrey Novikov commented on IGNITE-5229: Hi [~roman_s], I reviewed your pull request, looks good except following usability problems: * Before use Redis client user should start cache with name: "redis-ignite-internal-cache-0" * Cache with name: "redis-ignite-internal-cache-0" will be used as template for create new cache if user execute SELECT command As I understand from user list, this is unexpected behavior: By default client is connected to database '0'. Upon first request from the client IgniteCache with name "redis-ignite-internal-cache-0" gets created. Same for other databases - "redis-ignite-itnernal-cache-XX". User can register a config template for these caches. [~roman_s], [~yzhdanov] Is that correct? > Specify caches when using Redis protocol > > > Key: IGNITE-5229 > URL: https://issues.apache.org/jira/browse/IGNITE-5229 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Labels: redis > Fix For: 2.1 > > > Currently there's no way to switch caches -- all requests go to 'default'. > _Note that this is the switch needed only for a subset of Redis data > structures (currently only STRINGs) -- for SETs and HASHTABLEs caches will be > specified as keys (see IGNITE-5241)_ > The solution to be implemented: > 1. A user specifies the cache configuration (template) with predefined name > ‘redis-ignite-internal-cache’ > 2. Then issues ‘SELECT n’, and uses ‘redis-ignite-internal-cache-n’. > Caches are configurable by providing a template. > http://apache-ignite-developers.2346864.n4.nabble.com/Changing-cache-name-when-using-Redis-protocol-td17727.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5449) Add complex DDL+DML test.
Alexander Paschenko created IGNITE-5449: --- Summary: Add complex DDL+DML test. Key: IGNITE-5449 URL: https://issues.apache.org/jira/browse/IGNITE-5449 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Paschenko Assignee: Alexander Paschenko Fix For: 2.1 We need a test that will test data flow behavior in chain of DML+DDL operations as a whole. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-5372) .NET: IgniteConfiguration.LongQueryWarningTimeout
[
https://issues.apache.org/jira/browse/IGNITE-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-5372.
Resolution: Fixed
> .NET: IgniteConfiguration.LongQueryWarningTimeout
> -
>
> Key: IGNITE-5372
> URL: https://issues.apache.org/jira/browse/IGNITE-5372
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> * Add {{IgniteConfiguration.LongQueryWarningTimeout}}
> * Mark {{CacheConfiguration.LongQueryWarningTimeout}} as obsolete
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5372) .NET: IgniteConfiguration.LongQueryWarningTimeout
[
https://issues.apache.org/jira/browse/IGNITE-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042527#comment-16042527
]
Pavel Tupitsyn commented on IGNITE-5372:
Merged to master: {{d5ecf0a7e1683a060cd5c0b1dd2ba0d49c678947}}
> .NET: IgniteConfiguration.LongQueryWarningTimeout
> -
>
> Key: IGNITE-5372
> URL: https://issues.apache.org/jira/browse/IGNITE-5372
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> * Add {{IgniteConfiguration.LongQueryWarningTimeout}}
> * Mark {{CacheConfiguration.LongQueryWarningTimeout}} as obsolete
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5448) IgniteH2Indexing#tables implemented incorrectly
Vladimir Ozerov created IGNITE-5448:
---
Summary: IgniteH2Indexing#tables implemented incorrectly
Key: IGNITE-5448
URL: https://issues.apache.org/jira/browse/IGNITE-5448
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexey Goncharuk
Fix For: 2.1
Currently method IgniteH2Indexing#tables works as follows:
1) Get schema name for cache
2) Return all tables from the schema
This will work incorrectly for caches in {{PUBLIC}} schema, as tables for all
caches will be returned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception
[
https://issues.apache.org/jira/browse/IGNITE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042509#comment-16042509
]
Chris Wang commented on IGNITE-5204:
Dear,
I found the things that might reproduce the problem. in the class
"org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelper"
line 444:
"size = (short)(s.length | 0x8000);"
when the "s" is null, the logic will cause exception (NullReferenceException)
cause problem when querying on the cache.
case Value.STRING_IGNORECASE: {
short size;
byte[] s = val.getString().getBytes(CHARSET);
if (s.length + 3 <= maxSize)
size = (short)s.length;
else {
s = trimUTF8(s, maxSize - 3);
size = (short)(s.length | 0x8000);
}
if (s == null) {
// Can't fit anything to
PageUtils.putByte(pageAddr, off, (byte)Value.UNKNOWN);
return 0;
}
else {
PageUtils.putByte(pageAddr, off, (byte)val.getType());
PageUtils.putShort(pageAddr, off + 1, size);
PageUtils.putBytes(pageAddr, off + 3, s);
return s.length + 3;
}
}
> The Unicode character in the value of a field which are included in an
> un-unique index will cause "stack overhead" exception
>
>
> Key: IGNITE-5204
> URL: https://issues.apache.org/jira/browse/IGNITE-5204
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.0
> Environment: windows server 2012, JDK 1.8, X64
>Reporter: Chris Wang
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.1
>
>
> When put "草DX009090" as the value of BillId, which is a field of entity
> Bill. If I define a index includes the BillId, and execute the query like
> "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there
> throws an exception by the H2 with a code 5000.
> another scenario is, I have two entities, "Bill" and "Detail", both have
> field "BillId". If either of them have value like "草DX009090" and execute the
> query like "select bill.* from bill left join detail on
> bill.billid=detail.billid", the whole ignite cache node will halt ( suppose
> there should be an stack overhead exception, dead loop).
> ==
> I think the issue should relate to hash computing on the unicode character.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5325) CREATE TABLE should support "cacheGroup" property
[
https://issues.apache.org/jira/browse/IGNITE-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042490#comment-16042490
]
ASF GitHub Bot commented on IGNITE-5325:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2099
> CREATE TABLE should support "cacheGroup" property
> -
>
> Key: IGNITE-5325
> URL: https://issues.apache.org/jira/browse/IGNITE-5325
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> When cache groups are ready (IGNITE-5075), we should be able to configure
> group name through {{WITH}} keyword in the same way as we configure template
> name for now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (IGNITE-5325) CREATE TABLE should support "cacheGroup" property
[
https://issues.apache.org/jira/browse/IGNITE-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-5325.
-
Resolution: Fixed
> CREATE TABLE should support "cacheGroup" property
> -
>
> Key: IGNITE-5325
> URL: https://issues.apache.org/jira/browse/IGNITE-5325
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> When cache groups are ready (IGNITE-5075), we should be able to configure
> group name through {{WITH}} keyword in the same way as we configure template
> name for now.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IGNITE-5447) Web Console: Deployment ID may be not unique for cache
Alexey Kuznetsov created IGNITE-5447: Summary: Web Console: Deployment ID may be not unique for cache Key: IGNITE-5447 URL: https://issues.apache.org/jira/browse/IGNITE-5447 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 2.1 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.1 Web Console uses cache.deploymentId for cache identification. In 2.1 deploymentId may be same for several caches. This logic should be reworked. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (IGNITE-5432) Test IgniteMarshallerCacheClassNameConflictTest failed
[ https://issues.apache.org/jira/browse/IGNITE-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Ivanov updated IGNITE-5432: -- Affects Version/s: (was: 2.1) 2.0 > Test IgniteMarshallerCacheClassNameConflictTest failed > --- > > Key: IGNITE-5432 > URL: https://issues.apache.org/jira/browse/IGNITE-5432 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Alexey Ivanov >Assignee: Alexey Ivanov > Fix For: 2.1 > > > Test suit: > IgniteBinarySimpleNameMapperBasicTestSuite > Test: > IgniteMarshallerCacheClassNameConflictTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IGNITE-5432) Test IgniteMarshallerCacheClassNameConflictTest failed
[ https://issues.apache.org/jira/browse/IGNITE-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042470#comment-16042470 ] Alexey Ivanov commented on IGNITE-5432: --- Test fixed. pull request: https://github.com/apache/ignite/pull/2105 master: http://ci.ignite.apache.org/viewLog.html?buildId=653740&buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic&tab=buildResultsDiv 2105: http://ci.ignite.apache.org/viewLog.html?buildId=653518&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteBinarySImpleMapperBasic > Test IgniteMarshallerCacheClassNameConflictTest failed > --- > > Key: IGNITE-5432 > URL: https://issues.apache.org/jira/browse/IGNITE-5432 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Alexey Ivanov >Assignee: Alexey Ivanov > Fix For: 2.1 > > > Test suit: > IgniteBinarySimpleNameMapperBasicTestSuite > Test: > IgniteMarshallerCacheClassNameConflictTest -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (IGNITE-5436) .NET: CacheConfiguration.GroupName
[
https://issues.apache.org/jira/browse/IGNITE-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-5436.
Resolution: Fixed
> .NET: CacheConfiguration.GroupName
> --
>
> Key: IGNITE-5436
> URL: https://issues.apache.org/jira/browse/IGNITE-5436
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> Propagate {{CacheConfiguration.GroupName}} configuration property.
> Caches within the same group underneath use single physical Ignite cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5436) .NET: CacheConfiguration.GroupName
[
https://issues.apache.org/jira/browse/IGNITE-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042454#comment-16042454
]
Pavel Tupitsyn commented on IGNITE-5436:
Merged to master: {{5c77dab546f1eded908fd74a51eaef59054e038c}}
> .NET: CacheConfiguration.GroupName
> --
>
> Key: IGNITE-5436
> URL: https://issues.apache.org/jira/browse/IGNITE-5436
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: .NET
> Fix For: 2.1
>
>
> Propagate {{CacheConfiguration.GroupName}} configuration property.
> Caches within the same group underneath use single physical Ignite cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16042449#comment-16042449 ] Aleksey Chetaev commented on IGNITE-5434: - [~vozerov] Full logs in attachments. > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1291) >
