[jira] [Created] (IGNITE-10937) Support data page scan for JDBC/ODBC

[Sergi Vladykin (JIRA)]

Sergi Vladykin created IGNITE-10937:
---

 Summary: Support data page scan for JDBC/ODBC
 Key: IGNITE-10937
 URL: https://issues.apache.org/jira/browse/IGNITE-10937
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergi Vladykin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10936) Web Console: Add support for single select mode on ui-grid.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-10936:
-

 Summary: Web Console: Add support for single select mode on 
ui-grid.
 Key: IGNITE-10936
 URL: https://issues.apache.org/jira/browse/IGNITE-10936
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.8


Our grid support multi-select, but we also need support for single-select,



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10935) "Invalid node order" error occurs while cycle cluster nodes restart

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-10935:


 Summary: "Invalid node order" error occurs while cycle cluster 
nodes restart
 Key: IGNITE-10935
 URL: https://issues.apache.org/jira/browse/IGNITE-10935
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitry Sherstobitov


Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
{code:java}
Exception in thread "tcp-disco-msg-worker-#2" java.lang.AssertionError: Invalid 
node order: TcpDiscoveryNode [id=9a332aa3-3d60-469a-9ff5-3deee8918451, 
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 172.25.1.40], 
sockAddrs=[/172.25.1.40:47501, /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, 
/172.17.0.1:47501], discPort=47501, order=0, intOrder=16, 
lastExchangeTime=1547486771047, loc=false, ver=2.4.13#20190114-sha1:a7667ae6, 
isClient=false]
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:51)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing$1.apply(TcpDiscoveryNodesRing.java:48)
at org.apache.ignite.internal.util.lang.GridFunc.isAll(GridFunc.java:2030)
at org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9635)
at org.apache.ignite.internal.util.IgniteUtils.arrayList(IgniteUtils.java:9608)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.nodes(TcpDiscoveryNodesRing.java:625)
at 
org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.visibleNodes(TcpDiscoveryNodesRing.java:145)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.notifyDiscovery(ServerImpl.java:1429)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$2400(ServerImpl.java:176)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddFinishedMessage(ServerImpl.java:4565)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2732)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2554)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6955)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2634)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)




Collaps{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Best Effort Affinity for thin clients

[Pavel Tupitsyn]

Hi Igor,

Looks good to me in general, except changing the response message format so
much.

Can we use a separate message to retrieve affinity topology version?
Set a flag as you describe, but don't put the version data into standard
response?

Just to keep the protocol cleaner, follow SRP to some extent, and keep
client implementations simpler
(especially for clients that ignore this flag).

Thoughts?

On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego  wrote:

> Hello guys,
>
> I've updated IEP page [1] describing proposed solution in more details and
> proposing some changes for a protocol.
>
> Please, take a look and let me know what you think.
>
> [1] -
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients
>
> Best Regards,
> Igor
>
>
> On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov 
> wrote:
>
> > Denis,
> >
> > Yes, in principle we can extend it. We are going to implement it in
> > subsequent phases of this IEP.
> >
> > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda 
> wrote:
> > >
> > > > Folks,
> > > >
> > > > Feel that this functionality can be extended to the automatic
> > reconnect,
> > > > can't it? Presently we require to provide a static list of IPs to be
> > used
> > > > at a reconnect time. By having a partition map of all the nodes, the
> > thin
> > > > client should be able to automate this piece.
> > > >
> > >
> > > Not sure if static IP list can be avoided. What Igor is suggesting is
> > that
> > > we try to pick the best node out of the static IP  list.
> > >
> > > D.
> > >
> >
>

[jira] [Created] (IGNITE-10934) Order fields don't work in ignite field queries

[Gaurav Rawat (JIRA)]

Gaurav Rawat created IGNITE-10934:
-

 Summary: Order fields don't work in ignite field queries 
 Key: IGNITE-10934
 URL: https://issues.apache.org/jira/browse/IGNITE-10934
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.7
Reporter: Gaurav Rawat


There is an issue when we use fields woth a field such as order . seems the H2 
query engine recognizes this is a  keyword . 

example query :

SELECT fund.fund_id, fund.close_dt, fund.idea_id, pm .order  FROM "fund".FUND 
fund LEFT JOIN "pm ".PM pm ON fund.FUND_ID = pm .FUND_ID limit 40

 

error : 

 
{code:java}
Caused by: org.h2.jdbc.JdbcSQLException: Syntax error in SQL statement .
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
 at org.h2.message.DbException.getSyntaxError(DbException.java:217)
 at org.h2.command.Parser.readColumnIdentifier(Parser.java:3507)
 at org.h2.command.Parser.readTermObjectDot(Parser.java:2964)
 at org.h2.command.Parser.readTerm(Parser.java:3095)
 at org.h2.command.Parser.readFactor(Parser.java:2587)
 at org.h2.command.Parser.readSum(Parser.java:2574)
 at org.h2.command.Parser.readConcat(Parser.java:2544)
 at org.h2.command.Parser.readCondition(Parser.java:2370)
 at org.h2.command.Parser.readAnd(Parser.java:2342)
 at org.h2.command.Parser.readExpression(Parser.java:2334)
 at org.h2.command.Parser.parseSelectSimpleSelectPart(Parser.java:2245)
 
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10933) Node may hang on join to topology and not move forward

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-10933:
--

 Summary: Node may hang on join to topology and not move forward
 Key: IGNITE-10933
 URL: https://issues.apache.org/jira/browse/IGNITE-10933
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


