[
https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909111#comment-14909111
]
Denis Magda edited comment on IGNITE-1526 at 9/26/15 5:50 AM:
--------------------------------------------------------------
{quote}
Denis, I can't reproduce issues 2 (works correctly under Linux)
{quote}
Hey, we faced with an operation system related bug. You definitely will be able
to reproduce this on Windows.
{quote}
The reason is that IBM and Oracle JDK differently works with serialVersionUID
for inner anonymous classes. It is easy to reproduce. Just write object under
some JDK:
{quote}
That is not only true for anonymous classes but rather for every class that
doesn't have {{serialVersionUID}} field. If a class doesn't have such a field
then it's up to a compiler to initialize it to a value it likes.
To be more specific
(http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html):
If a serializable class does not explicitly declare a serialVersionUID, then
the serialization runtime will calculate a default serialVersionUID value for
that class based on various aspects of the class, as described in the Java(TM)
Object Serialization Specification. However, it is strongly recommended that
all serializable classes explicitly declare serialVersionUID values, since the
default serialVersionUID computation is highly sensitive to class details that
may vary depending on compiler implementations, and can thus result in
unexpected InvalidClassExceptions during deserialization. Therefore, to
guarantee a consistent serialVersionUID value across different java compiler
implementations, a serializable class must declare an explicit serialVersionUID
value. It is also strongly advised that explicit serialVersionUID declarations
use the private modifier where possible, since such declarations apply only to
the immediately declaring class--serialVersionUID fields are not useful as
inherited members. Array classes cannot declare an explicit serialVersionUID,
so they always have the default computed value, but the requirement for
matching serialVersionUID values is waived for array classes.
It means that we can't use JdkMarshaller in a heterogeneous scenario.
In my understanding the last chance is to switch to a PortableMarshaller system
wide. However this is not an easy task.
Just look for {{new JdkMarshaller()}} throughout the code and we will see that
JdkMarshaller is used in many components.
Some of them, like DiscoverySpi, start using marshalling functionality before
PortableMarshaller is initialized.
One more obstacle is that PortableMarshaller may switch to Optimized or Jdk
marshallers for classes that override {{writeObject}} and {{readObject}}
methods. Such classes provide custom serialization logic and PortableMarshaller
can't ignore this fact. Look at
{{PortableClassDescriptor.initUseOptimizedMarshallerFlag}}.
was (Author: dmagda):
{quote}
Denis, I can't reproduce issues 2 (works correctly under Linux)
{quote}
Hey, we faced with an operation system related bug. You definitely will be able
to reproduce this on Windows.
{quote}
The reason is that IBM and Oracle JDK differently works with serialVersionUID
for inner anonymous classes. It is easy to reproduce. Just write object under
some JDK:
{quote}
That is not only true for anonymous classes but rather for every class that
doesn't have {{serialVersionUID}} field. If a class doesn't have such a field
then it's up to a compiler to initialize it to a value it likes.
To be more specific
(http://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html):
{noformat}
If a serializable class does not explicitly declare a serialVersionUID, then
the serialization runtime will calculate a default serialVersionUID value for
that class based on various aspects of the class, as described in the Java(TM)
Object Serialization Specification. However, it is strongly recommended that
all serializable classes explicitly declare serialVersionUID values, since the
default serialVersionUID computation is highly sensitive to class details that
may vary depending on compiler implementations, and can thus result in
unexpected InvalidClassExceptions during deserialization. Therefore, to
guarantee a consistent serialVersionUID value across different java compiler
implementations, a serializable class must declare an explicit serialVersionUID
value. It is also strongly advised that explicit serialVersionUID declarations
use the private modifier where possible, since such declarations apply only to
the immediately declaring class--serialVersionUID fields are not useful as
inherited members. Array classes cannot declare an explicit serialVersionUID,
so they always have the default computed value, but the requirement for
matching serialVersionUID values is waived for array classes.
{noformat}
It means that we can't use JdkMarshaller in a heterogeneous scenario.
In my understanding the last chance is to switch to a PortableMarshaller system
wide. However this is not an easy task.
Just look for {{new JdkMarshaller()}} throughout the code and we will see that
JdkMarshaller is used in many components.
Some of them, like DiscoverySpi, start using marshalling functionality before
PortableMarshaller is initialized.
One more obstacle is that PortableMarshaller may switch to Optimized or Jdk
marshallers for classes that override {{writeObject}} and {{readObject}}
methods. Such classes provide custom serialization logic and PortableMarshaller
can't ignore this fact. Look at
{{PortableClassDescriptor.initUseOptimizedMarshallerFlag}}.
> 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: ignite-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 java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProces
> sor$DiscoveryDataItem.readExternal(GridContinuousProcessor.java:1455)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:183
> 7)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 796)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at
> org.apache.ignite.internal.util.IgniteUtils.readList(IgniteUtils.java
> :5109)
> at
> org.apache.ignite.internal.util.IgniteUtils.readCollection(IgniteUtil
> s.java:1618)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProces
> sor$DiscoveryData.readExternal(GridContinuousProcessor.java:1371)
> at
> java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:183
> 7)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1
> 796)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshalle
> r.java:102)
> ... 6 more
> {noformat}
> 4) Oracle JVM based client node is partially connected to IBM server node.
> The server node updates its topology while the client is hanging with the
> stack trace below. Tested with JDK and Portable marshallers.:
> {noformat}
> "main" prio=6 tid=0x00000000001ee800 nid=0x1f44 waiting on condition
> [0x00000000025ce000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000007d7ad4478> (a
> java.util.concurrent.CountDownLatch$Sync)
> 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 java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:252)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1815)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:252)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:666)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1485)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:908)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1617)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1484)
> - locked <0x00000007d7bbb918> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:965)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:892)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:784)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:705)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:576)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:546)
> at org.apache.ignite.Ignition.start(Ignition.java:346)
> {noformat}
> IBM SDK implements {{sun.misc.Unsafe}}. However there is no guarantee that it
> works the same way Oracle's does.
> In all the test the following JDK versions were used:
> 1) IBM
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pwa6470sr8fp10-20141219_01(SR8 FP10))
> IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 Compressed References
> 2014121
> 6_227497 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR8_20141216_0955_B227497
> JIT - r11.b07_20141003_74578.05
> GC - R26_Java726_SR8_20141216_0955_B227497_CMPRSS
> J9CL - 20141216_227497)
> JCL - 20141217_01 based on Oracle jdk7u75-b12
> 2) Oracle
> java version "1.7.0_67"
> Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
