[jira] [Closed] (IGNITE-8035) Duplicated events with type CREATED in ContinuousQuery's Events Listener
[ https://issues.apache.org/jira/browse/IGNITE-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov closed IGNITE-8035. --- > Duplicated events with type CREATED in ContinuousQuery's Events Listener > - > > Key: IGNITE-8035 > URL: https://issues.apache.org/jira/browse/IGNITE-8035 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Ruslan Gilemzyanov >Assignee: Nikolay Izhikov >Priority: Major > > We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote > sample project to demonstrate it. > We started 2 server nodes connected to the one cache. > Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB] > I have put elements in cache (about 50 elements). Elements were distributed > between two nodes approxiamtely in the same amount. > After pushing every element to cache we waited 100ms (to ensure that Listener > did his work) and deleted element from cache. > Then we stopped one node. (Topology snapshot became [ver=3, servers=1, > clients=0, CPUs=4, heap=1.8GB]) > And then some absolutely randomly chosen (deleted from cache to this moment) > events came to other working node with status CREATED (Remind you that we > deleted them from cache to this moment). In our case it was 5 events. > I think this is direct violation of Continuous Query's "exactly once > delivery" contract. > Source code is here: [https://github.com/ruslangm/ignite-sample] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8329) Clarify TransactionRollbackException-related paragraph in documentation
[ https://issues.apache.org/jira/browse/IGNITE-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-8329: --- Assignee: Nikolay Izhikov > Clarify TransactionRollbackException-related paragraph in documentation > --- > > Key: IGNITE-8329 > URL: https://issues.apache.org/jira/browse/IGNITE-8329 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Andrey Kuznetsov >Assignee: Nikolay Izhikov >Priority: Trivial > > As documentation states currently [1], TransactionRollbackException is thrown > "if the transaction was rolled back automatically". This should be extended > to manual rollback as well, if it took place before commit for some reason. > [1] > https://apacheignite.readme.io/docs/transactions#section-handling-failed-transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8442) How to use ignite cache for cross-platform(Java, C++)
[
https://issues.apache.org/jira/browse/IGNITE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Jingyuan updated IGNITE-8442:
-
Description:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
The cache main entity is User, which contains List, Map, Contact entity, for
example:
User
{ Long id; String userName; String password; Map
extAttributes; List phoneNums; ... ... }
Contact
{
Long id;
String contactType;
String contactNum;
}
Could you tell me an example how to implement it?
[https://apacheignite-cpp.readme.io/docs/cross-platform-interoperability#defining-cross-platform-type|https://apacheignite-cpp.readme.io/docs/cross-platform-interoperability#defining-cross-platform-type,]
was:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
The cache entity structure as below:
User
{
Long id;
String userName;
Map extAttributes;
List phoneNums;
... ...
}
Could you tell me an example how to implement it?
> How to use ignite cache for cross-platform(Java, C++)
> -
>
> Key: IGNITE-8442
> URL: https://issues.apache.org/jira/browse/IGNITE-8442
> Project: Ignite
> Issue Type: Wish
> Components: binary, cache, platforms
>Affects Versions: 2.4
>Reporter: Liu Jingyuan
>Priority: Minor
>
> I want to use ignite, but our system contains C++ and Java applications.
> C++ write/read a cache, and java read the cache;
> Java write/read a cache, and C++ read the cache;
>
> The cache main entity is User, which contains List, Map, Contact entity, for
> example:
>
> User
> { Long id; String userName; String password; Map
> extAttributes; List phoneNums; ... ... }
>
> Contact
> {
> Long id;
> String contactType;
> String contactNum;
> }
>
> Could you tell me an example how to implement it?
>
> [https://apacheignite-cpp.readme.io/docs/cross-platform-interoperability#defining-cross-platform-type|https://apacheignite-cpp.readme.io/docs/cross-platform-interoperability#defining-cross-platform-type,]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8442) How to use ignite cache for cross-platform(Java, C++)
[
https://issues.apache.org/jira/browse/IGNITE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Jingyuan updated IGNITE-8442:
-
Description:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
The cache entity structure as below:
User
{
Long id;
String userName;
Map extAttributes;
List phoneNums;
... ...
}
Could you tell me an example how to implement it?
was:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
The cache entity structure as below:
User{
Long id
String userName;
Map extAttributes;
List phoneNums;
... ...
}
Could you tell me an example how to implement it?
> How to use ignite cache for cross-platform(Java, C++)
> -
>
> Key: IGNITE-8442
> URL: https://issues.apache.org/jira/browse/IGNITE-8442
> Project: Ignite
> Issue Type: Wish
> Components: binary, cache, platforms
>Affects Versions: 2.4
>Reporter: Liu Jingyuan
>Priority: Minor
>
> I want to use ignite, but our system contains C++ and Java applications.
> C++ write/read a cache, and java read the cache;
> Java write/read a cache, and C++ read the cache;
>
> The cache entity structure as below:
>
> User
> {
> Long id;
> String userName;
> Map extAttributes;
> List phoneNums;
> ... ...
> }
>
> Could you tell me an example how to implement it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8442) How to use ignite cache for cross-platform(Java, C++)
[
https://issues.apache.org/jira/browse/IGNITE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liu Jingyuan updated IGNITE-8442:
-
Description:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
The cache entity structure as below:
User{
Long id
String userName;
Map extAttributes;
List phoneNums;
... ...
}
Could you tell me an example how to implement it?
was:
I want to use ignite, but our system contains C++ and Java applications.
C++ write/read a cache, and java read the cache;
Java write/read a cache, and C++ read the cache;
Could you tell me an example how to implement it?
> How to use ignite cache for cross-platform(Java, C++)
> -
>
> Key: IGNITE-8442
> URL: https://issues.apache.org/jira/browse/IGNITE-8442
> Project: Ignite
> Issue Type: Wish
> Components: binary, cache, platforms
>Affects Versions: 2.4
>Reporter: Liu Jingyuan
>Priority: Minor
>
> I want to use ignite, but our system contains C++ and Java applications.
> C++ write/read a cache, and java read the cache;
> Java write/read a cache, and C++ read the cache;
>
> The cache entity structure as below:
>
> User{
> Long id
> String userName;
> Map extAttributes;
> List phoneNums;
> ... ...
> }
>
> Could you tell me an example how to implement it?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8442) How to use ignite cache for cross-platform(Java, C++)
Liu Jingyuan created IGNITE-8442: Summary: How to use ignite cache for cross-platform(Java, C++) Key: IGNITE-8442 URL: https://issues.apache.org/jira/browse/IGNITE-8442 Project: Ignite Issue Type: Wish Components: binary, cache, platforms Affects Versions: 2.4 Reporter: Liu Jingyuan I want to use ignite, but our system contains C++ and Java applications. C++ write/read a cache, and java read the cache; Java write/read a cache, and C++ read the cache; Could you tell me an example how to implement it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)
[ https://issues.apache.org/jira/browse/IGNITE-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465438#comment-16465438 ] ASF GitHub Bot commented on IGNITE-8439: GitHub user shroman opened a pull request: https://github.com/apache/ignite/pull/3948 IGNITE-8439: user-specified IGNITE_JETTY_HOST doesn't work. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shroman/ignite IGNITE-8439 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3948.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3948 commit 8ffb0162ebe81c7d1c8dd3de0caf37afaea5ee10 Author: shroman Date: 2018-05-07T05:06:41Z IGNITE-8439: user-specified IGNITE_JETTY_HOST doesn't work. > IGNITE_JETTY_HOST doesn't work (never has probably) > --- > > Key: IGNITE-8439 > URL: https://issues.apache.org/jira/browse/IGNITE-8439 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.4 >Reporter: Paul Anderson >Assignee: Roman Shtykh >Priority: Major > > GridJettyRestProtocol.java > > public void start(GridRestProtocolHandler hnd) > ... > System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress()) > ... > should be > if(System.getProperty(IGNITE_JETTY_HOST)==null) > System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress()); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)
[ https://issues.apache.org/jira/browse/IGNITE-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-8439: Assignee: Roman Shtykh > IGNITE_JETTY_HOST doesn't work (never has probably) > --- > > Key: IGNITE-8439 > URL: https://issues.apache.org/jira/browse/IGNITE-8439 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.4 >Reporter: Paul Anderson >Assignee: Roman Shtykh >Priority: Major > > GridJettyRestProtocol.java > > public void start(GridRestProtocolHandler hnd) > ... > System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress()) > ... > should be > if(System.getProperty(IGNITE_JETTY_HOST)==null) > System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress()); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465308#comment-16465308
]
Alexey Kosenchuk commented on IGNITE-8039:
--
Several more comments:
a) Timestamp:
msecs_since_epoch contains a fraction of the last second (milliseconds of the
last second).
sec_fraction_in_nsecs contains a fraction of the last second.
It is some duplication and the values must correspond each other, correct?
Or msecs_since_epoch must not contain milliseconds of the last second? I.e.
milliseconds of the last second are zero and the fraction of the last second is
specified by sec_fraction_in_nsecs only?
b) Object array:
The new version of the spec does say there is type Id for the whole Object
array.
The previous version has it (between the length and elements) and the java
client writes it.
Does it exist?
If yes, what should be written as type Id if Object array contains non-complex
objects?
c) As we see from reality, there is type with code 38 (BINARY_ENUM) returned by
server.
It is not mentioned in the spec. Should be added?
> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
> Issue Type: Bug
> Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow
> a client development basing on the spec only, w/o looking at other client
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol
> spec (v.2.4)
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?)
> - what is Object array (type code 23) ? What is the difference between it and
> Objects Wrapped In Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
>
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field
> name".
> - "Repeat for as many times as the total number of schemas you have" ->
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the
> number of fields in the Data Object ?
> Objects Wrapped In Array
>
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not
> primitives)." -> does it mean that in general a complex object (103) must
> always be sent via the Binary Protocol in a wrapper (27)?
> - "Byte array size" -> "Payload size" or "Size of the whole array with
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8041) Add a GA Grid example that solves 'Knapsack Problem'
[ https://issues.apache.org/jira/browse/IGNITE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465303#comment-16465303 ] ASF GitHub Bot commented on IGNITE-8041: GitHub user techbysample opened a pull request: https://github.com/apache/ignite/pull/3947 IGNITE-8041: Add a GA Grid example that solves 'Knapsack Problem' Add a GA Grid example that solves 'Knapsack Problem' You can merge this pull request into a Git repository by running: $ git pull https://github.com/techbysample/ignite ignite-8041 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3947.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3947 commit 9beafa738d8a60df5049f5d418f2742459dbafe1 Author: Turik Campbell Date: 2018-05-03T02:51:22Z IGNITE-8041: Add a GA Grid example that solves 'Knapsack Problem commit f62a224877a2d7acadf92e532914196370970556 Author: Turik Campbell Date: 2018-05-04T20:18:50Z IGNITE-8041: Update terminate criteria to perform 30 generations commit fdb3eddbe22344f0c36e1b04a233bd9860d934d8 Author: Turik Campbell Date: 2018-05-04T21:20:20Z IGNITE-8041: Merge branch 'master' into ignite-8041 commit 756633f8d3122bc2f2e5b700dc2d4a5e882f0686 Author: Turik Campbell Date: 2018-05-04T21:26:12Z IGNITE-8041: Updated comments to reflect GA Grid performing 30 genrations > Add a GA Grid example that solves 'Knapsack Problem' > - > > Key: IGNITE-8041 > URL: https://issues.apache.org/jira/browse/IGNITE-8041 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Turik Campbell >Assignee: Turik Campbell >Priority: Minor > Fix For: 2.6 > > > The _Knapsack Problem_ is well known combinatorial optimization problem where > the goal is to maximize the benefit of objects in a knapsack without > exceeding its capacity. > Additional information: > [https://en.wikipedia.org/wiki/Knapsack_problem] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
[ https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465066#comment-16465066 ] Evgenii Zagumennov commented on IGNITE-7766: I've investigated the issue (with "git bisect"). This test started to fail after [IGNITE-7195|https://issues.apache.org/jira/browse/IGNITE-7195] was fixed. I think, the subject test (IgniteCacheQueryNodeRestartTxSelfTest.testRestarts) is not actual anymore. > Ignite Queries 2: Test always failed > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > --- > > Key: IGNITE-7766 > URL: https://issues.apache.org/jira/browse/IGNITE-7766 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Dmitriy Pavlov >Assignee: Evgenii Zagumennov >Priority: Major > Labels: MakeTeamcityGreenAgain > >Ignite Queries 2 > IgniteBinaryCacheQueryTestSuite2: > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > Current failure:refs/heads/master #345No changes > 11 Feb 18 03:03 > > junit.framework.AssertionFailedError: On large page size must retry. > > Last runs fails with 100% probability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8434) .NET: Service proxies do not work on .NET Core
[
https://issues.apache.org/jira/browse/IGNITE-8434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465039#comment-16465039
]
ASF GitHub Bot commented on IGNITE-8434:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/3946
IGNITE-8434 .NET: Fix service proxies on .NET Core
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-8434
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3946.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3946
commit e8b39d2c2806b068df74ebac58d4261ea0b03774
Author: Pavel Tupitsyn
Date: 2018-05-04T08:12:39Z
Fix DefineDynamicAssembly call
commit 2c4f4cb805077e3d2f4d91cfedf2b516b5c5fe63
Author: Pavel Tupitsyn
Date: 2018-05-04T08:31:27Z
Fix DefineDynamicAssembly call
commit 4999a99f01979759942a711fc7b702de8b514ef7
Author: Pavel Tupitsyn
Date: 2018-05-06T09:11:23Z
Change to expression trees to work around the limitation of non-callable
methods
commit cbae86b59bb97bd3af7f05304bc8f97bc329cb72
Author: Pavel Tupitsyn
Date: 2018-05-06T09:14:40Z
Change to expression trees to work around the limitation of non-callable
methods
commit 3cf378a2a9c11567d14b211d98cac5c2c23163b2
Author: Pavel Tupitsyn
Date: 2018-05-06T09:17:56Z
add explanation
> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> Service proxies do not work on .NET Core because of conditional compilation
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never
> used.
> Except in tests, so they pass.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
