[jira] [Commented] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[ https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439057#comment-16439057 ] Alexander B commented on DIRMINA-1081: -- Hi guys, I found the time to check all information. I am not sure where this problem was exactly. After some refactoring and the implementation of the WriteFuture requests it works and we do not receive this problem again. I am gonna close this issue. Thanks a lot. > Increasing number of ConcurrentLinkedQueue$Node objects > --- > > Key: DIRMINA-1081 > URL: https://issues.apache.org/jira/browse/DIRMINA-1081 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.16, 2.0.17 >Reporter: Alexander B >Priority: Major > Attachments: heap.png, linkedqueuenodes.png, recorded live > allocations.png > > > In a few issues i read, that some users detect a hugh number of > ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I > dont know if this behaviour is still an open bug, so i opened this new issue. > Attached are two screenshot made by JProfiler. It seems, that the broadcast > method references these objects and does not deallocate them. > In my point of view this behaviour was getting better by using version 2.0.17 > instead of 2.0.16, but this behaviour still exists. > > PS: I am using Java 1.8.0_161b12 64bit > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[
https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418614#comment-16418614
]
Emmanuel Lecharny commented on DIRMINA-1081:
I would add one thing:
Due to the asynchronous very nature of {{NIO}}, which is a bit masked by the
{{MINA}} framework, you can't really wait for the result of an operation (like
a broadcast), as I said before.
That means the set of futures is pretty much useless if you don't manage that
in a separate thread. Typically, if you want to execute an action when all the
sessions have been sent the message, then you have to handle each session
{{messageSent}} event, and remove the associated future from the set, up to the
point it's empty - also remove future for disconnected sessions -.
Frankly, this is quite problematic and I do think such a set of future is
pretty useless, typically because when a client brutally disconnect, the server
will not be informed, and teh session will remain forever, unless you also
manage idling sessions (something you'll have to do anyway).
I don't know what your application is doing, but you have to have that in mind,
just in case.
> Increasing number of ConcurrentLinkedQueue$Node objects
> ---
>
> Key: DIRMINA-1081
> URL: https://issues.apache.org/jira/browse/DIRMINA-1081
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.16, 2.0.17
>Reporter: Alexander B
>Priority: Major
> Attachments: heap.png, linkedqueuenodes.png, recorded live
> allocations.png
>
>
> In a few issues i read, that some users detect a hugh number of
> ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I
> dont know if this behaviour is still an open bug, so i opened this new issue.
> Attached are two screenshot made by JProfiler. It seems, that the broadcast
> method references these objects and does not deallocate them.
> In my point of view this behaviour was getting better by using version 2.0.17
> instead of 2.0.16, but this behaviour still exists.
>
> PS: I am using Java 1.8.0_161b12 64bit
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[ https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418591#comment-16418591 ] Alexander B commented on DIRMINA-1081: -- Thanks for your help and your advices. based on the IoSession count we see, that they are connected, but we will take a closer look, what they do in detail. It is true, that we do not handle the WriteFutures, we just call the broadcast-method. I will check/implement this. Thanks a lot > Increasing number of ConcurrentLinkedQueue$Node objects > --- > > Key: DIRMINA-1081 > URL: https://issues.apache.org/jira/browse/DIRMINA-1081 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.16, 2.0.17 >Reporter: Alexander B >Priority: Major > Attachments: heap.png, linkedqueuenodes.png, recorded live > allocations.png > > > In a few issues i read, that some users detect a hugh number of > ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I > dont know if this behaviour is still an open bug, so i opened this new issue. > Attached are two screenshot made by JProfiler. It seems, that the broadcast > method references these objects and does not deallocate them. > In my point of view this behaviour was getting better by using version 2.0.17 > instead of 2.0.16, but this behaviour still exists. > > PS: I am using Java 1.8.0_161b12 64bit > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[
https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417592#comment-16417592
]
Emmanuel Lecharny commented on DIRMINA-1081:
Ok, in the heap you provided, we see that 2436 messages are stacked in the
queue, and that correspond to the 1218 messages you are broadcasting.
Are you sure those messages are being read by the remote client ?
Also are you checking that the messages are being written (by checking the
futures the {{broadcast}} call returns ?)
Note that you should *not* check the futures immediately after having called
{{broadcast}}, that would block. Do so in a separate thread, or in the
{{messageSent}} event in your handler.
> Increasing number of ConcurrentLinkedQueue$Node objects
> ---
>
> Key: DIRMINA-1081
> URL: https://issues.apache.org/jira/browse/DIRMINA-1081
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0.16, 2.0.17
>Reporter: Alexander B
>Priority: Major
> Attachments: heap.png, linkedqueuenodes.png, recorded live
> allocations.png
>
>
> In a few issues i read, that some users detect a hugh number of
> ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I
> dont know if this behaviour is still an open bug, so i opened this new issue.
> Attached are two screenshot made by JProfiler. It seems, that the broadcast
> method references these objects and does not deallocate them.
> In my point of view this behaviour was getting better by using version 2.0.17
> instead of 2.0.16, but this behaviour still exists.
>
> PS: I am using Java 1.8.0_161b12 64bit
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[ https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417560#comment-16417560 ] Alexander B commented on DIRMINA-1081: -- We have some more information: In our scenario we have just one NioConnector and one NioAcceptor, that take messages and broadcast them (in this case to one client). We saw, that we have different behaviours on two different machines. On a local machine (windows10, 64bit) with a single local consumer everything works fine. On a machine (Linux) placed in a network and a consumer, which is not running on this machine but is connected via a socket connection, we create this memory problem (based on the given 8 classes, that were not deallocate (linkedqueuenodes.png)) . The results of getReadBytesThroughput() and getWrittenBytesThroughput() respectively shows values between 20 and 50 kbit/s on the connector and acceptor-side. Thats actually not much. Are there any restrictions that we have to follow using a Linux-System / or any other restrictions about network performances ? Based on (heap.png) we expect that there are mina-buffers, that are not deallocated. Thanks a lot > Increasing number of ConcurrentLinkedQueue$Node objects > --- > > Key: DIRMINA-1081 > URL: https://issues.apache.org/jira/browse/DIRMINA-1081 > Project: MINA > Issue Type: Bug > Components: Core >Affects Versions: 2.0.16, 2.0.17 >Reporter: Alexander B >Priority: Major > Attachments: heap.png, linkedqueuenodes.png, recorded live > allocations.png > > > In a few issues i read, that some users detect a hugh number of > ConcurrentLinkedQueue$Node objects, which are actually not collected by GC. I > dont know if this behaviour is still an open bug, so i opened this new issue. > Attached are two screenshot made by JProfiler. It seems, that the broadcast > method references these objects and does not deallocate them. > In my point of view this behaviour was getting better by using version 2.0.17 > instead of 2.0.16, but this behaviour still exists. > > PS: I am using Java 1.8.0_161b12 64bit > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