Several nodes join to topology simultaneously and hang on a long time.

That can be on first start all cluster nodes or join nodes to completed 
topology.

In the logs of problem nodes can see messages:

{noformat}

2019-01-11 18:37:39.296 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi] Node 
has not been connected to topology and will repeat join process. Check remote 
nodes logs for possible error messages. Note that large topology may require sig
nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration 
property if getting this message on the starting nodes [networkTimeout=5000]

 2019-01-11 18:43:09.374 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi] Node 
has not been connected to topology and will repeat join process. Check remote 
nodes logs for possible error messages. Note that large topology may require sig
nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration 
property if getting this message on the starting nodes [networkTimeout=5000]

...

{noformat}

and this long time without others.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Best Effort Affinity for thin clients

[Igor Sapego]

Hello guys,

I've updated IEP page [1] describing proposed solution in more details and
proposing some changes for a protocol.

Please, take a look and let me know what you think.

[1] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients

Best Regards,
Igor


On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov 
wrote:

> Denis,
>
> Yes, in principle we can extend it. We are going to implement it in
> subsequent phases of this IEP.
>
> On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan 
> wrote:
>
> > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda  wrote:
> >
> > > Folks,
> > >
> > > Feel that this functionality can be extended to the automatic
> reconnect,
> > > can't it? Presently we require to provide a static list of IPs to be
> used
> > > at a reconnect time. By having a partition map of all the nodes, the
> thin
> > > client should be able to automate this piece.
> > >
> >
> > Not sure if static IP list can be avoided. What Igor is suggesting is
> that
> > we try to pick the best node out of the static IP  list.
> >
> > D.
> >
>

[jira] [Created] (IGNITE-10932) Remove inheritance between VisorIdleVerifyTaskArg and VisorIdleVerifyDumpTaskArg

[Sergey Antonov (JIRA)]

Sergey Antonov created IGNITE-10932:
---

 Summary: Remove inheritance between VisorIdleVerifyTaskArg and 
VisorIdleVerifyDumpTaskArg
 Key: IGNITE-10932
 URL: https://issues.apache.org/jira/browse/IGNITE-10932
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.8
Reporter: Sergey Antonov
 Fix For: 3.0


VisorIdleVerifyDumpTaskArg shouldn't depends from VisorIdleVerifyTaskArg, 
because of it makes class extension difficult. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10931) Get rid of GridTestUtils#addTestIfNeeded

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-10931:
--

 Summary: Get rid of GridTestUtils#addTestIfNeeded
 Key: IGNITE-10931
 URL: https://issues.apache.org/jira/browse/IGNITE-10931
 Project: Ignite
  Issue Type: Task
Reporter: Eduard Shangareev


It could be replaced with Assume.

It will allow to remove some suites with replacing them by new TC 
configuration. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10929) After huge load on cluster and restart with walCompactionEnabled=True warning on log

[ARomantsov (JIRA)]

ARomantsov created IGNITE-10929:
---

 Summary: After huge load on cluster and restart with 
