[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418167#comment-16418167
]
Emmanuel Lecharny commented on DIRMINA-1083:
Reads and writes are concurrent: we want to have the opportunity to abandon an
operation. We have an executor in the chain for that purpose:
{noformat}
...
if ( transport.isSSLEnabled() )
{
chain = LdapsInitializer.init( this, ( TcpTransport ) transport
);
}
else
{
chain = new DefaultIoFilterChainBuilder();
}
// Inject the codec into the chain
( ( DefaultIoFilterChainBuilder ) chain ).addLast( "codec", new
ProtocolCodecFilter( this
.getProtocolCodecFactory() ) );
// Now inject an ExecutorFilter for the write operations
// We use the same number of thread than the number of IoProcessor
// (NOTE : this has to be double checked)
( ( DefaultIoFilterChainBuilder ) chain ).addLast( "executor", new
ExecutorFilter(
new UnorderedThreadPoolExecutor( transport.getNbThreads() ),
IoEventType.MESSAGE_RECEIVED ) );
...
{noformat}
And yes, that means we may have a concurrency issue if we inject a
{{SslFilter}} in the chain while a message is getting written back to the
client. In this case, such a message may 'collide' with the handshake messages.
What I don't get is why it was working in {{2.0.16}} and not anymore...
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417792#comment-16417792
]
Jonathan Valliere commented on DIRMINA-1083:
Its really starting to sound like there is a concurrency issue in Apache
Directory with inserting the SSL filter. Are read and writes fully concurrent
with each other in MINA? If they aren't, I could totally see an asynchronous
write at the same time of the SSL Filter insertion causing major problems.
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417756#comment-16417756
]
Emmanuel Lecharny commented on DIRMINA-1083:
Note that a better test to mimic my code would be to establish a connection,
exchange some data, then switch to {{TLS}}. I can write such a test.
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417753#comment-16417753
]
Emmanuel Lecharny commented on DIRMINA-1083:
Yes : {{SslFilterTest}}. It uses a simple socket as a client, not a Connector.
For a {{Connector }}+ {{Acceptor}} test with SSL, use
{{ConnectorTest.testTCPWithSSL}}.
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417753#comment-16417753
]
Emmanuel Lecharny edited comment on DIRMINA-1083 at 3/28/18 5:01 PM:
-
Yes : {{SslFilterTest}}. It uses a simple socket as a client, not a Connector.
For a {{Connector}} + {{Acceptor}} test with SSL, use
{{ConnectorTest.testTCPWithSSL}}.
was (Author: elecharny):
Yes : {{SslFilterTest}}. It uses a simple socket as a client, not a Connector.
For a {{Connector }}+ {{Acceptor}} test with SSL, use
{{ConnectorTest.testTCPWithSSL}}.
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417718#comment-16417718
]
Jonathan Valliere commented on DIRMINA-1083:
Does MINA has a loopback SSL test as part of test suite?
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417718#comment-16417718
]
Jonathan Valliere edited comment on DIRMINA-1083 at 3/28/18 4:45 PM:
-
Does MINA have a loopback SSL test as part of test suite?
was (Author: johnnyv):
Does MINA has a loopback SSL test as part of test suite?
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
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)
[jira] [Updated] (DIRMINA-1081) Increasing number of ConcurrentLinkedQueue$Node objects
[ https://issues.apache.org/jira/browse/DIRMINA-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander B updated DIRMINA-1081: - Attachment: heap.png > 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-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16417054#comment-16417054
]
Emmanuel Lecharny commented on DIRMINA-1083:
It's a bit tricky, but as the failure is (almost) always reproductible, I can
already tell that the problem is when the client (\{{LDAP API}}) is initiating
the {{SSL}} handshake.
Technically speaking, the test starts a {{LDAP}} server (ApacheDS), no
{{SSL/TLS}} is involved at this point, the {{LDAPS}} port is not enabled. The
client (\{{LDAP API}}) is now sending a {{StartTLS}} extended operation (it's a
{{LDAP}} request asking the server to establish a secure communication over an
established {{TCP}} connection: we don't open a new connection).
There is a double {{SSL}} initialization occuring :
* one on the server, as we inject the {{SSLFilter}} in the {{MINA}} chain,
* one on the client, for the exact same reason.
The failure occurs on the second initialization, here are the {{MINA}} traces :
{noformat}
10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] - Processing
a MESSAGE_RECEIVED for session 1
[10:39:08] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a
MESSAGE_RECEIVED event for session 1
[10:39:08] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event
MESSAGE_RECEIVED has been fired for session 1
[10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 2
[10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 1
[10:39:08] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a
MESSAGE_RECEIVED event for session 1
[10:39:08] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event
MESSAGE_RECEIVED has been fired for session 1
[10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 2
[10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 2
[10:39:08] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 1
[10:39:08] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Firing a
MESSAGE_RECEIVED event for session 1
[10:39:08] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Adding the SSL Filter
sslFilter to the chain
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session Server[1](no
sslEngine) Initializing the SSL Handler
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session Server[1](no
sslEngine) SSL Handler Initialization done.
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Server[1](ssl...) : Starting the first handshake
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session
Server[1](ssl...) processing the NEED_UNWRAP state
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Server[1](ssl...): Writing Message : WriteRequest: HeapBuffer[pos=0 lim=40
cap=40: 30 26 02 01 03 78 21 0A 01 00 04 00 04 00 8A 16...]
[10:39:09] DEBUG [org.apache.mina.filter.codec.ProtocolCodecFilter] -
Processing a MESSAGE_RECEIVED for session 2
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Server[1](ssl...): Writing Message : MessageWriteRequest, parent : WR
WrapperWriteRequest: StartTlsResponse : Ldap Result
Result code : (SUCCESS) success
Matched Dn : 'null'
Diagnostic message : 'null'
[10:39:09] DEBUG [org.apache.mina.core.filterchain.IoFilterEvent] - Event
MESSAGE_RECEIVED has been fired for session 1
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Adding the SSL Filter
sslFilter to the chain
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session Client[2](no
sslEngine) Initializing the SSL Handler
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session Client[2](no
sslEngine) SSL Handler Initialization done.
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Client[2](ssl...) : Starting the first handshake
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session
Client[2](ssl...) processing the NEED_WRAP state
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Client[2](ssl...): Writing Message : WriteRequest: HeapBuffer[pos=0 lim=302
cap=528: 16 03 03 01 29 01 00 01 25 03 03 5A BB 54 AD 04...]
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslHandler] - Session
Client[2](ssl...) processing the NEED_UNWRAP state
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session
Server[1](ssl...): Message received : HeapBuffer[pos=0 lim=302 cap=32768: 16 03
03 01 29 01 00 01 25 03 03 5A BB 54 AD 04...]
[10:39:09] DEBUG [org.apache.mina.filter.ssl.SslFilter] - Session Client[2]:
Writing Message : WriteRequest: HeapBuffer[pos=0 lim=7 cap=8: 15 03 01 00 02 01
00]
[10:39:09] DEBUG
[jira] [Commented] (DIRMINA-1083) Regression on SSL connection
[
https://issues.apache.org/jira/browse/DIRMINA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416985#comment-16416985
]
Emmanuel Lecharny commented on DIRMINA-1083:
I'm investigating atm. What I can say for sure is that I don't see this issue
when using MINA 2.0.16.
> Regression on SSL connection
>
>
> Key: DIRMINA-1083
> URL: https://issues.apache.org/jira/browse/DIRMINA-1083
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.17
>Reporter: Emmanuel Lecharny
>Priority: Major
> Fix For: 2.0.18
>
>
> We are using MINA in Apache Directory. After having moved to MINA 2.0.17, we
> now have failures like :
> {noformat}
> Running org.apache.directory.shared.client.api.LdapSSLConnectionTest
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
> at
> org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
