ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Magda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-1526) IBM JDK is not fully supported by the platfrom
Date Sat, 26 Sep 2015 05:45:04 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14909111#comment-14909111
] 

Denis Magda commented on IGNITE-1526:
-------------------------------------

{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)

Mime
View raw message