[jira] [Commented] (IGNITE-12139) RPM for 2.7.5 release built from incorrect version
[
https://issues.apache.org/jira/browse/IGNITE-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928198#comment-16928198
]
Peter Ivanov commented on IGNITE-12139:
---
I can rebuild and reupload packages from correct hash, should I do it now?
> RPM for 2.7.5 release built from incorrect version
> --
>
> Key: IGNITE-12139
> URL: https://issues.apache.org/jira/browse/IGNITE-12139
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7.5
>Reporter: Jan Kupec
>Assignee: Dmitriy Pavlov
>Priority: Minor
>
> The {{apache-ignite-2.7.5}} RPM found in the [official RPM
> repository|https://ignite.apache.org/download.cgi#rpm-package] has been built
> from commit *{{c9521338}}*, which is several weeks of development away from
> the head of the {{ignite-2.7.5}} release branch (*{{be4f2a15}}*) and
> apparently contains incompatible changes.
> Is this a result of a human error or an error in the automated build system?
> Can this easily be fixed?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12164) Ignite Node stopped by ttl-cleanup-worker
[ https://issues.apache.org/jira/browse/IGNITE-12164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shariar Imtiaz updated IGNITE-12164: Attachment: ignite config.txt > Ignite Node stopped by ttl-cleanup-worker > - > > Key: IGNITE-12164 > URL: https://issues.apache.org/jira/browse/IGNITE-12164 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7 >Reporter: Shariar Imtiaz >Priority: Major > Fix For: None > > Attachments: Ignite Error.txt, ignite config.txt > > > I have Ignite 2.7 and 5 node cluster. Over 40Mil data is generating and > stored in ignite cache. I have set 3 days expiry for a paticular cache. It > stopped by ttl-cleanup-worker. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12164) Ignite Node stopped by ttl-cleanup-worker
Shariar Imtiaz created IGNITE-12164: --- Summary: Ignite Node stopped by ttl-cleanup-worker Key: IGNITE-12164 URL: https://issues.apache.org/jira/browse/IGNITE-12164 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.7 Reporter: Shariar Imtiaz Fix For: None Attachments: Ignite Error.txt I have Ignite 2.7 and 5 node cluster. Over 40Mil data is generating and stored in ignite cache. I have set 3 days expiry for a paticular cache. It stopped by ttl-cleanup-worker. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12162) Add the cluster name to the promt message "--deactivate" the control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928185#comment-16928185
]
Ignite TC Bot commented on IGNITE-12162:
{panel:title=Branch: [pull/6863/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4589123buildTypeId=IgniteTests24Java8_RunAll]
> Add the cluster name to the promt message "--deactivate" the control.sh
> ---
>
> Key: IGNITE-12162
> URL: https://issues.apache.org/jira/browse/IGNITE-12162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
>
> Add the cluster name to the promt message "--deactivate" the control.sh
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928009#comment-16928009
]
Denis Magda commented on IGNITE-12032:
--
[~isapego], could you please step in?
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.8
>
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>
> 04)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>
> oServer.java:2389)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>
> 6)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)*
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node,
> so, we shouldn't print exception in the log. We should replace it with
> something like INFO message about ODBC client disconnection.
> Thread from user list:
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12054) Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16928005#comment-16928005 ] Denis Magda commented on IGNITE-12054: -- [~NIzhikov], [~zaleslaw], how about creating the first separate Ignite module for Spark and release it independently? The module will be in its own repository and there are might be different branches for different versions. Ignite community will support and release only the latest version of Spark integration while the users can always build an old version from one of the branches. More details are recorded on this page: https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization If three of us agree, then we can restart discussion on the dev list, do a call with [~agoncharuk] and other community members and get down to the implementation. > Upgrade Spark module to 2.4 > --- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.7.5 >Reporter: Denis Magda >Assignee: Nikolay Izhikov >Priority: Blocker > Fix For: 2.8 > > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IGNITE-4604) Python: basic SQL Grid API
[ https://issues.apache.org/jira/browse/IGNITE-4604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4604. --- > Python: basic SQL Grid API > -- > > Key: IGNITE-4604 > URL: https://issues.apache.org/jira/browse/IGNITE-4604 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Implement basic SQL Grid API similar to the scope covered by C++ which > includes SQL queries and DML. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (IGNITE-4604) Python: basic SQL Grid API
[ https://issues.apache.org/jira/browse/IGNITE-4604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4604. - Resolution: Fixed Python Thin Client has been supported for Ignite: https://apacheignite.readme.io/docs/python-thin-client > Python: basic SQL Grid API > -- > > Key: IGNITE-4604 > URL: https://issues.apache.org/jira/browse/IGNITE-4604 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Implement basic SQL Grid API similar to the scope covered by C++ which > includes SQL queries and DML. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IGNITE-4603) Python: basic Data Grid API
[ https://issues.apache.org/jira/browse/IGNITE-4603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4603. --- > Python: basic Data Grid API > --- > > Key: IGNITE-4603 > URL: https://issues.apache.org/jira/browse/IGNITE-4603 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Implement basic Data Grid API similar to the scope covered by C++: > https://apacheignite-cpp.readme.io/docs/data-grid -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (IGNITE-4602) Python: module and build scripts
[ https://issues.apache.org/jira/browse/IGNITE-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4602. - Resolution: Fixed Python Thin Client has been supported for Ignite: https://apacheignite.readme.io/docs/python-thin-client > Python: module and build scripts > > > Key: IGNITE-4602 > URL: https://issues.apache.org/jira/browse/IGNITE-4602 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Create "ignite-python" module and implement a build procedure for it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (IGNITE-4601) Python: support binary format
[ https://issues.apache.org/jira/browse/IGNITE-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-4601. - Resolution: Fixed Python Thin Client has been supported for Ignite: https://apacheignite.readme.io/docs/python-thin-client > Python: support binary format > - > > Key: IGNITE-4601 > URL: https://issues.apache.org/jira/browse/IGNITE-4601 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Python client has to support binary format natively by implementing a binary > marshaller logic directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IGNITE-4601) Python: support binary format
[ https://issues.apache.org/jira/browse/IGNITE-4601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4601. --- > Python: support binary format > - > > Key: IGNITE-4601 > URL: https://issues.apache.org/jira/browse/IGNITE-4601 > Project: Ignite > Issue Type: Sub-task >Reporter: Denis Magda >Priority: Major > > Python client has to support binary format natively by implementing a binary > marshaller logic directly. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (IGNITE-4600) Apache Ignite Python Library
[ https://issues.apache.org/jira/browse/IGNITE-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-4600. --- > Apache Ignite Python Library > > > Key: IGNITE-4600 > URL: https://issues.apache.org/jira/browse/IGNITE-4600 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Priority: Major > Labels: gsoc2017 > > The goal of this ticket is to enable direct Python support for Apache Ignite > In-Memory Data Fabric. > This ticket is an umbrella ticket of basic functionality that should be > released first. > Python can be supported in several ways that have do be discussed on the dev > list: > - Use SWIG (http://www.swig.org) to generate Python API from Ignite.C++. > - Design and implement Python API from scratch talking to underlying JVM that > runs the node. > - Design and implement Python API from scratch talking to Ignite.C++ API that > talks to JVM on its turn. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-4600) Apache Ignite Python Library
[ https://issues.apache.org/jira/browse/IGNITE-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927994#comment-16927994 ] Denis Magda commented on IGNITE-4600: - [~zyc], this ticket should be considered as outdated as long as Ignite already support Python: https://apacheignite.readme.io/docs/python-thin-client Please send an email to the dev list if you'd like to enhance the existing client anyhow. I'm closing this and all dependent tickets. > Apache Ignite Python Library > > > Key: IGNITE-4600 > URL: https://issues.apache.org/jira/browse/IGNITE-4600 > Project: Ignite > Issue Type: Task >Reporter: Denis Magda >Priority: Major > Labels: gsoc2017 > > The goal of this ticket is to enable direct Python support for Apache Ignite > In-Memory Data Fabric. > This ticket is an umbrella ticket of basic functionality that should be > released first. > Python can be supported in several ways that have do be discussed on the dev > list: > - Use SWIG (http://www.swig.org) to generate Python API from Ignite.C++. > - Design and implement Python API from scratch talking to underlying JVM that > runs the node. > - Design and implement Python API from scratch talking to Ignite.C++ API that > talks to JVM on its turn. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12139) RPM for 2.7.5 release built from incorrect version
[
https://issues.apache.org/jira/browse/IGNITE-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927992#comment-16927992
]
Denis Magda commented on IGNITE-12139:
--
[~vveider], [~avinogradov], [~dpavlov], could you please check this issue?
> RPM for 2.7.5 release built from incorrect version
> --
>
> Key: IGNITE-12139
> URL: https://issues.apache.org/jira/browse/IGNITE-12139
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7.5
>Reporter: Jan Kupec
>Assignee: Dmitriy Pavlov
>Priority: Minor
>
> The {{apache-ignite-2.7.5}} RPM found in the [official RPM
> repository|https://ignite.apache.org/download.cgi#rpm-package] has been built
> from commit *{{c9521338}}*, which is several weeks of development away from
> the head of the {{ignite-2.7.5}} release branch (*{{be4f2a15}}*) and
> apparently contains incompatible changes.
> Is this a result of a human error or an error in the automated build system?
> Can this easily be fixed?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12146) Make timeout of network operations customizable
[ https://issues.apache.org/jira/browse/IGNITE-12146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927989#comment-16927989 ] Denis Magda commented on IGNITE-12146: -- [~isapego], could you please step in and see what can be improved here? > Make timeout of network operations customizable > --- > > Key: IGNITE-12146 > URL: https://issues.apache.org/jira/browse/IGNITE-12146 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7.5 >Reporter: Oleg Popov >Priority: Major > Labels: cpp > > I'm performing a data migration from MariaDB to Apache Ignite and I do bulk > insertions with help of a "converter". All works fine except of appearing of > a message at the end of operations: > *Can not send message to remote host: timeout* > but all data succefully placed into Ignite cluster. > Short investigation showed that default values of network operations are too > low in my case (do data migration, remember?). Default values: > [https://github.com/apache/ignite/blob/ignite-2.7.5/modules/platforms/cpp/thin-client/src/impl/data_router.h#L61] > > It would be much better to have an option to customize these values through > "IgniteClientConfiguration" (the python client has such option?). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12149) apacheignite/web-agent:2.7.0 /2.6.0 both the images looks like corrupted.
[
https://issues.apache.org/jira/browse/IGNITE-12149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927987#comment-16927987
]
Denis Magda commented on IGNITE-12149:
--
[~kuaw26], [~greg.stachnick], could you please have a look at the issue?
> apacheignite/web-agent:2.7.0 /2.6.0 both the images looks like corrupted.
> --
>
> Key: IGNITE-12149
> URL: https://issues.apache.org/jira/browse/IGNITE-12149
> Project: Ignite
> Issue Type: Bug
>Reporter: Gaurav Agnihotri
>Priority: Blocker
>
> apacheignite/web-agent:2.7.0 /2.6.0 both the images looks like corrupted.
> giving error {{Failed to find agent property file: default.properties}} &
> {{You are using an older version of the agent. Please reload agent}}
> {{}}
>
> Log trace :-
> [2019-09-09 04:54:11,869][INFO ][main][AgentLauncher] Starting Apache Ignite
> Web Console Agent...
> [2019-09-09 04:54:12,482][WARN ][main][AgentLauncher] Failed to find agent
> property file: default.properties
>
> Agent configuration:
> User's security tokens : xyyF
> URI to Ignite node REST server: http://10.x.x.x:8080
> URI to Ignite Console server : http://frontend.web-console.svc.cluster.local
> Path to agent property file : default.properties
> Path to JDBC drivers folder : ./jdbc-drivers
> Demo mode : enabled
>
> [2019-09-09 04:54:13,566][INFO ][main][AgentLauncher] Connecting to:
> http://frontend.web-console.svc.cluster.local
> [2019-09-09 04:54:14,179][INFO ][EventThread][AgentLauncher] Connection
> established.
> [2019-09-09 04:54:14,373][ERROR][EventThread][AgentLauncher] You are using an
> older version of the agent. Please reload agent
> {{```}}
> Is there any working Image available?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12163: -- Ignite Flags: (was: Release Notes Required) > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12163: -- Release Note: Fixed missing CacheEntryEventType.Removed event > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927856#comment-16927856 ] Ivan Rakov commented on IGNITE-12163: - Merged to master and 2.7.6. > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 20m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[
https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927792#comment-16927792
]
Ignite TC Bot commented on IGNITE-12163:
{panel:title=Branch: [pull/6862/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4588926]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCustomEventsTest.testCustomEvents_FastStopProcess_2 - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4588931]]
* IgniteBasicTestSuite:
IgniteExceptionRegistrySelfTest.testMultiThreadedMaxSize - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Integrations){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4589007]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4589003buildTypeId=IgniteTests24Java8_RunAll]
> .NET: CacheEntryEventType.Removed is not being risen
>
>
> Key: IGNITE-12163
> URL: https://issues.apache.org/jira/browse/IGNITE-12163
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7.5
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Critical
> Labels: .NET
> Fix For: 2.7.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> * Create a cache with user-defined type
> * Add an ICacheEntryEventListener in order to be notified of
> CacheEntryEventType.Removed events
> * Put a value in the cache
> * Remove that value
> Expected: CacheEntryEventType.Removed event get captured
> Actual: CacheEntryEventType.Updated event get captured
> Update:
> After these changes https://issues.apache.org/jira/browse/IGNITE-8714
> New logic of detecting events (ContinuousQueryUtils.cs) now relies on the
> Object.Equals method which is not intuitive at all.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927728#comment-16927728 ] Amit Chavan commented on IGNITE-11894: -- [~slukyanov] Some questions I have 1. Looking at the Ignite core module I see following classes that are jdbc stores CacheJdbcBlobStore and CacheJdbcPojoStore. Are these the only ones or am I missing more? 2. I see the fetchSize is part of JdbcDialect. Which implementation of the JdbcDilect is used to access CacheStores? 3. Are there any examples of UT or docs which shows how the cachestores are being used so it helps me understand the full end to end workings on the CacheStores. > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a customer implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12163: Labels: .NET (was: ) > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927706#comment-16927706 ] Pavel Tupitsyn commented on IGNITE-12163: - [~ashapkin] looks good to me > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12163: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Labels: .NET > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) .NET: CacheEntryEventType.Removed is not being risen
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12163: Summary: .NET: CacheEntryEventType.Removed is not being risen (was: CacheEntryEventType.Removed is not being rised) > .NET: CacheEntryEventType.Removed is not being risen > > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12153) Control.sh add test for checking that help and cache help output are not broken.
[ https://issues.apache.org/jira/browse/IGNITE-12153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927697#comment-16927697 ] Sergey Antonov commented on IGNITE-12153: - [~Denis Chudov] Could you review my changes please? > Control.sh add test for checking that help and cache help output are not > broken. > > > Key: IGNITE-12153 > URL: https://issues.apache.org/jira/browse/IGNITE-12153 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We should store "ideal" outputs in resorces and compare with current. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12160) Fix RPM packages build
[
https://issues.apache.org/jira/browse/IGNITE-12160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12160:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix RPM packages build
> --
>
> Key: IGNITE-12160
> URL: https://issues.apache.org/jira/browse/IGNITE-12160
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{Tue 10 Sep 2019 Peter Ivanov - 2.7.6-1}} date is in
> invalid format and should be fixed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12153) Control.sh add test for checking that help and cache help output are not broken.
[
https://issues.apache.org/jira/browse/IGNITE-12153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927694#comment-16927694
]
Ignite TC Bot commented on IGNITE-12153:
{panel:title=Branch: [pull/6860/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4588347buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh add test for checking that help and cache help output are not
> broken.
>
>
> Key: IGNITE-12153
> URL: https://issues.apache.org/jira/browse/IGNITE-12153
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store "ideal" outputs in resorces and compare with current.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12163) CacheEntryEventType.Removed is not being rised
[ https://issues.apache.org/jira/browse/IGNITE-12163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12163: -- Fix Version/s: 2.7.6 > CacheEntryEventType.Removed is not being rised > -- > > Key: IGNITE-12163 > URL: https://issues.apache.org/jira/browse/IGNITE-12163 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7.5 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Critical > Fix For: 2.7.6 > > Time Spent: 10m > Remaining Estimate: 0h > > Steps to reproduce: > * Create a cache with user-defined type > * Add an ICacheEntryEventListener in order to be notified of > CacheEntryEventType.Removed events > * Put a value in the cache > * Remove that value > Expected: CacheEntryEventType.Removed event get captured > Actual: CacheEntryEventType.Updated event get captured > Update: > After these changes https://issues.apache.org/jira/browse/IGNITE-8714 > New logic of detecting events (ContinuousQueryUtils.cs) now relies on the > Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12145) [IEP-35] Monitoring list engine
[
https://issues.apache.org/jira/browse/IGNITE-12145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927639#comment-16927639
]
Nikolay Izhikov commented on IGNITE-12145:
--
* Basic interface for objects list is {{MonitoringList}}. It provides the
following features:
** name.
** description.
** row class.
** size.
** iterator for the list content.
** attribute walker (described below).
* MonitoringRow is a marker interface for classes that can be used as a
monitoring list content.
Internally, there is only one implementation of {{MonitoringList}}, for now,
{{MonitoringListAdapter}}.
It adapts the content of some {{ConcurrentMap}} which uses widely in Ignite
internals.
I think, will be another implementation in the follow-up PRs.
Public API changes:
* New registry created {{ReadOnlyMonitoringListRegistry}} It provides access:
** To all lists that exist in the Ignite.
** Ability to subscribe to the list creation/removal events.
* {{MetricExporterSpi}} changes:
** {{setMonitoringListRegistry}} method added
** {{setMonitoringListExportFilter}} method added.
{{MonitoringRowAttributeWalker}} is a helper class for exporter implementations.
Usually, exporter SPI iterates on `MonitoringRow` attributes.
{{SqlViewExporterSpi}}, {{JmxMetricExporterSpi}} can be taken as an example.
It can be implemented with Java reflection API, but I use more quick approach.
{{MonitoringRowAttributeWalker}} can visit each attribute of the
{{MonitoringRow}} implementation.
It's also, preserves, the order provided by the {{MonitoringRow}}
implementation author.
> [IEP-35] Monitoring list engine
> ---
>
> Key: IGNITE-12145
> URL: https://issues.apache.org/jira/browse/IGNITE-12145
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.5
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> The base engine for the monitoring list.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IGNITE-9207) Update Web Console dependencies
[ https://issues.apache.org/jira/browse/IGNITE-9207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9207: Assignee: (was: Alexey Kuznetsov) > Update Web Console dependencies > --- > > Key: IGNITE-9207 > URL: https://issues.apache.org/jira/browse/IGNITE-9207 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Priority: Major > Original Estimate: 2h > Time Spent: 4h > Remaining Estimate: 0h > > Update package.json to latest versions. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-9956) Web Agent should handle EOFException in the process of node stopping
[
https://issues.apache.org/jira/browse/IGNITE-9956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-9956:
Assignee: (was: Alexey Kuznetsov)
> Web Agent should handle EOFException in the process of node stopping
>
>
> Key: IGNITE-9956
> URL: https://issues.apache.org/jira/browse/IGNITE-9956
> Project: Ignite
> Issue Type: Bug
> Components: UI
>Reporter: Roman Guseinov
>Priority: Major
>
> If web agent is connected to a node which starts stopping we will see the
> following message in the agent's logs:
> {code:java}
> [2018-10-03 12:19:32,672][ERROR][pool-3-thread-48][AbstractListener] Failed
> to execute REST command with parameters:
> {p1=6840C2E6-EE22-4F96-8BC3-35DFD60497CF,
> p2=org.gridgain.grid.internal.visor.node.VisorGridGainNodeConfigurationCollectorTask,
> p3=java.lang.Void, name=o.a.i.i.v.compute.VisorGatewayTask, cmd=exe}
> java.io.IOException: unexpected end of stream on
> Connection{datafabric-dev-22.test.com:8080, proxy=DIRECT
> hostAddress=datafabric-dev-22.test.com/10.54.1.21:8080 cipherSuite=none
> protocol=http/1.1}
> at
> okhttp3.internal.http1.Http1Codec.readResponseHeaders(Http1Codec.java:205)
> at
> okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:75)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
> at
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
> at
> okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
> at
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
> at
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:185)
> at okhttp3.RealCall.execute(RealCall.java:69)
> at
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:169)
> at
> org.apache.ignite.console.agent.rest.RestExecutor.sendRequest(RestExecutor.java:184)
> at
> org.apache.ignite.console.agent.handlers.RestListener.execute(RestListener.java:85)
> at
> org.apache.ignite.console.agent.handlers.AbstractListener.lambda$call$0(AbstractListener.java:76)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException: \n not found: limit=0 content=…
> at
> okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:226)
> at
> okio.RealBufferedSource.readUtf8LineStrict(RealBufferedSource.java:210)
> at
> okhttp3.internal.http1.Http1Codec.readResponseHeaders(Http1Codec.java:189)
> ... 24 more
> {code}
> It looks like node returns an empty response. Web agent should handle that,
> print a more understandable message and start trying to connect to other
> nodes immediately.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-11094) Add SSL support for ignite zookeeper SPI
[
https://issues.apache.org/jira/browse/IGNITE-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927603#comment-16927603
]
Ryabov Dmitrii commented on IGNITE-11094:
-
Apache Zookeeper supports SSL since 3.5.x version, so, to write a test we need
to update zk version (and Curator version, because it tests Zookeeper).
I added {{ZookeeperDiscoverySpiSslTest}} class and edited
{{ZookeeperDiscoverySpiTestBase}} class to test SSL connection. In the same
time, version update requires changes in some other test classes.
In {{ZookeeperDiscoveryImpl}} class I fixed a bug - with enabled custom
security, NPE happens in {{ZookeeperDiscoveryImpl.validateJoiningNode}} on spi
validation, because currently {{ATTR_SECURITY_SUBJECT_V2}} is placed into node
attrs after validation.
> Add SSL support for ignite zookeeper SPI
>
>
> Key: IGNITE-11094
> URL: https://issues.apache.org/jira/browse/IGNITE-11094
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> ZK 3.5.4-beta is already supporting SSL [1]. We should add SSL support to ZK
> server connections if Zookeeper SPI used.
> 1.
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12108) [IEP-35] Migrate Communication Metrics.
[ https://issues.apache.org/jira/browse/IGNITE-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927602#comment-16927602 ] Nikolay Izhikov commented on IGNITE-12108: -- Hello, [~ibessonov] Thanks, for the contribution. I left some comments in pull request. Please, resolve them prior merge. > [IEP-35] Migrate Communication Metrics. > --- > > Key: IGNITE-12108 > URL: https://issues.apache.org/jira/browse/IGNITE-12108 > Project: Ignite > Issue Type: New Feature >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 2h > Remaining Estimate: 0h > > ||*Name*||*Description*|| > |communication.tcp.outboundMessagesQueueSize|Number of messages waiting to be > sent| > |communication.tcp.sentBytes|Total number of bytes received by current node| > |communication.tcp.receivedBytes|Total number of bytes sent by current node| > |communication.tcp.sentMessagesCount|Total number of messages sent by current > node| > |communication.tcp.receivedMessagesCount|Total number of messages received by > current node| > |communication.tcp.sentMessagesByType.|Total number of messages > with given type sent by current node| > |communication.tcp.receivedMessagesByType.|Total number of > messages with given type received by current node| > |communication.tcp..sentMessagesToNode|Total number of messages sent > by current node to the given node| > |communication.tcp..receivedMessagesFromNode|Total number of messages > received by current node from the given node| > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927586#comment-16927586 ] Ilya Kasnacheev commented on IGNITE-11894: -- Seems that you have two accounts, I've added both. > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a customer implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-11894: Assignee: Amit Chavan (was: Amit Chavan) > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a customer implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927580#comment-16927580 ] Ilya Kasnacheev commented on IGNITE-11894: -- It's better to write to developers list or discuss changes here. I don't know why you can't change the state, I will check this. > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a customer implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12163) CacheEntryEventType.Removed is not being rised
Alexandr Shapkin created IGNITE-12163: - Summary: CacheEntryEventType.Removed is not being rised Key: IGNITE-12163 URL: https://issues.apache.org/jira/browse/IGNITE-12163 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.7.5 Reporter: Alexandr Shapkin Assignee: Alexandr Shapkin Steps to reproduce: * Create a cache with user-defined type * Add an ICacheEntryEventListener in order to be notified of CacheEntryEventType.Removed events * Put a value in the cache * Remove that value Expected: CacheEntryEventType.Removed event get captured Actual: CacheEntryEventType.Updated event get captured Update: After these changes https://issues.apache.org/jira/browse/IGNITE-8714 New logic of detecting events (ContinuousQueryUtils.cs) now relies on the Object.Equals method which is not intuitive at all. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12160) Fix RPM packages build
[
https://issues.apache.org/jira/browse/IGNITE-12160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-12160:
--
Fix Version/s: (was: 2.7.6)
2.8
> Fix RPM packages build
> --
>
> Key: IGNITE-12160
> URL: https://issues.apache.org/jira/browse/IGNITE-12160
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Tue 10 Sep 2019 Peter Ivanov - 2.7.6-1}} date is in
> invalid format and should be fixed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12162) Add the cluster name to the promt message "--deactivate" the control.sh
Kirill Tkalenko created IGNITE-12162: Summary: Add the cluster name to the promt message "--deactivate" the control.sh Key: IGNITE-12162 URL: https://issues.apache.org/jira/browse/IGNITE-12162 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.8 Add the cluster name to the promt message "--deactivate" the control.sh -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12147) Thin client: Partitions response doesn't contain caches for which affinity awareness is not applicable
[ https://issues.apache.org/jira/browse/IGNITE-12147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927548#comment-16927548 ] Aleksey Plekhanov commented on IGNITE-12147: [~ptupitsyn] thanks for tips, I've fixed the tests. > Thin client: Partitions response doesn't contain caches for which affinity > awareness is not applicable > -- > > Key: IGNITE-12147 > URL: https://issues.apache.org/jira/browse/IGNITE-12147 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-23 > Time Spent: 0.5h > Remaining Estimate: 0h > > Partitions response never contains caches for which affinity awareness is not > applicable (unlike specified by the protocol) even if information for these > caches was explicitly requested. > .NET thin client also fails while processing messages for caches without > partitions information. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12153) Control.sh add test for checking that help and cache help output are not broken.
[
https://issues.apache.org/jira/browse/IGNITE-12153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927521#comment-16927521
]
Ignite TC Bot commented on IGNITE-12153:
{panel:title=Branch: [pull/6860/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4588263]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDisconnectAfterNetworkTimeout -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4588297]]
{color:#d04437}MVCC Cache 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4588331]]
{color:#d04437}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4588316]]
* IgnitePdsTestSuite4: PageLockTrackerManagerTest.testMemoryCalculation - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4588347buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh add test for checking that help and cache help output are not
> broken.
>
>
> Key: IGNITE-12153
> URL: https://issues.apache.org/jira/browse/IGNITE-12153
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should store "ideal" outputs in resorces and compare with current.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12161) [ML] Add support of different classloaders for client code
Alexey Platonov created IGNITE-12161: Summary: [ML] Add support of different classloaders for client code Key: IGNITE-12161 URL: https://issues.apache.org/jira/browse/IGNITE-12161 Project: Ignite Issue Type: Improvement Components: ml Reporter: Alexey Platonov Assignee: Alexey Platonov Currently we support just one classloader for unknown classes on server side. Potentially client can handle several classloaders and we should support this situation. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12160) Fix RPM packages build
[
https://issues.apache.org/jira/browse/IGNITE-12160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-12160:
--
Fix Version/s: 2.7.6
> Fix RPM packages build
> --
>
> Key: IGNITE-12160
> URL: https://issues.apache.org/jira/browse/IGNITE-12160
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Fix For: 2.7.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{Tue 10 Sep 2019 Peter Ivanov - 2.7.6-1}} date is in
> invalid format and should be fixed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12160) Fix RPM packages build
Peter Ivanov created IGNITE-12160:
-
Summary: Fix RPM packages build
Key: IGNITE-12160
URL: https://issues.apache.org/jira/browse/IGNITE-12160
Project: Ignite
Issue Type: Task
Reporter: Peter Ivanov
Assignee: Peter Ivanov
{{Tue 10 Sep 2019 Peter Ivanov - 2.7.6-1}} date is in
invalid format and should be fixed.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927441#comment-16927441
]
Lev Agafonov edited comment on IGNITE-12032 at 9/11/19 10:01 AM:
-
Hello,
I investigated the issue, seems that exception is thrown from [this
line|https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/internal/util/nio/GridNioServer.java#L2673]
I also was able to reproduce this stack trace with following test:
{code:java}
import java.sql._
import org.scalatest.{FunSuite, Matchers}
class OdbcTest extends FunSuite with Matchers {
test("Odbc close connection") {
val dsn = "Ignite_srv"
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
val t = new Thread() {
override def run() = {
val conn = DriverManager.getConnection(s"jdbc:odbc:$dsn")
//conn.close()
}
}
t.start()
Thread.sleep(100)
t.interrupt()
}
}
{code}
As you can see - there is commented 'conn.close()' in my test, and actually
this produces error.
Of course, it absolutely normal to close database connection, but it should be
done in proper way, by calling `close` connection method.
In my opinion throwing error on unexpectedly closed network connection - is
correct. In case it changed to INFO, the problem of loosing network connection
will be hidden.
So, I suppose that problem should be fixed by correct closing database
connection with adding `connection.close()` to client application, before
"{color:#00}process using this thin clients is finished".{color}
was (Author: levagafonov):
Hello,
I investigated the issue, seems that exception is thrown from [this
line|#L2673].]
I also was able to reproduce this stack trace with following test:
{code:java}
import java.sql._
import org.scalatest.{FunSuite, Matchers}
class OdbcTest extends FunSuite with Matchers {
test("Odbc close connection") {
val dsn = "Ignite_srv"
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
val t = new Thread() {
override def run() = {
val conn = DriverManager.getConnection(s"jdbc:odbc:$dsn")
//conn.close()
}
}
t.start()
Thread.sleep(100)
t.interrupt()
}
}
{code}
As you can see - there is commented 'conn.close()' in my test, and actually
this produces error.
Of course, it absolutely normal to close database connection, but it should be
done in proper way, by calling `close` connection method.
In my opinion throwing error on unexpectedly closed network connection - is
correct. In case it changed to INFO, the problem of loosing network connection
will be hidden.
So, I suppose that problem should be fixed by correct closing database
connection with `connection.close()` to client application, before
"{color:#00}process using this thin clients is finished".{color}
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.8
>
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at
[jira] [Comment Edited] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927441#comment-16927441
]
Lev Agafonov edited comment on IGNITE-12032 at 9/11/19 9:43 AM:
Hello,
I investigated the issue, seems that exception is thrown from [this
line|#L2673].]
I also was able to reproduce this stack trace with following test:
{code:java}
import java.sql._
import org.scalatest.{FunSuite, Matchers}
class OdbcTest extends FunSuite with Matchers {
test("Odbc close connection") {
val dsn = "Ignite_srv"
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
val t = new Thread() {
override def run() = {
val conn = DriverManager.getConnection(s"jdbc:odbc:$dsn")
//conn.close()
}
}
t.start()
Thread.sleep(100)
t.interrupt()
}
}
{code}
As you can see - there is commented 'conn.close()' in my test, and actually
this produces error.
Of course, it absolutely normal to close database connection, but it should be
done in proper way, by calling `close` connection method.
In my opinion throwing error on unexpectedly closed network connection - is
correct. In case it changed to INFO, the problem of loosing network connection
will be hidden.
So, I suppose that problem should be fixed by correct closing database
connection with `connection.close()` to client application, before
"{color:#00}process using this thin clients is finished".{color}
was (Author: levagafonov):
Hello,
I investigated the issue, seems that exception is thrown from [this
line|[https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/internal/util/nio/GridNioServer.java#L2673].]
I also was able to reproduce this stack trace with following test:
{code:java}
import java.sql._
import org.scalatest.{FunSuite, Matchers}
class OdbcTest extends FunSuite with Matchers {
test("Odbc close connection") {
val dsn = "Ignite_srv"
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
val t = new Thread() {
override def run() = {
val conn = DriverManager.getConnection(s"jdbc:odbc:$dsn")
//conn.close()
}
}
t.start()
Thread.sleep(100)
t.interrupt()
}
}
{code}
As you can see - there is commented 'conn.close()' in my test, and actually
this produces error.
Of course, it absolutely normal to close database connection, but it should be
done in proper way, by calling `close` connection method.
In my opinion throwing error on unexpectedly closed network connection - is
correct. In case it changed to INFO, the problem of loosing network connection
between thin client and will be hidden.
So, I suppose that problem should be fixed by correct closing database
connection with `connection.close()` to client application, before
"{color:#00}process using this thin clients is finished".{color}
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.8
>
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at
[jira] [Commented] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927441#comment-16927441
]
Lev Agafonov commented on IGNITE-12032:
---
Hello,
I investigated the issue, seems that exception is thrown from [this
line|[https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/internal/util/nio/GridNioServer.java#L2673].]
I also was able to reproduce this stack trace with following test:
{code:java}
import java.sql._
import org.scalatest.{FunSuite, Matchers}
class OdbcTest extends FunSuite with Matchers {
test("Odbc close connection") {
val dsn = "Ignite_srv"
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver")
val t = new Thread() {
override def run() = {
val conn = DriverManager.getConnection(s"jdbc:odbc:$dsn")
//conn.close()
}
}
t.start()
Thread.sleep(100)
t.interrupt()
}
}
{code}
As you can see - there is commented 'conn.close()' in my test, and actually
this produces error.
Of course, it absolutely normal to close database connection, but it should be
done in proper way, by calling `close` connection method.
In my opinion throwing error on unexpectedly closed network connection - is
correct. In case it changed to INFO, the problem of loosing network connection
between thin client and will be hidden.
So, I suppose that problem should be fixed by correct closing database
connection with `connection.close()` to client application, before
"{color:#00}process using this thin clients is finished".{color}
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.8
>
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>
> 04)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>
> oServer.java:2389)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>
> 6)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)*
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node,
> so, we shouldn't print exception in the log. We should replace it with
> something like INFO message about ODBC client disconnection.
> Thread from user list:
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-11843) [SQL] sqlline.sh trows NPE on invalid(inaccessible) JDBC URL on start
[ https://issues.apache.org/jira/browse/IGNITE-11843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927424#comment-16927424 ] Aleksey Vysotin commented on IGNITE-11843: -- [~boringMax], is this issue still relevant? I would like to give it a try. > [SQL] sqlline.sh trows NPE on invalid(inaccessible) JDBC URL on start > - > > Key: IGNITE-11843 > URL: https://issues.apache.org/jira/browse/IGNITE-11843 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Losevskoy Maxim >Priority: Minor > Labels: easyfix > Attachments: image-2019-05-11-23-29-21-399.png > > > Please see screenshot attached. > It would be preferable to see human-friendly message that URL is invalid/not > accessible -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12135) Rework GridCommandHandlerTest
[ https://issues.apache.org/jira/browse/IGNITE-12135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927395#comment-16927395 ] Dmitriy Govorukhin commented on IGNITE-12135: - [~ktkale...@gridgain.com]Merged to master. Thanks for your contribution! > Rework GridCommandHandlerTest > - > > Key: IGNITE-12135 > URL: https://issues.apache.org/jira/browse/IGNITE-12135 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There are 50+ tests. In each test we are start and stop nodes. I think we > could split tests at least to two groups: > # Tests on normal behaviour. We could start nodes before all tests and stop > them after all tests. > # Tests required start new cluster before each test. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12054) Upgrade Spark module to 2.4
[
https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927325#comment-16927325
]
Nikolay Izhikov commented on IGNITE-12054:
--
Hello, [~zaleslaw]
The main issue with upgrading to 2.4 and support both 2.3 and 2.5 is changes in
Spark internal API that was introduced in 2.3 version.
As you may know, Ignite - Spark integration uses some internal API
({{ExternalCatalog}}) and leverage on other parts of close-to-internal parts of
Spark(query parser and optimizer). That code was changed in 2.4 and we can't
simply change the version in pom.xml. We need to fix our code for the new Spark
behaviour.
I tried to do so but fail to do it quickly.
If you want to take care of this upgrade, please, do.
As for support both version, it seems we should have different modules or
similar to do so.
[~dmagda] Ignite, in the past, had those kinds of modules, that support two
different versions of some external library.
Should we do the similar and create spark_24 and spark_25 modules with the very
similar(but still different) codebase?
> Upgrade Spark module to 2.4
> ---
>
> Key: IGNITE-12054
> URL: https://issues.apache.org/jira/browse/IGNITE-12054
> Project: Ignite
> Issue Type: Task
> Components: spark
>Affects Versions: 2.7.5
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.8
>
>
> Users can't use APIs that are already available in Spark 2.4:
> https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite
> Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as
> a separate module that can support multiple Spark versions.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (IGNITE-12054) Upgrade Spark module to 2.4
[
https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927325#comment-16927325
]
Nikolay Izhikov edited comment on IGNITE-12054 at 9/11/19 7:34 AM:
---
Hello, [~zaleslaw]
The main issue with upgrading to 2.4 and support both 2.3 and 2.5 is changes in
Spark internal API that were introduced in 2.3 version.
As you may know, Ignite - Spark integration uses some internal API
({{ExternalCatalog}}) and leverage on other parts of close-to-internal parts of
Spark(query parser and optimizer). That code was changed in 2.4 and we can't
simply change the version in pom.xml. We need to fix our code for the new Spark
behaviour.
I tried to do so but fail to do it quickly.
If you want to take care of this upgrade, please, do.
As for support both version, it seems we should have different modules or
similar to do so.
[~dmagda] Ignite, in the past, had those kinds of modules, that support two
different versions of some external library.
Should we do the similar and create spark_24 and spark_25 modules with the very
similar(but still different) codebase?
was (Author: nizhikov):
Hello, [~zaleslaw]
The main issue with upgrading to 2.4 and support both 2.3 and 2.5 is changes in
Spark internal API that was introduced in 2.3 version.
As you may know, Ignite - Spark integration uses some internal API
({{ExternalCatalog}}) and leverage on other parts of close-to-internal parts of
Spark(query parser and optimizer). That code was changed in 2.4 and we can't
simply change the version in pom.xml. We need to fix our code for the new Spark
behaviour.
I tried to do so but fail to do it quickly.
If you want to take care of this upgrade, please, do.
As for support both version, it seems we should have different modules or
similar to do so.
[~dmagda] Ignite, in the past, had those kinds of modules, that support two
different versions of some external library.
Should we do the similar and create spark_24 and spark_25 modules with the very
similar(but still different) codebase?
> Upgrade Spark module to 2.4
> ---
>
> Key: IGNITE-12054
> URL: https://issues.apache.org/jira/browse/IGNITE-12054
> Project: Ignite
> Issue Type: Task
> Components: spark
>Affects Versions: 2.7.5
>Reporter: Denis Magda
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.8
>
>
> Users can't use APIs that are already available in Spark 2.4:
> https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite
> Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as
> a separate module that can support multiple Spark versions.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