walCompactionEnabled=True warning on log
 Key: IGNITE-10929
 URL: https://issues.apache.org/jira/browse/IGNITE-10929
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: ARomantsov
 Fix For: 2.8



{code:java}
[15:08:14,610][WARNING][wal-file-compressor-%null%-3-#70][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0001.wal, exists: 
false
[15:08:15,661][WARNING][wal-file-compressor-%null%-0-#66][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0005.wal, exists: 
false
[15:08:16,540][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0009.wal, exists: 
false
[15:08:17,354][WARNING][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0013.wal, exists: 
false
[15:08:18,161][WARNING][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0017.wal, exists: 
false
[15:08:18,161][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0017.wal, exists: 
false
[15:08:18,161][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0018.wal, exists: 
false
[15:08:18,987][WARNING][wal-file-compressor-%null%-3-#70][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0020.wal, exists: 
false
[15:08:18,987][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0020.wal, exists: 
false
[15:08:18,998][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0023.wal, exists: 
false
[15:08:23,211][WARNING][wal-file-compressor-%null%-2-#69][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0028.wal, exists: 
false
[15:08:23,211][WARNING][wal-file-compressor-%null%-3-#70][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0029.wal, exists: 
false
[15:08:24,264][WARNING][wal-file-compressor-%null%-0-#66][FileWriteAheadLogManager]
 Failed to remove obsolete WAL segment (make sure the process has enough 
rights):  my_path/work/db/wal/archive/node_1_1/0033.wal, exists: 
false
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10930) [TC Bot] Support PR-less contributions

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-10930:
---

 Summary: [TC Bot] Support PR-less contributions
 Key: IGNITE-10930
 URL: https://issues.apache.org/jira/browse/IGNITE-10930
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


An Apache Ignite committer can prepare issue fix with origin/ignite-1 
branch. And this contributions testing does not require any PR creations, 
because TC RunAll may be created without it.

Support contributions detection by provided TC run for branches matching
ignite-N, where N=0-9

If such RunAll presented for any tracked branch and JIRA issue is in PA state, 
we may display these branches as addition to PRs, show its report and setup 
VISA into IGNITE-N ticket.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10928) After huge load on cluster and restart with walCompactionEnabled=True errors on log

[ARomantsov (JIRA)]

ARomantsov created IGNITE-10928:
---

 Summary: After huge load on cluster and restart with 
walCompactionEnabled=True errors on log
 Key: IGNITE-10928
 URL: https://issues.apache.org/jira/browse/IGNITE-10928
 Project: Ignite
  Issue Type: Bug
Reporter: ARomantsov



{code:java}







{code}



{code:java}
[15:30:56,809][INFO][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
 Stopping WAL iteration due to an exception: Failed to read WAL record at 
position: 28310114 size: -1, ptr=FileWALPointer [idx=35, fileOff=28310114, 
len=0]
[15:30:56,811][INFO][wal-file-compressor-%null%-3-#70][FileWriteAheadLogManager]
 Stopping WAL iteration due to an exception: Failed to read WAL record at 
position: 28303753 size: -1, ptr=FileWALPointer [idx=36, fileOff=28303753, 
len=0]
[15:30:56,811][SEVERE][wal-file-compressor-%null%-1-#68][FileWriteAheadLogManager]
 Compression of WAL segment [idx=35] was skipped due to unexpected error
class org.apache.ignite.IgniteCheckedException: Failed to read WAL record at 
position: 28310114 size: -1
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.handleRecordException(AbstractWalRecordsIterator.java:292)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:258)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advance(AbstractWalRecordsIterator.java:154)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.SingleSegmentLogicalRecordsIterator.advance(SingleSegmentLogicalRecordsIterator.java:119)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:123)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.onNext(AbstractWalRecordsIterator.java:52)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.nextX(GridCloseableIteratorAdapter.java:41)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.compressSegmentToFile(FileWriteAheadLogManager.java:2039)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body0(FileWriteAheadLogManager.java:1974)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressorWorker.body(FileWriteAheadLogManager.java:1950)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to read WAL 
record at position: 28310114 size: -1
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readWithCrc(RecordV1Serializer.java:394)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer.readRecord(RecordV2Serializer.java:235)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.AbstractWalRecordsIterator.advanceRecord(AbstractWalRecordsIterator.java:243)
... 10 more
Caused by: java.nio.channels.ClosedByInterruptException
at 
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:164)
at 
org.apache.ignite.internal.processors.cache.persistence.file.RandomAccessFileIO.read(RandomAccessFileIO.java:58)
at 
org.apache.ignite.internal.processors.cache.persistence.file.FileIODecorator.read(FileIODecorator.java:51)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.io.SimpleFileInput.ensure(SimpleFileInput.java:119)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.io.FileInput$Crc32CheckingFileInput.ensure(FileInput.java:89)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.io.FileInput$Crc32CheckingFileInput.readFully(FileInput.java:152)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV2Serializer$2.readWithHeaders(RecordV2Serializer.java:149)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordV1Serializer.readWithCrc(RecordV1Serializer.java:373)
... 12 more
Suppressed: class 
org.apache.ignite.internal.processors.cache.persistence.wal.crc.IgniteDataIntegrityViolationException:
 val: 1241861030 writtenCrc: 20736
at 
org.apache.ignite.internal.processors.cache.persistence.wal.io.FileInput$Crc32CheckingFileInput.close(FileInput.java:106)
 

Re: proposed realization KILL QUERY command

[Юрий]

Hi Igniters,

Earlier we discuss about columns for running queries. Let's summarize it
and continue discussion for not closed questions.

What we had:
*name of view**: *running_queries
*columns and meaning*:
   query_id -  unique id of query on node
   node_id - initial node of request.
   sql - text of query
   schema_name - name of sql schema
   duration - duration in milliseconds from start of
execution.

All of this columns are clear, except query_id.
Let's keep in mind that the query_id column of the view coupled with KILL
QUERY command.

We have the following variants what is query_id:
1) It's string, internally with two parts separated by '.'(it can be other
separator): numeric node order and numeric query counter unique for local
node, e.g. '172.67321'. For this case query id will be really unique across
a cluster, but can be looks a strange for a user, especially in case we
will have ability to kill all queries on a node, when user should get first
part before separator to use it, e.g. KILL QUERY '172.*'.

2) Just single numeric id, unique for local node, e.g '127'. In this case
we need more complicated syntax for further KILL QUERY command, which lead
to use two columns from the view, e.g. KILL QUERY WHERE nodeId=
37d7afd8-b87d-4aa1-b3d1-c1c03380 and queryId=67321

3) Use base16String(concat(node,".",queryID) as query id, e.g. '
3132332E393337'. Then we hide internal structure of id and such id will be
unique across a cluster. However we will need use complicated syntax for
KILL QUERY command as for 2nd case.

4) Just single numeric id, unique for local node, e.g '127'. But user
should use two columns to merge it and create query id unique in a cluster.
Such approach use  by Oracle:ALTER SYSTEM CANCEL SQL 'SID, SERIAL, SQL_ID'.
In this case user will know real meaning of each part of passed parameter
for KILL QUERY command. But it hard to use.

5) Any other approach you can think of

If be honestly I prefer first variant, it looks simple to use by user (it
require read a docs, but any case it required for any use cases).

Lets discuss it again and chose better approach to expose query_id column
for Ignite. Also confirm list of columns.

вт, 27 нояб. 2018 г. в 11:00, Vladimir Ozerov :

> Yes ("нуы")
>
> On Tue, Nov 27, 2018 at 10:56 AM Павлухин Иван 
> wrote:
>
> > I believe that the meaning was:
> >
> > > I propose to start with running queries VIEW first.
> > вт, 27 нояб. 2018 г. в 10:47, Vladimir Ozerov :
> > >
> > > I propose to start with running queries мшуц first. Once we have it, it
> > > will be easier to agree on final command syntax.
> > >
> > > On Fri, Nov 23, 2018 at 9:32 AM Павлухин Иван 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > May be I am a little bit late with my thoughts about a command
> syntax.
> > > > How do I see it is going to be used:
> > > > 1. A user is able to kill a query by unique id belonging only to this
> > > > query.
> > > > 2. A user is able to kill all queries started by a specific node.
> > > > For killing a single query we must identify it by unique id which is
> > > > going to be received directly from Ignite (e.g. running queries view)
> > > > and not calculated by user. Internally the id is compound but why
> > > > cannot we convert it to opaque integer or string which hides real
> > > > structure? E.g. base16String(concat(nodeOrder.toString(), ".",
> > > > queryIdOnNode.toString())) The syntax could be KILL QUERY '123' or
> > > > KILL QUERY WHERE queryId = '123'
> > > > For killing all queries started by some node we need to use only node
> > > > order (or id). It could be like KILL QUERY WHERE nodeOrder = 34.
> > > > чт, 22 нояб. 2018 г. в 12:56, Denis Mekhanikov <
> dmekhani...@gmail.com
> > >:
> > > > >
> > > > > Actually, option with separate parameters was mentioned in another
> > thread
> > > > >
> > > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/proposed-design-for-thin-client-SQL-management-and-monitoring-view-running-queries-and-kill-it-tp37713p38056.html
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 22 нояб. 2018 г. в 08:51, Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Problems with separate parameters are explained above.
> > > > > >
> > > > > > чт, 22 нояб. 2018 г. в 3:23, Denis Magda :
> > > > > >
> > > > > > > Vladimir,
> > > > > > >
> > > > > > > All of the alternatives are reminiscent of mathematical
> > operations.
> > > > Don't
> > > > > > > look like a SQL command. What if we use a SQL approach
> > introducing
> > > > named
> > > > > > > parameters:
> > > > > > >
> > > > > > > KILL QUERY query_id=10 [AND node_id=5]
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > > On Wed, Nov 21, 2018 at 4:11 AM Vladimir Ozerov <
> > > > voze...@gridgain.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > >

Re: System Worker Failure Handler on local laptop

[Andrey Gura]

Guys,

there is no problem in blocking thread monitroing. Please, look at the
error message: "failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.IgniteCheckedException: Node is stopping: grid-2]]". Some
critical worker was terminated unexpectedly. So the problem isn't
related with any timeouts. It's a bug that should be investigated.



On Thu, Dec 27, 2018 at 9:27 PM Denis Magda  wrote:
>
> Folks,
>
> What are the current timeouts? We need to know the probability of failures
> in dev environment. This affect usability.
>
> --
> Denis
>
> On Thu, Dec 27, 2018 at 4:59 AM Alexey Goncharuk 
> wrote:
>
> > Nikolay,
> >
> > Yes, the fix is already in master. Looks like I was wrong, in your case
> > failure handler is triggered by 'Node is stopping: grid-2'. Can you please
> > share the full trace?
> >
> >
> >
> > чт, 27 дек. 2018 г. в 12:41, Nikolay Izhikov :
> >
> > > Alexey
> > >
> > > Fix for this issue already in master?
> > > I run tests on current master.
> > >
> > > > Should we somehow announce it on the user-list or highlight on
> > readme.io
> > > ?
> > >
> > > I don't think our users will be happy to users stuck with this behavior
> > in
> > > production.
> > >
> > > Am I understand you correctly:
> > > If someone use 2.7. release and Ignite process slowing for a few seconds
> > > for any reason(low-end hardwre, VM pause, other processes grab the
> > > resources) then Ignite node will be stopped?
> > >
> > > > This is the issue I mentioned in "Critical worker threads liveness
> > > checking
> > > drawbacks" topic
> > >
> > > Thanks for the link, I will check it out.
> > >
> > > чт, 27 дек. 2018 г. в 12:24, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Hi Nikolay,
> > > >
> > > > This is the issue I mentioned in "Critical worker threads liveness
> > > checking
> > > > drawbacks" topic which I was expecting to be included to Ignite 2.7,
> > but
> > > it
> > > > was not. To workaround the issue, you should set
> > > > DataStorageConfiguration#setCheckpointReadLockTimeout to 0.
> > > >
> > > > Should we somehow announce it on the user-list or highlight on
> > readme.io
> > > ?
> > > >
> > > > чт, 27 дек. 2018 г. в 11:57, Nikolay Izhikov :
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I run into issue with critical system worker failure handler.
> > > > > I just run `IgniteDataFrameSuite` and it terminates on random test.
> > > > > My laptop doesn't have bleeding edge hardware, so tests can take
> > > > > significant amount of time.
> > > > > Looks like our watch dog too aggressive on development environment
> > > > >
> > > > > Can you please, help me. What should I do to configure or turn off
> > > watch
> > > > > dog?
> > > > > Should we relax it a little bit? At least for a test environment.
> > > > >
> > > > > Error message contains following message:
> > > > >
> > > > > ```
> > > > > [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root]
> > > > > Critical system error detected. Will be handled accordingly to
> > > configured
> > > > > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> > > > > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> > > > > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> > > > > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> > > > > o.a.i.IgniteCheckedException: Node is stopping: grid-2]]
> > > > > class org.apache.ignite.IgniteCheckedException: Node is stopping:
> > > grid-2
> > > > > ```
> > > > >
> > > >
> > >
> >

[jira] [Created] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)

[Oleg Ignatenko (JIRA)]

Oleg Ignatenko created IGNITE-10927:
---

 Summary: Relieve JUnit3TestLegacySupport from inheriting 
deprecated junit.framework.Assert (follow-up to IGNITE-10177)
 Key: IGNITE-10927
 URL: https://issues.apache.org/jira/browse/IGNITE-10927
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 2.7
Reporter: Oleg Ignatenko


{{JUnit3TestLegacySupport}} currently inherits deprecated 
{{junit.framework.Assert}}. This was done only in order to minimize risky code 
changes when tests were migrating from Junit 3, after {{GridAbstractTest}} has 
dropped inheriting {{junit.framework.TestCase}}.

Now that migration is over it is less risky to cleanup project from deprecated 
assert methods and drop the harmful inheritance. In order to make this smoother 
and minimize amount of test changes, after inheritance is dropped, 
{{JUnit3TestLegacySupport}} should be extended with a set of "temporary patch" 
methods that would delegate most popular assertions used by subclasses to 
respective methods of {{org.junit.Assert}}.

Mentioned temporary patch methods, in turn, should get {{@Deprecated}} 
annotation and respective {{2deprecation}} noticed in javadocs that would 
encourage developers to (safely and gradually) change them to direct 
invocations and static imports of respective Assert methods instead of using 
those inherited from superclass. These patch methods should be declared 
protected final or protected static final, to minimize their applicability and 
prevent them spreading more than intended.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: How to update Documentation 2.8 docs? - IGNITE-8532 [ML] GA Grid - Implement Roulette Wheel Selection

[techbysample]

Igniters,

Would you please advise on when 2.8 documentation will be available?

I need to make updates to Genetic Algorithm section of ML to support

ticket: https://issues.apache.org/jira/browse/IGNITE-8532

Best,
Turik



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: [IGNITE-10925] After upgrading 2.7 getting Unexpected error occurred during unmarshalling

[Prasad Bhalerao]

Hi,

I am able to create a reproducer for this issue. I have also created a JIRA
IGNITE-10925   for this
issue.

Reproducer: https://github.com/prasadbhalerao1983/IgniteIssueReproducer.git

Step to Reproduce:

1) First Run com.example.demo.Server class as a java program

2) Then run com.example.demo.Client as java program.

Thanks,
Prasad

On Sat, Jan 12, 2019 at 11:17 AM Prasad Bhalerao <
prasadbhalerao1...@gmail.com> wrote:

> No I am not using zookeeper discovery.
> Using TcpDiscoveryVmIpFinder.
>
> Can someone please explain on what event cacheMetrics in TcpDiscoveryNode
> gets populated. It is not getting populated in standalone program.
>
> If it gets populated then I might be able to reproduce this case.
>
> On Fri 11 Jan, 2019, 8:28 PM Ilya Kasnacheev  wrote:
>
>> Hello!
>>
>> Have you tried enabling Zookeeper in your reproducer? I have a hunch that
>> they are linked: this behavior is affected by zookeeper discovery.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пт, 11 янв. 2019 г. в 17:44, Prasad Bhalerao <
>> prasadbhalerao1...@gmail.com>:
>>
>>> I tried to reproduce this in standalone program. But the thing is cache
>>> metrics map in TcpDiscoveryNode is empty even after setting
>>> statisticEnabled to true on all caches.
>>> So the flow does not enter into serializr/deserialize cacheMetrics block.
>>>
>>> Any idea how the cacheMetrics gets populated. On which event?
>>>
>>>
>>> Thanks,
>>> Prasad
>>>
>>> On Fri 11 Jan, 2019, 7:55 PM ilya.kasnacheev >> wrote:
>>>
 Hello!

 I think the problem was introduced by
 https://issues.apache.org/jira/browse/IGNITE-6846 which does look very
 suspicious, however it is strange that it does not reproduce right away.

 I could try and devise a fix but I could not reproduce this behavior in
 any
 of tests. If you could do a reproducer project that would be awesome.

 Regards,



 --
 Sent from: http://apache-ignite-users.70518.x6.nabble.com/

>>>

[jira] [Created] (IGNITE-10926) ZookeeperDiscoverySpi: client does not survive after several cluster restarts

[Amelchev Nikita (JIRA)]

Amelchev Nikita created IGNITE-10926:


 Summary: ZookeeperDiscoverySpi: client does not survive after 
several cluster restarts
 Key: IGNITE-10926
 URL: https://issues.apache.org/jira/browse/IGNITE-10926
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
 Fix For: 2.8


{{ZookeeperDiscoveryImpl#cleanupPreviousClusterData}} can delete alive node of 
a client in case of low internal order.
Steps to reproduce: 
1. Start server and client.
2. Stop the server and wait for the client disconnected.
3. Start and stop the server. The server hasn't time to process client join 
request.
4. Start server. It will delete alive client node because the client has low 
internal order. The client will never connect.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10925) Failure to submit affinity task from client node

[Prasad (JIRA)]

Prasad created IGNITE-10925:
---

 Summary: Failure to submit affinity task from client node
 Key: IGNITE-10925
 URL: https://issues.apache.org/jira/browse/IGNITE-10925
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Prasad


Getting following exception while submitting the affinity task from client node 
to server node.

Before submitting the affinity task ignite first gets the affinity cached 
function (AffinityInfo) by submitting the cluster wide task "AffinityJob". But 
while in the process of retrieving the output of this AffinityJob, ignite 
deserializes this output. I am getting exception while deserailizing this 
output.

Code fails while in-marshalling cachesnapshotmetrics on client node.

 

 
{noformat}
2019-01-14 15:37:02.723 ERROR 10712 --- [springDataNode%] 
o.a.i.i.processors.task.GridTaskWorker   : Error deserializing job response: 
GridJobExecuteResponse [nodeId=e9a24c20-0d00-4808-b2f5-13e1ce35496a, 
sesId=76324db4861-1d85ad49-5b25-454a-b69c-d8685cfc73b0, 
jobId=86324db4861-1d85ad49-5b25-454a-b69c-d8685cfc73b0, gridEx=null, 
isCancelled=false, retry=null]
org.apache.ignite.IgniteCheckedException: Failed to unmarshal object with 
optimized marshaller
 at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10146) 
~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:831)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1081)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1316)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
 [ignite-core-2.7.0.jar:2.7.0]
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[na:1.8.0_144]
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[na:1.8.0_144]
 at java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to unmarshal 
