You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ivan Daschinskiy (Jira)" <ji...@apache.org> on 2020/04/22 17:44:00 UTC

[jira] [Comment Edited] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter

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

Ivan Daschinskiy edited comment on IGNITE-12827 at 4/22/20, 5:43 PM:
---------------------------------------------------------------------

[~nizhikov] This issue, to be honest, not about OOM on special case, but about conter intuitive API and confusing behaviour.
Let's explain. Consider this code:

{code:java}
 @Test
    public void testCoreDump() throws Exception {
        BinaryMarshaller marsh = binaryMarshaller();

        BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);

        List<Value> col = IntStream.range(0, 1000).mapToObj(Value::new).collect(Collectors.toList());

        marsh.binaryMarshaller().writer(os).marshal(col);

        MappedFile memFile = new MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());

        long ptr = memFile.address();

        GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr, os.position());

        BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr, os.capacity());

        List<BinaryObject> desCol = (List<BinaryObject>)marsh.binaryMarshaller().reader(is)
                .readObjectDetached();

        memFile.close();

        assertEquals(500, (int)desCol.get(500).field("val"));
    }
{code}

Let's assume that once upon a time one igniter start to develop unmarshalling from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully. 

I think that confusing and errorneous API is worse, than small performance penalty in some cases (and, as you can find in my report, in many cases, when collection is large enough or object is not so small, has performance benefits). Correctness is worth more than performance.



was (Author: ivandasch):
[~nizhikov] This issue, to be honest, not about OOM on special case, but about conter intuitive API and confusing behaviour.
Let's explain. Consider this code:

{code:java}
 @Test
    public void testCoreDump() throws Exception {
        BinaryMarshaller marsh = binaryMarshaller();

        BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);

        List<Value> col = IntStream.range(0, 1000).mapToObj(Value::new).collect(Collectors.toList());

        marsh.binaryMarshaller().writer(os).marshal(col);

        MappedFile memFile = new MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());

        long ptr = memFile.address();

        GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr, os.capacity());

        BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr, os.capacity());

        List<BinaryObject> desCol = (List<BinaryObject>)marsh.binaryMarshaller().reader(is)
                .readObjectDetached();

        memFile.close();

        assertEquals(500, (int)desCol.get(500).field("val"));
    }
{code}

Let's assume that once upon a time one igniter start to develop unmarshalling from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully. 

I think that confusing and errorneous API is worse, than small performance penalty in some cases (and, as you can find in my report, in many cases, when collection is large enough or object is not so small, has performance benefits). Correctness is worth more than performance.


> OutOfMemory exception when calling grid service from .NET with user type array parameter
> ----------------------------------------------------------------------------------------
>
>                 Key: IGNITE-12827
>                 URL: https://issues.apache.org/jira/browse/IGNITE-12827
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 2.8
>            Reporter: Alexey Kukushkin
>            Assignee: Ivan Daschinskiy
>            Priority: Major
>              Labels: sbcf
>             Fix For: 2.9
>
>         Attachments: ignite-12827-vs-2.8.patch
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to Java OutOfMemory exception.
> +*Reproducer*+:
>  * Limit JVM heap with 128 MB.
>  * Create a .NET or Java service with a parameter of type 
> *array of* Parameter { 
>   Id: int, 
>   *array of* ParameterValue { 
>     PeriodId: int, 
>     Value: double? 
>   }
> }
>  * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200 Parameters.
>  
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)