[jira] [Commented] (IGNITE-1789) Data Snapshots for Ignite caches
[
https://issues.apache.org/jira/browse/IGNITE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975530#comment-14975530
]
Dmitriy Setrakyan commented on IGNITE-1789:
---
I still think we should snapshot to disk and preserve a snapshot on disk. This
would make everything else, like frozen state possible. For example, user can
snapshot to disk, then load from disk into a different cache and perform any
kind of Ignite operation there, like so:
{code}
cache.saveSnapshot("mySnapshot"); // Should be sync or async mode.
IgniteCache otherCache = ignite.getOrCreateCache("otherCache");
otherCache.loadSnapshot("mySnapshot");
{code}
> Data Snapshots for Ignite caches
>
>
> Key: IGNITE-1789
> URL: https://issues.apache.org/jira/browse/IGNITE-1789
> Project: Ignite
> Issue Type: New Feature
> Components: cache
>Reporter: Raúl Kripalani
>
> There was a discussion in the dev forum about Data Snapshots in Ignite as a
> way to obtain a consistent and "frozen" view of one or multiple caches in
> order to execute a set of SQL queries, distributed closures, map reduce, etc.
> without having to worry about data slippage (or moving data).
> The discussion is here:
> http://apache-ignite-developers.2346864.n4.nabble.com/Data-Snapshots-in-Ignite-td4183.html
> and we still need to mature the idea, but several users chimed in and
> considered it interesting.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1789) Data Snapshots for Ignite caches
[ https://issues.apache.org/jira/browse/IGNITE-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975114#comment-14975114 ] Konstantin Boudnik commented on IGNITE-1789: This *frozen* view can also be useful for ML-type workloads, as far as I understand, right? > Data Snapshots for Ignite caches > > > Key: IGNITE-1789 > URL: https://issues.apache.org/jira/browse/IGNITE-1789 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Raúl Kripalani > > There was a discussion in the dev forum about Data Snapshots in Ignite as a > way to obtain a consistent and "frozen" view of one or multiple caches in > order to execute a set of SQL queries, distributed closures, map reduce, etc. > without having to worry about data slippage (or moving data). > The discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Data-Snapshots-in-Ignite-td4183.html > and we still need to mature the idea, but several users chimed in and > considered it interesting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1701) Bump Spark dependenency to 1.5.1 (the latest stable)
[
https://issues.apache.org/jira/browse/IGNITE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974861#comment-14974861
]
Konstantin Boudnik commented on IGNITE-1701:
I haven't committed it yet. And yes, I am aware about this thread and the
issue. It has nothing to do with the patch in question. The problem user is
facing comes from running ignite and spark services under different user
accounts. Which leads to the permission conflicts in {{/tmp/ignite}} work
directory. I worked with Rich directly and the issue was solved (see
[here|http://apache-ignite-users.70518.x6.nabble.com/Question-about-getting-started-with-spark-shell-tp1663p1676.html]
Ideally, it needs to be documented as the requirement. Also, is it possible to
start an Ignite node and specify the location of the work directory via command
line or sys.prop?
The patch has been tested and as it stance shouldn't pose any threat to the
release, unless there some sudden incompatibilities between new spark and
latest ignite, which I don't think is the case. Will be committing this today.
Thanks!
> Bump Spark dependenency to 1.5.1 (the latest stable)
>
>
> Key: IGNITE-1701
> URL: https://issues.apache.org/jira/browse/IGNITE-1701
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1701.patch
>
>
> At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is
> like 3 versions old already. Let's bump the version to 1.5.1, which is the
> latest stable.
> In the process, I'd like to add an ability to specify the version of Spark
> during the build time, like it is done for Hadoop now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura reassigned IGNITE-1526:
---
Assignee: Denis Magda (was: Andrey Gura)
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID =
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162
> 2)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 771)
>
[jira] [Commented] (IGNITE-1792) ContinuousProcessor should use ALWAYS_TRUE predicate instead of null
[
https://issues.apache.org/jira/browse/IGNITE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974816#comment-14974816
]
Andrey Gura commented on IGNITE-1792:
-
PR created: https://github.com/apache/ignite/pull/174
Waiting for TC.
> ContinuousProcessor should use ALWAYS_TRUE predicate instead of null
>
>
> Key: IGNITE-1792
> URL: https://issues.apache.org/jira/browse/IGNITE-1792
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.5
>
>
> In order to keep backward compatibility {{GridContinuousProcessor}} should
> start routine with {{ALWAYS_TRUE}} predicate instead of {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974802#comment-14974802
]
Andrey Gura edited comment on IGNITE-1526 at 10/26/15 6:44 PM:
---
1) Fixed.
2) Test added.
PR updated.
The only reason to replace {{OptimizedMarshaller}} with {{JdkMarshaller}} is
{{BigInteger}}-like classes. But problem is solved. So I don't see any other
reasons for it.
was (Author: agura):
1) Fixed.
2) Test added.
PR updated.
The only reason to replace {{OptimizedMarshaller}} with {{JdkMarshaller}} is
{{BigInteger}}-like classes. But problem is solved. So I don see any other
reasons for it.
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Gura
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38
[jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974802#comment-14974802
]
Andrey Gura commented on IGNITE-1526:
-
1) Fixed.
2) Test added.
PR updated.
The only reason to replace {{OptimizedMarshaller}} with {{JdkMarshaller}} is
{{BigInteger}}-like classes. But problem is solved. So I don see any other
reasons for it.
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Gura
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID =
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at
> java.io.ObjectInputStream.readNonProxyDesc(Obj
[jira] [Commented] (IGNITE-1786) Need to implement ODBC driver for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974798#comment-14974798 ] Igor Sapego commented on IGNITE-1786: - I suggest to implement separate lightweight driver and use shared memory to communicate with the JVM. This approach will require a JVM node running on the same computer but it will be more flexible than the first approach and easier to implement than the second one. > Need to implement ODBC driver for Ignite > > > Key: IGNITE-1786 > URL: https://issues.apache.org/jira/browse/IGNITE-1786 > Project: Ignite > Issue Type: New Feature > Components: clients >Reporter: Dmitriy Setrakyan >Assignee: Igor Sapego > Fix For: 1.6 > > > # We have a C++ API for Ignite which starts JVM internally. Probably we can > just add that ODBC API there. > # Another approach is to implement really separate driver and a network > server on java side which will interact with each other. > The first one is simpler and probably more effective, but heavyweight. The > second one is probably slower but but more lightweight. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1652) .Net: Rework async APIs (remove WithAsync/GetFuture)
[
https://issues.apache.org/jira/browse/IGNITE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974597#comment-14974597
]
ASF GitHub Bot commented on IGNITE-1652:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/175
IGNITE-1652 .Net: Rework async APIs (remove WithAsync/GetFuture)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1652
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/175.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 #175
commit 67c245e74cd227d1d8708e58a8eab96d22203f99
Author: Pavel Tupitsyn
Date: 2015-10-26T13:20:30Z
IGNITE-1652 .Net: Rework async APIs (remove WithAsync/GetFuture): Messaging
reworked
commit 63fb6a617303191c746453691c132146fc3596a5
Author: Pavel Tupitsyn
Date: 2015-10-26T13:58:41Z
wip
commit 1ad95340cdecc4c4f8427b433dc1d024dd68a5cd
Author: Pavel Tupitsyn
Date: 2015-10-26T13:59:53Z
fix messaging test
commit 395b76957fe332e2bced240657c522cc5951de42
Author: Pavel Tupitsyn
Date: 2015-10-26T14:23:43Z
IEvents wip
commit 3f1be27e0cd3005721b1e6f7636bb5dcd315f164
Author: Pavel Tupitsyn
Date: 2015-10-26T15:24:00Z
Async events wip
commit db1816311576106fc4c2008954e9ae39a7a99d3e
Author: Pavel Tupitsyn
Date: 2015-10-26T15:41:44Z
Fix tests
commit 619b2841525074c2b034ed2b8fca92e9f97d08aa
Author: Pavel Tupitsyn
Date: 2015-10-26T15:55:29Z
wip
commit 3169cdfaa007c2c093442998a611131b6f166085
Author: Pavel Tupitsyn
Date: 2015-10-26T15:59:48Z
Remove EventsAsync
commit e0dcadc2c7dc2b76a6149605fb94c1513c674b55
Author: Pavel Tupitsyn
Date: 2015-10-26T16:04:09Z
wip
commit 69738e91aef8e956c027c61f73a3e4d5c0f7f6d2
Author: Pavel Tupitsyn
Date: 2015-10-26T16:05:00Z
Remove asyncSupported
commit 19b9580a588e15427788f1159bbb49c4476a5c71
Author: Pavel Tupitsyn
Date: 2015-10-26T16:35:30Z
Services API
commit 7ca06a4cdaa977c862d9894f7a4873e523b3cd42
Author: Pavel Tupitsyn
Date: 2015-10-26T16:35:48Z
wip
commit 7b13b6b83d2c78aa33f08acfcfe7f742de2f1bd8
Author: Pavel Tupitsyn
Date: 2015-10-26T16:37:27Z
wip
commit 9b092182d3db8470f82b9d185e9b6cc0d31b82f8
Author: Pavel Tupitsyn
Date: 2015-10-26T16:40:10Z
wip
commit 8d7d5a3461c2287df0d5c55ce217dd7df792b443
Author: Pavel Tupitsyn
Date: 2015-10-26T16:40:20Z
wip
commit 0e2212fff88655660e8e7ab0910eb566b60f82a1
Author: Pavel Tupitsyn
Date: 2015-10-26T16:47:18Z
wip services
commit 4e8ae20f7a845ba44a47059b812ee64b4071c4ce
Author: Pavel Tupitsyn
Date: 2015-10-26T16:49:08Z
wip
commit 8f9ef25e729676ce73aa7837784eac62ccbb063b
Author: Pavel Tupitsyn
Date: 2015-10-26T16:56:31Z
wip
commit d431278988e437b999fb435af433f36e502c1723
Author: Pavel Tupitsyn
Date: 2015-10-26T17:03:11Z
ITransaction
commit 9bfddf4c956ac859eab8f4f35cf5b54dae055db9
Author: Pavel Tupitsyn
Date: 2015-10-26T17:07:11Z
Fix tx tests
commit 3d2143baa6d0d4dd7ba257a13a5cb82c4d6dde1c
Author: Pavel Tupitsyn
Date: 2015-10-26T17:08:28Z
wip
commit bb076c006602f70cdf02cfaadd9890edec8289d6
Author: Pavel Tupitsyn
Date: 2015-10-26T17:09:54Z
wip ICompute
commit 28b2247718bc3baafe2b00ddecf015b14e3ac936
Author: Pavel Tupitsyn
Date: 2015-10-26T17:13:54Z
ICompute iface done
commit 2bb77b8e9e6f9c49c3d3c6d706604a3805bc0244
Author: Pavel Tupitsyn
Date: 2015-10-26T17:16:11Z
Wip compute
commit 2c5239427d064596324deb2e855a2317377ea102
Author: Pavel Tupitsyn
Date: 2015-10-26T17:16:43Z
wip
commit 854738e611f5b00b82382c7f9ded018ade48a1bc
Author: Pavel Tupitsyn
Date: 2015-10-26T17:22:49Z
Compute done
commit ad6ce0724f807ce8a107fa4aaba44c9d8d329d73
Author: Pavel Tupitsyn
Date: 2015-10-26T17:25:30Z
wip
commit 24e9caf6ce01e45f0c78ee2eb567cf435ee21164
Author: Pavel Tupitsyn
Date: 2015-10-26T17:28:59Z
fix tests
> .Net: Rework async APIs (remove WithAsync/GetFuture)
>
>
> Key: IGNITE-1652
> URL: https://issues.apache.org/jira/browse/IGNITE-1652
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> {code}
> cache.WithAsync().Get();
> IFuture future = cache.GetFuture();
> {code}
> should become
> {code}
> Task task = cache.GetAsync();
> {code}
> Guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
> First step is .Net-only (remove GetFuture from public API, call it inside
> *Async methods). This requires 2 JNI calls.
> Later w
[jira] [Created] (IGNITE-1794) Ignite should support Hibernate 5
Artem Shutak created IGNITE-1794:
Summary: Ignite should support Hibernate 5
Key: IGNITE-1794
URL: https://issues.apache.org/jira/browse/IGNITE-1794
Project: Ignite
Issue Type: Test
Reporter: Artem Shutak
Currently Ignite supports Hibernate 4.
In Hibernate 5 org.hibernate.cache.spi.RegionFactory.start() method signature
has been changed from
{{void start(Settings var1, Properties var2) throws CacheException;}}
on
{{void start(SessionFactoryOptions settings, Properties properties) throws
CacheException;}}
Original user list:
http://apache-ignite-users.70518.x6.nabble.com/Hibernate-5-L2-Cache-Compatibility-td1656.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974552#comment-14974552
]
Semen Boikov commented on IGNITE-1272:
--
Denis,
I don't like that if message contains EntryProcessor then 'addDepInfo' is set
to 'true' for all objects in the message (and e.g. 'prepareObject' will be
unnecessarily called for keys), I think it is better to initialize 'addDepInfo'
flag inside 'prepareMarshal' method.
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov reassigned IGNITE-1272:
Assignee: Denis Magda (was: Semen Boikov)
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1791) .Net: Improve Task-based async API efficiency with TaskCompletionSource
[ https://issues.apache.org/jira/browse/IGNITE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1791: Description: Currently we use TaskFactory.FromAsync to create tasks and return them from API. This requires implementing IAsyncResult, which has a heavyweight WaitHandle inside. TaskFactory then uses ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task completion. Creating WaitHandle and waiting on it are redundant extra steps. [TaskCompletionSource|https://msdn.microsoft.com/en-us/library/dd449174(v=vs.100).aspx] allows lighter-weight approach. was: Currently we use TaskFactory.FromAsync to create tasks and return them from API. This requires implementing IAsyncResult, which has a heavyweight WaitHandle inside. TaskFactory then uses ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task completion. Creating WaitHandle and waiting on it are redundant extra steps. System.Threading.Task has internal API to create "promise-style" task and then set it to completed state when needed. > .Net: Improve Task-based async API efficiency with TaskCompletionSource > --- > > Key: IGNITE-1791 > URL: https://issues.apache.org/jira/browse/IGNITE-1791 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Currently we use TaskFactory.FromAsync to create tasks and return them from > API. This requires implementing IAsyncResult, which has a heavyweight > WaitHandle inside. TaskFactory then uses > ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task > completion. > Creating WaitHandle and waiting on it are redundant extra steps. > [TaskCompletionSource|https://msdn.microsoft.com/en-us/library/dd449174(v=vs.100).aspx] > allows lighter-weight approach. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1791) .Net: Improve Task-based async API efficiency with TaskCompletionSource
[ https://issues.apache.org/jira/browse/IGNITE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1791: Summary: .Net: Improve Task-based async API efficiency with TaskCompletionSource (was: .Net: Improve Task-based async API efficiency with promise-style tasks) > .Net: Improve Task-based async API efficiency with TaskCompletionSource > --- > > Key: IGNITE-1791 > URL: https://issues.apache.org/jira/browse/IGNITE-1791 > Project: Ignite > Issue Type: Improvement > Components: interop >Affects Versions: 1.5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Fix For: 1.5 > > > Currently we use TaskFactory.FromAsync to create tasks and return them from > API. This requires implementing IAsyncResult, which has a heavyweight > WaitHandle inside. TaskFactory then uses > ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task > completion. > Creating WaitHandle and waiting on it are redundant extra steps. > System.Threading.Task has internal API to create "promise-style" task and > then set it to completed state when needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1792) ContinuousProcessor should use ALWAYS_TRUE predicate instead of null
[
https://issues.apache.org/jira/browse/IGNITE-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-1792:
Description: In order to keep backward compatibility
{{GridContinuousProcessor}} should start routine with {{ALWAYS_TRUE}} predicate
instead of {{null}}. (was: In order to keep backward compatibility
{{GridContinuousProcessor}} should start routine with {{aLWAYS_TRUE}} predicate
instead of {{null}}.)
> ContinuousProcessor should use ALWAYS_TRUE predicate instead of null
>
>
> Key: IGNITE-1792
> URL: https://issues.apache.org/jira/browse/IGNITE-1792
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.5
>
>
> In order to keep backward compatibility {{GridContinuousProcessor}} should
> start routine with {{ALWAYS_TRUE}} predicate instead of {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
[
https://issues.apache.org/jira/browse/IGNITE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-1793:
-
Attachment: test.logs
Added logs.
> [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs
> on TC sometimes
> -
>
> Key: IGNITE-1793
> URL: https://issues.apache.org/jira/browse/IGNITE-1793
> Project: Ignite
> Issue Type: Test
>Reporter: Artem Shutak
>Priority: Blocker
> Labels: Muted_test
> Fix For: 1.5
>
> Attachments: test.logs
>
>
> IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
> Test hangs on IgniteCountDownLatch.count() method.
> {noformat}
> Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
> Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
> at
> o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
> at
> o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
> at
> o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1793) [Failed Test] IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
Artem Shutak created IGNITE-1793:
Summary: [Failed Test]
IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes
Key: IGNITE-1793
URL: https://issues.apache.org/jira/browse/IGNITE-1793
Project: Ignite
Issue Type: Test
Reporter: Artem Shutak
Priority: Blocker
Fix For: 1.5
IgnitePartitionedCountDownLatchSelfTest.testLatch hangs on TC sometimes.
Test hangs on IgniteCountDownLatch.count() method.
{noformat}
Thread [name="test-runner", id=24157, state=WAITING, blockCnt=0, waitCnt=96]
Lock [object=o.a.i.i.util.future.GridFutureAdapter$ChainFuture@1e542154,
ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
at
o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4525)
at
o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1544)
at
o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:348)
at
o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl$GetCountCallable.call(GridCacheCountDownLatchImpl.java:342)
at
o.a.i.i.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:962)
at
o.a.i.i.processors.datastructures.GridCacheCountDownLatchImpl.count(GridCacheCountDownLatchImpl.java:143)
at
o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkRemovedLatch(IgniteCountDownLatchAbstractSelfTest.java:159)
at
o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkCountDown(IgniteCountDownLatchAbstractSelfTest.java:232)
at
o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.checkLatch(IgniteCountDownLatchAbstractSelfTest.java:84)
at
o.a.i.i.processors.cache.datastructures.IgniteCountDownLatchAbstractSelfTest.testLatch(IgniteCountDownLatchAbstractSelfTest.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
at
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
at
o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1792) ContinuousProcessor should use ALWAYS_TRUE predicate instead of null
Andrey Gura created IGNITE-1792:
---
Summary: ContinuousProcessor should use ALWAYS_TRUE predicate
instead of null
Key: IGNITE-1792
URL: https://issues.apache.org/jira/browse/IGNITE-1792
Project: Ignite
Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura
Fix For: 1.5
In order to keep backward compatibility {{GridContinuousProcessor}} should
start routine with {{aLWAYS_TRUE}} predicate instead of {{null}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1746) ScalaCacheQuery fails with jdkMarshaller in the mixed cluster
[
https://issues.apache.org/jira/browse/IGNITE-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova updated IGNITE-1746:
---
Environment: Apache Ignite 1.5.0 build #40 (was: Apache Ignite build #40)
> ScalaCacheQuery fails with jdkMarshaller in the mixed cluster
> -
>
> Key: IGNITE-1746
> URL: https://issues.apache.org/jira/browse/IGNITE-1746
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5
> Environment: Apache Ignite 1.5.0 build #40
>Reporter: Vasilisa Sidorova
> Fix For: 1.5
>
>
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project in IDE (oracle-java7)
> # In the example-ignite.xml change property from:
> {noformat}
>
> class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> -->
>
> ACTUAL RESULT
> -
> Example is failed with exception:
> {noformat}
> [17:34:48,979][ERROR][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to unmarshal discovery custom message.
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@76ed5528
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.messages.TcpDiscoveryCustomEventMessage.message(TcpDiscoveryCustomEventMessage.java:78)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:4257)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2125)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5382)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.scalar.examples.Organization
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8137)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
> at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1484)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1334)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1707)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at java.util.ArrayList.readObject(ArrayList.java:791)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1900)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:20
[jira] [Closed] (IGNITE-1746) ScalaCacheQuery fails with jdkMarshaller in the mixed cluster
[
https://issues.apache.org/jira/browse/IGNITE-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova closed IGNITE-1746.
--
Assignee: (was: Vasilisa Sidorova)
Confirm: couldn't reproduce for Apache Ignite 1.5.0 build #45
> ScalaCacheQuery fails with jdkMarshaller in the mixed cluster
> -
>
> Key: IGNITE-1746
> URL: https://issues.apache.org/jira/browse/IGNITE-1746
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5
> Environment: Apache Ignite build #40
>Reporter: Vasilisa Sidorova
> Fix For: 1.5
>
>
> -
> STEPS FOR REPRODUCE
> -
> # Build examples project in IDE (oracle-java7)
> # In the example-ignite.xml change property from:
> {noformat}
>
> class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> -->
>
> ACTUAL RESULT
> -
> Example is failed with exception:
> {noformat}
> [17:34:48,979][ERROR][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to unmarshal discovery custom message.
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@76ed5528
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.messages.TcpDiscoveryCustomEventMessage.message(TcpDiscoveryCustomEventMessage.java:78)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:4257)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2125)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5382)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.scalar.examples.Organization
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8137)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
> at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1484)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1334)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1707)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1345)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1924)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at java.util.ArrayList.readObject(ArrayList.java:791)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1900)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at
> java.io.ObjectInputStream.defaultReadFields(Objec
[jira] [Assigned] (IGNITE-1653) Need to remove lgpl-dependent examples from Ignite binaries
[ https://issues.apache.org/jira/browse/IGNITE-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-1653: Assignee: Vasilisa Sidorova (was: Anton Vinogradov) Fixed ad master > Need to remove lgpl-dependent examples from Ignite binaries > --- > > Key: IGNITE-1653 > URL: https://issues.apache.org/jira/browse/IGNITE-1653 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.5 > Environment: Apache-Ignite-1.5.0 build #29 >Reporter: Vasilisa Sidorova >Assignee: Vasilisa Sidorova >Priority: Critical > Fix For: 1.5 > > > Examples project from Ignite binaries couldn't be compiled due to there is > lgpl-dependencies. > Solution: lgpl-dependent examples should be removed from Ignite src and bin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1701) Bump Spark dependenency to 1.5.1 (the latest stable)
[
https://issues.apache.org/jira/browse/IGNITE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974242#comment-14974242
]
Artem Shutak commented on IGNITE-1701:
--
Hi Cos,
Did you already commit?
I worry about proper testing before we can switch to 1.5.1. Did you see user
thread above. As I understand Ignite will not work with 1.5.1 without some code
changes.
I see you changed default Spark version to 1.5.1. Is this mean that Ignite will
not support 1.3.1 without rebuilding? Can we support 1.3.1, 1.4.1 and 1.5.1
with the same binaries?
Thanks,
Artem.
> Bump Spark dependenency to 1.5.1 (the latest stable)
>
>
> Key: IGNITE-1701
> URL: https://issues.apache.org/jira/browse/IGNITE-1701
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Affects Versions: ignite-1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
> Fix For: 1.5
>
> Attachments: IGNITE-1701.patch
>
>
> At the moment, {{ignite-spark}} module is built against spark 1.3.1 which is
> like 3 versions old already. Let's bump the version to 1.5.1, which is the
> latest stable.
> In the process, I'd like to add an ability to specify the version of Spark
> during the build time, like it is done for Hadoop now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1652) .Net: Rework async APIs (remove WithAsync/GetFuture)
[
https://issues.apache.org/jira/browse/IGNITE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-1652:
Description:
{code}
cache.WithAsync().Get();
IFuture future = cache.GetFuture();
{code}
should become
{code}
Task task = cache.GetAsync();
{code}
Guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
First step is .Net-only (remove GetFuture from public API, call it inside
*Async methods). This requires 2 JNI calls.
Later we should look into making it a single JNI call.
was:
{code}
cache.WithAsync().Get();
var future = cache.GetFuture();
{code}
should become
{code}
var future = cache.GetAsync();
{code}
See if we can make ToTask() more efficient, or even get rid of Futures
completely in favor of tasks, preserving performance.
First step is .Net-only (remove GetFuture from public API, call it inside
*Async methods). This requires 2 JNI calls.
Later we should look into making it a single JNI call.
> .Net: Rework async APIs (remove WithAsync/GetFuture)
>
>
> Key: IGNITE-1652
> URL: https://issues.apache.org/jira/browse/IGNITE-1652
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> {code}
> cache.WithAsync().Get();
> IFuture future = cache.GetFuture();
> {code}
> should become
> {code}
> Task task = cache.GetAsync();
> {code}
> Guidelines: https://msdn.microsoft.com/en-us/library/hh873175(v=vs.110).aspx
> First step is .Net-only (remove GetFuture from public API, call it inside
> *Async methods). This requires 2 JNI calls.
> Later we should look into making it a single JNI call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1652) .Net: Rework async APIs (remove WithAsync/GetFuture)
[
https://issues.apache.org/jira/browse/IGNITE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974216#comment-14974216
]
Pavel Tupitsyn commented on IGNITE-1652:
-
Let's hide IFuture and return Tasks directly to have a .Net-friendly API.
Later we can improve Task creation performance:
https://issues.apache.org/jira/browse/IGNITE-1791
> .Net: Rework async APIs (remove WithAsync/GetFuture)
>
>
> Key: IGNITE-1652
> URL: https://issues.apache.org/jira/browse/IGNITE-1652
> Project: Ignite
> Issue Type: Task
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> {code}
> cache.WithAsync().Get();
> var future = cache.GetFuture();
> {code}
> should become
> {code}
> var future = cache.GetAsync();
> {code}
> See if we can make ToTask() more efficient, or even get rid of Futures
> completely in favor of tasks, preserving performance.
> First step is .Net-only (remove GetFuture from public API, call it inside
> *Async methods). This requires 2 JNI calls.
> Later we should look into making it a single JNI call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1791) .Net: Improve Task-based async API efficiency with promise-style tasks
Pavel Tupitsyn created IGNITE-1791: --- Summary: .Net: Improve Task-based async API efficiency with promise-style tasks Key: IGNITE-1791 URL: https://issues.apache.org/jira/browse/IGNITE-1791 Project: Ignite Issue Type: Improvement Components: interop Affects Versions: 1.5 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.5 Currently we use TaskFactory.FromAsync to create tasks and return them from API. This requires implementing IAsyncResult, which has a heavyweight WaitHandle inside. TaskFactory then uses ThreadPool.RegisterWaitForSingleObject to wait on that handle and set task completion. Creating WaitHandle and waiting on it are redundant extra steps. System.Threading.Task has internal API to create "promise-style" task and then set it to completed state when needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization
[
https://issues.apache.org/jira/browse/IGNITE-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974158#comment-14974158
]
Pavel Tupitsyn commented on IGNITE-1644:
-
To fix mismatch between Reader/Writer and PortableBuilder APIs I've added
Set_x_Field methods to the builder.
> .Net: DateTime.Kind is lost during serialization
>
>
> Key: IGNITE-1644
> URL: https://issues.apache.org/jira/browse/IGNITE-1644
> Project: Ignite
> Issue Type: Bug
> Components: interop
>Affects Versions: 1.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 1.5
>
>
> Add the following test to PortableSelfTest.cs:
> {code}
> [Test]
> public void TestWriteDate()
> {
> DateTime time = DateTime.Now;
> DateTime timeUtc = DateTime.UtcNow;
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(time)), time);
> Assert.AreEqual(_marsh.Unmarshal(_marsh.Marshal(timeUtc)),
> timeUtc);
> }
> {code}
> Observe that it fails becuase we loose DateTimeKind.
> This happens because we always write DateTime as UTC and lose DateTime.Kind,
> so on deserialization we do not know whether ToLocal should be called.
> DateTime must be serialized in portable form only in two cases:
> 1) IPortableWriter.WriteDate()
> 2) IPortableWriter.WriteDateArray()
> In these cases we should throw exception on a non-UTC date.
> In all other cases it should be serialized in some other form. E.g., we can
> introduce new wrapper type ".NET-specific" and wrap DateTime, Collections,
> Arrays (IGNITE-1779) in it.
> This will break queries to some extent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1790) Implement an Apache Camel Data Streamer
Raúl Kripalani created IGNITE-1790: -- Summary: Implement an Apache Camel Data Streamer Key: IGNITE-1790 URL: https://issues.apache.org/jira/browse/IGNITE-1790 Project: Ignite Issue Type: New Feature Components: streaming Reporter: Raúl Kripalani Assignee: Raúl Kripalani Fix For: 1.5 An Apache Camel data streamer would make it possible for a user to use any of Camel's [150+ adapters/components|http://camel.apache.org/components.html] to consume data from the outside world and feed it into an Ignite cache. SOAP, REST, HTTP, WebSockets, FTP, File, XMPP, SMPP, POP3, IMAP, TCP, etc. This data streamer will instantiate a Camel consumer endpoint, it'll apply the user-specified StreamTransformer to the incoming Exchange and it'll add the result to the data streamer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-1789) Data Snapshots for Ignite caches
Raúl Kripalani created IGNITE-1789: -- Summary: Data Snapshots for Ignite caches Key: IGNITE-1789 URL: https://issues.apache.org/jira/browse/IGNITE-1789 Project: Ignite Issue Type: New Feature Components: cache Reporter: Raúl Kripalani There was a discussion in the dev forum about Data Snapshots in Ignite as a way to obtain a consistent and "frozen" view of one or multiple caches in order to execute a set of SQL queries, distributed closures, map reduce, etc. without having to worry about data slippage (or moving data). The discussion is here: http://apache-ignite-developers.2346864.n4.nabble.com/Data-Snapshots-in-Ignite-td4183.html and we still need to mature the idea, but several users chimed in and considered it interesting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1750) Missed placeholders in cluster configuration
[ https://issues.apache.org/jira/browse/IGNITE-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-1750: - Assignee: Vasiliy Sisko > Missed placeholders in cluster configuration > > > Key: IGNITE-1750 > URL: https://issues.apache.org/jira/browse/IGNITE-1750 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko > Fix For: 1.5 > > > Placeholder for the following fields is not set. > Please analyze Ignite source code and set . > *Communication*: > - Communication listener: > - Unacknowledged messages: > - Selectors count: > - Address resolver: > *Discovery*: > - Address resolver: > - Socket timeout: > - Acknowledgement timeout: > - Join timeout: > - Discovery listener: > - Data exchange: > - Metrics provider: > - Statistics frequency: > - Node authenticator: > *Transactions* > - Manager lookup: > *SSL configuration* > - Key store file: > - Trust store file: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1718) ScalaPrimeExample fails with "Not enough data to read the value" error when it's running with portableMarshaller
[
https://issues.apache.org/jira/browse/IGNITE-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasilisa Sidorova updated IGNITE-1718:
---
Assignee: (was: Vasilisa Sidorova)
> ScalaPrimeExample fails with "Not enough data to read the value" error when
> it's running with portableMarshaller
>
>
> Key: IGNITE-1718
> URL: https://issues.apache.org/jira/browse/IGNITE-1718
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5
> Environment: Ubuntu 14.04, community 1.5.0 build #319
>Reporter: Vasilisa Sidorova
> Fix For: 1.5
>
>
> -
> DESCRIPTION
> -
> When default optimizedMarshaller is changed into portableMarshaller in
> example-ignite.xml then ScalarPrimeExample doesn't start with exception "Not
> enough data to read the value"
> -
> STEPS FOR REPRODUCE
> -
> 1. Build examples project in IDE
> 2.In the example-ignite.xml change property from:
> {noformat}
>
> class="org.apache.ignite.marshaller.optimized.OptimizedMarshaller"> -->
>
> ACTUAL RESULT
> -
> Example is failed with exception:
> {noformat}
> Exception in thread "ignite-#21%sys-null%" class
> org.apache.ignite.internal.portable.api.PortableException: Not enough data to
> read the value [position=18, requiredBytes=1, remainingBytes=0]
> at
> org.apache.ignite.internal.portable.streams.PortableAbstractInputStream.ensureEnoughData(PortableAbstractInputStream.java:288)
> at
> org.apache.ignite.internal.portable.streams.PortableAbstractInputStream.readByte(PortableAbstractInputStream.java:32)
> at
> org.apache.ignite.internal.portable.PortableReaderExImpl.doReadByte(PortableReaderExImpl.java:1895)
> at
> org.apache.ignite.internal.portable.PortableReaderExImpl.doReadClass(PortableReaderExImpl.java:2986)
> at
> org.apache.ignite.internal.portable.PortableReaderExImpl.readObjectTypeId(PortableReaderExImpl.java:211)
> at
> org.apache.ignite.internal.portable.PortableReaderExImpl.deserialize(PortableReaderExImpl.java:2142)
> at
> org.apache.ignite.internal.portable.GridPortableMarshaller.deserialize(GridPortableMarshaller.java:274)
> at
> org.apache.ignite.internal.portable.api.PortableMarshaller.unmarshal(PortableMarshaller.java:328)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:762)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:995)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1219)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:811)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1500(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:774)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
> at java.lang.Thread.run(Thread.java:809)
> {noformat}
> -
> EXPECTED RESULT
> -
> Example is passed without any exceptions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14973912#comment-14973912
]
Denis Magda commented on IGNITE-1272:
-
Did the following changes:
- every deployable {{CacheMessage}} has to initialize {{addDepInfo}} variable.
Basing on the value of this variable deployment info is either added or not
during serialization;
- added tests for {{EntryProcessor}}. Fixed implementation when
{{PortableMarshaller}} is used.
Semen, please take a look one more time. TC looks good.
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1272) PortableMarshaller: issues when different class loaders are used
[
https://issues.apache.org/jira/browse/IGNITE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1272:
Assignee: Semen Boikov (was: Denis Magda)
> PortableMarshaller: issues when different class loaders are used
>
>
> Key: IGNITE-1272
> URL: https://issues.apache.org/jira/browse/IGNITE-1272
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Semen Boikov
>Priority: Blocker
> Fix For: 1.5
>
> Attachments: ignite-1272.patch, ignite-1272.patch
>
>
> The reason is that a loader is not passed to required places when needed.
> Reproduced with the following tests:
> - {{IgniteCacheAbstractExecutionContextTest.testUserClassLoader()}} fails
> with PortableMarshaller enabled.
> - {{GridDeploymentMessageCountSelfTest.testCacheValueDeploymentOnPut()}}
> Another issue is when {{PortableContext}} returns {{PortableClassDescriptor}}
> by type id. Returned descriptor has a constructor which already has been
> loaded with another class loader. Fix is not trivial and issue is reproduced
> with {{GridP2PRemoteClassLoadersSelfTest}}
> Look for corresponding TODOs in the code.
> Unmute tests when fixed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1788) Duplicate check of IGFS configuration
Vasiliy Sisko created IGNITE-1788:
-
Summary: Duplicate check of IGFS configuration
Key: IGNITE-1788
URL: https://issues.apache.org/jira/browse/IGNITE-1788
Project: Ignite
Issue Type: Bug
Components: hadoop
Affects Versions: 1.5
Reporter: Vasiliy Sisko
Priority: Minor
Fix For: 1.5
In class org.apache.ignite.internal.processors.igfs.IgfsProcessor exist
duplicate check:
{code}
if (GridQueryProcessor.isEnabled(metaCacheCfg))
throw new IgniteCheckedException("IGFS metadata cache cannot start with
enabled query indexing.");
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-1786) Need to implement ODBC driver for Ignite
[ https://issues.apache.org/jira/browse/IGNITE-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-1786: --- Assignee: Igor Sapego > Need to implement ODBC driver for Ignite > > > Key: IGNITE-1786 > URL: https://issues.apache.org/jira/browse/IGNITE-1786 > Project: Ignite > Issue Type: New Feature > Components: clients >Reporter: Dmitriy Setrakyan >Assignee: Igor Sapego > Fix For: 1.6 > > > # We have a C++ API for Ignite which starts JVM internally. Probably we can > just add that ODBC API there. > # Another approach is to implement really separate driver and a network > server on java side which will interact with each other. > The first one is simpler and probably more effective, but heavyweight. The > second one is probably slower but but more lightweight. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1526:
Assignee: Andrey Gura (was: Denis Magda)
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Andrey Gura
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(ServerImpl.java:3258)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essMessage(ServerImpl.java:1993)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.b
> ody(ServerImpl.java:5206)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.io.InvalidClassException:
> org.apache.ignite.internal.util.lang.G
> ridFunc$38; local class incompatible: stream classdesc serialVersionUID =
> -55433
> 49853748590486, local class serialVersionUID = -5664060422647374863
> at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:617)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:162
> 2)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 771)
> at ja
[jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14973871#comment-14973871
]
Denis Magda commented on IGNITE-1526:
-
Andrey, thanks for applying the changes.
However, have some comments so far:
1 ) This condition {{if (!F.eq(locMarshUseDfltSuid, rmtMarshUseDfltSuid) &&
locMarshUseDfltSuidBool != rmtMarshUseDfltSuidBool)}} can be simplified this
way {{if (locMarshUseDfltSuidBool != rmtMarshUseDfltSuidBool)}};
2) Please add a sanity test to be sure that no two nodes with different values
for this key will join the same cluster. A good suite candidate for the test is
{{GridDiscoveryManagerAttributesSelfTest}}.
BTW, I don't see that you took into account my previous comment
{noformat}
I would recommend not to use OptimizedMarshaller in the heterogeneous
configuration at all. The only problem is that PortableMarshaller relies on it.
So for PortableMarshaller that is being open-sourced right now I would replace
OptimizedMarshaller with JdkMarshaller in PortableMarshaller internals.
{noformat}
Do you have any other opinion?
> IBM JDK is not fully supported by the platfrom
> --
>
> Key: IGNITE-1526
> URL: https://issues.apache.org/jira/browse/IGNITE-1526
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Blocker
> Fix For: 1.5
>
>
> There are several issue related to IBM JDK.
> 1) It's not possible to compile the platform using IBM JDK ver 1.7;
> 2) Besides of the fact that two IBM nodes can connect to each other some
> functionality still doesn't work. As an example
> {{CacheClientPortablePutGetExample}} fails with the following stack trace
> {noformat}
> [14:38:56,930][ERROR][grid-nio-worker-0-#26%null%][TcpCommunicationSpi]
> Caught unhandled exception in NIO worker thread (restart the node).
> class org.apache.ignite.IgniteException: Invalid field type: 0
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readRemovedField(PortableDirectMessageReader.java:670)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readFieldHeader(PortableDirectMessageReader.java:520)
> at
> org.gridgain.grid.internal.communication.PortableDirectMessageReader.readMessage(PortableDirectMessageReader.java:339)
> at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:248)
> at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:76)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:103)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:122)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2078)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:172)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:858)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeys(GridNioServer.java:1397)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1339)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1223)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:108)
> at java.lang.Thread.run(Thread.java:801)
> {noformat}
> 3) Oracle JVM based server node fails to connect to IBM server node producing
> the stack trace below. Tested with JDK and Portable marshallers.
> {noformat}
> [13:47:33,935][SEVERE][tcp-disco-msg-worker-#2%null][TcpDiscoverySpi] Failed
> to
> unmarshal discovery data for component: 0
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> wit
> h given class loader: sun.misc.Launcher$AppClassLoader@56092666
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:105)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMar
> shaller.java:68)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDis
> coverySpi.java:1697)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.proc
> essNodeAddedMessage(Se