object with optimized marshaller
 at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1765)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:102)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10140) 
~[ignite-core-2.7.0.jar:2.7.0]
 ... 10 common frames omitted
Caused by: org.apache.ignite.IgniteCheckedException: Failed to deserialize 
object with given class loader: 
[clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, err=Failed to deserialize 
object [typeName=org.apache.ignite.internal.util.lang.GridTuple3]]
 at 
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:237)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1762)
 ~[ignite-core-2.7.0.jar:2.7.0]
 ... 16 common frames omitted
Caused by: java.io.IOException: Failed to deserialize object 
[typeName=org.apache.ignite.internal.util.lang.GridTuple3]
 at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:350)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
 ~[ignite-core-2.7.0.jar:2.7.0]
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:416) 
~[na:1.8.0_144]
 at 
org.apache.ignite.inter

[jira] [Created] (IGNITE-10924) Invalid message type blocks Communication SPI

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-10924:
---

 Summary: Invalid message type blocks Communication SPI
 Key: IGNITE-10924
 URL: https://issues.apache.org/jira/browse/IGNITE-10924
 Project: Ignite
  Issue Type: Bug
  Components: messaging
Affects Versions: 2.7
Reporter: Roman Guseinov
 Attachments: InvalidMessageTypeTest.java

If node A sends a message with a type which is unknown for node B then node B 
will fail to process the message and node A will retry sending that message 
infinitely. Communication SPI will be blocked. Also, logs from node B will 
contain a lot of error messages like the following:
{code:java}
[2019-01-14 
18:00:59,957][ERROR][grid-nio-worker-tcp-comm-0-#25%server%][TcpCommunicationSpi]
 Closing NIO session because of unhandled exception.
class org.apache.ignite.internal.util.nio.GridNioException: Invalid message 
type: 32767
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2409)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2150)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1791)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteException: Invalid message type: 32767
at 
org.apache.ignite.internal.managers.communication.GridIoMessageFactory.create(GridIoMessageFactory.java:1164)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$6.create(TcpCommunicationSpi.java:2322)
at 
org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:81)
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:133)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3546)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at 
org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1300)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2383)
... 4 more
{code}

Reproducer is attached [^InvalidMessageTypeTest.java].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10923) Minor cleanup

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-10923:
-

 Summary: Minor cleanup
 Key: IGNITE-10923
 URL: https://issues.apache.org/jira/browse/IGNITE-10923
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10922) Add a way to override any configuration property via a system property

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-10922:
---

 Summary: Add a way to override any configuration property via a 
system property
 Key: IGNITE-10922
 URL: https://issues.apache.org/jira/browse/IGNITE-10922
 Project: Ignite
  Issue Type: Bug
Reporter: Stanislav Lukyanov


>From time to time we introduce system properties as a shorthand way to set a 
>specific configuration parameter, e.g. IGNITE-10921.

It would be nice to have a standard way to override any property like that.
E.g. instead of 
-DIGNITE_CONSISTENT_ID=foo 
we would use something like
-Dorg.apache.ignite.IgniteConfiguration.consistentId=foo

This mechanism should work for any configuration sections. It seems that it is 
rather hard to implement for complex types, but perhaps we could start by doing 
this for simple properties (strings, numbers, etc).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-10920:
--

 Summary: Optimize HistoryAffinityAssignment heap usage.
 Key: IGNITE-10920
 URL: https://issues.apache.org/jira/browse/IGNITE-10920
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov


With large topology and large amount of caches/partitions many server discovery 
events may quickly produce large affinity history, eating gigabytes of heap.

Solution: implement some kind of a compression for affinity cache map.

On example, affinity history could be stored as delta to some previous version.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10921) Add IGNITE_CONSISTENT_ID system property

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-10921:
---

 Summary: Add IGNITE_CONSISTENT_ID system property
 Key: IGNITE-10921
 URL: https://issues.apache.org/jira/browse/IGNITE-10921
 Project: Ignite
  Issue Type: Bug
Reporter: Stanislav Lukyanov


IGNITE-10900 explains the benefits of setting consistent ID explicitly and 
suggests adding a warning it isn't. However, currently changing consistentId 
for each node is rather cumbersome if the nodes share the configuration.

It would be good to add a new system property as a shorthand way to set 
consistent ID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10919) Implement .Net thin client benchmarks

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-10919:
-

 Summary: Implement .Net thin client benchmarks
 Key: IGNITE-10919
 URL: https://issues.apache.org/jira/browse/IGNITE-10919
 Project: Ignite
  Issue Type: Task
Reporter: Ilya Suntsov
 Attachments: put.cs

We need to implement the following benchmarks list:

{noformat}

IgniteThinGetBenchmark
IgniteThinGetTxBenchmark
IgniteThinPutAllBenchmark
IgniteThinPutAllTxBenchmark
IgniteThinPutGetBenchmark
IgniteThinPutTxBenchmark

{noformat}

Example of put benchmark you can find at attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10918) Implement C++, .Net thin benchmarks

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-10918:
-

 Summary: Implement C++, .Net thin benchmarks 
 Key: IGNITE-10918
 URL: https://issues.apache.org/jira/browse/IGNITE-10918
 Project: Ignite
  Issue Type: Task
Reporter: Ilya Suntsov
 Attachments: put.cpp, put.cs

We need the following list of benchmarks:

{noformat}

IgniteThinGetBenchmark
IgniteThinGetTxBenchmark
IgniteThinPutAllBenchmark
IgniteThinPutAllTxBenchmark
IgniteThinPutGetBenchmark
IgniteThinPutTxBenchmark

{noformat}

You can find examples of benchmarks in attachment.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)