[JBoss JIRA] (ISPN-3452) Hot Rod client socket leak
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3452?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3452:
--------------------------------------
BTW this is a hotrod client problem, but ISPN JIRA project still hasn't Client component defined so I've put it under "Remote protocols"
This is not a very well formed test but it reproduces the situation I'm talking about:
https://github.com/mlinhard/infinispan/commit/839022bad269565282bfc3b4df3...
I'm creating a server that just simply closes all the connections it accepts and an idle RemoteCacheManager that just sits there and it's evictor thread creates a new TcpTransport object every 500ms, pings the server and gets TransportException("End of stream reached!") which is swallowed.
sample output here (TRACE on org.infinispan.client.hotrod)
{code}
2013-08-29 18:21:46,215 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Created tcp transport: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35552], serverAddress=/127.0.0.1:15233, id =3}
2013-08-29 18:21:46,216 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Returning to pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35552], serverAddress=/127.0.0.1:15233, id =3}
2013-08-29 18:21:46,249 INFO (main) [org.infinispan.client.hotrod.HotRodSocketLeakTest] numActive = 0, numIdle=1
2013-08-29 18:21:46,708 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Fetching from pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35552], serverAddress=/127.0.0.1:15233, id =3}
2013-08-29 18:21:46,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] About to validate(ping) connection to server /127.0.0.1:15233. TcpTransport is TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35552], serverAddress=/127.0.0.1:15233, id =3}
2013-08-29 18:21:46,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 160
2013-08-29 18:21:46,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 12
2013-08-29 18:21:46,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 23
2013-08-29 18:21:46,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote 0 bytes
2013-08-29 18:21:46,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 3
2013-08-29 18:21:46,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 0
2013-08-29 18:21:46,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.protocol.Codec12] Wrote header for message 3. Operation code: 0x17. Flags: 0x0
2013-08-29 18:21:46,710 TRACE (ScumbagServer) [org.infinispan.client.hotrod.test.ScumbagServer] Reading and closing
2013-08-29 18:21:46,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Flushed socket: Socket[addr=/127.0.0.1,port=15233,localport=35552]
2013-08-29 18:21:46,711 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Read byte -1 from socket input in Socket[addr=/127.0.0.1,port=15233,localport=35552]
2013-08-29 18:21:46,712 TRACE (ScumbagServer) [org.infinispan.client.hotrod.test.ScumbagServer] Accepting new connection
2013-08-29 18:21:46,712 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Created tcp transport: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35553], serverAddress=/127.0.0.1:15233, id =4}
2013-08-29 18:21:46,712 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Returning to pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35553], serverAddress=/127.0.0.1:15233, id =4}
2013-08-29 18:21:47,209 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Fetching from pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35553], serverAddress=/127.0.0.1:15233, id =4}
2013-08-29 18:21:47,209 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] About to validate(ping) connection to server /127.0.0.1:15233. TcpTransport is TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35553], serverAddress=/127.0.0.1:15233, id =4}
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 160
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 12
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 23
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote 0 bytes
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 3
2013-08-29 18:21:47,210 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 0
2013-08-29 18:21:47,211 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.protocol.Codec12] Wrote header for message 4. Operation code: 0x17. Flags: 0x0
2013-08-29 18:21:47,211 TRACE (ScumbagServer) [org.infinispan.client.hotrod.test.ScumbagServer] Reading and closing
2013-08-29 18:21:47,211 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Flushed socket: Socket[addr=/127.0.0.1,port=15233,localport=35553]
2013-08-29 18:21:47,212 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Read byte -1 from socket input in Socket[addr=/127.0.0.1,port=15233,localport=35553]
2013-08-29 18:21:47,212 TRACE (ScumbagServer) [org.infinispan.client.hotrod.test.ScumbagServer] Accepting new connection
2013-08-29 18:21:47,213 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Created tcp transport: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35554], serverAddress=/127.0.0.1:15233, id =5}
2013-08-29 18:21:47,213 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Returning to pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35554], serverAddress=/127.0.0.1:15233, id =5}
2013-08-29 18:21:47,249 INFO (main) [org.infinispan.client.hotrod.HotRodSocketLeakTest] numActive = 0, numIdle=1
2013-08-29 18:21:47,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] Fetching from pool: TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35554], serverAddress=/127.0.0.1:15233, id =5}
2013-08-29 18:21:47,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory] About to validate(ping) connection to server /127.0.0.1:15233. TcpTransport is TcpTransport{socket=Socket[addr=/127.0.0.1,port=15233,localport=35554], serverAddress=/127.0.0.1:15233, id =5}
2013-08-29 18:21:47,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 160
2013-08-29 18:21:47,709 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 12
2013-08-29 18:21:47,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 23
2013-08-29 18:21:47,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote 0 bytes
2013-08-29 18:21:47,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 3
2013-08-29 18:21:47,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Wrote byte 0
2013-08-29 18:21:47,710 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.protocol.Codec12] Wrote header for message 5. Operation code: 0x17. Flags: 0x0
2013-08-29 18:21:47,711 TRACE (ScumbagServer) [org.infinispan.client.hotrod.test.ScumbagServer] Reading and closing
2013-08-29 18:21:47,711 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Flushed socket: Socket[addr=/127.0.0.1,port=15233,localport=35554]
2013-08-29 18:21:47,711 TRACE (Timer-0) [org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport] Read byte -1 from socket input in Socket[addr=/127.0.0.1,port=15233,localport=35554]
{code}
Normally we should also see "Successfully closed socket" message after TcpTransport is destroyed. but that doesn't happen.
good tool to see that Sockets are still open is http://file-leak-detector.kohsuke.org/ (pointed out by Mitchell on the forum)
> Hot Rod client socket leak
> --------------------------
>
> Key: ISPN-3452
> URL: https://issues.jboss.org/browse/ISPN-3452
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha3
> Reporter: Michal Linhard
> Assignee: Galder Zamarreño
> Priority: Critical
>
> TransportObjectFactory.validateObject swallows TransportException and doesn't properly close socket connected with the TcpTransport object.
> This way an open socket is leaked each time it's created by connection pool Evictor thread
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3452) Hot Rod client socket leak
by Michal Linhard (JIRA)
Michal Linhard created ISPN-3452:
------------------------------------
Summary: Hot Rod client socket leak
Key: ISPN-3452
URL: https://issues.jboss.org/browse/ISPN-3452
Project: Infinispan
Issue Type: Bug
Components: Remote protocols
Affects Versions: 6.0.0.Alpha3
Reporter: Michal Linhard
Assignee: Galder Zamarreño
Priority: Critical
TransportObjectFactory.validateObject swallows TransportException and doesn't properly close socket connected with the TcpTransport object.
This way an open socket is leaked each time it's created by connection pool Evictor thread
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3435) Enable tests for RemoteCache.getBulk() and keySet()
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3435?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3435:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Enable tests for RemoteCache.getBulk() and keySet()
> ---------------------------------------------------
>
> Key: ISPN-3435
> URL: https://issues.jboss.org/browse/ISPN-3435
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote protocols
> Reporter: Jiří Holuša
> Assignee: Jiří Holuša
> Fix For: 6.0.0.Beta1
>
>
> When exploring tests for HotRod client and operations getBulk() and keySet() found out that in org.infinispan.client.hotrod.BulkGetKeys*Test the inherited test methods from BaseBulkGetKeys*Test aren't running due to absent @Test annotation.
> Also in pull request added tests for getBulk() even for REPL mode.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3451:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1002602|https://bugzilla.redhat.com/show_bug.cgi?id=1002602] from NEW to CLOSED
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3200) Allow KeyFilters to be applied to listeners
by Manik Surtani (JIRA)
[ https://issues.jboss.org/browse/ISPN-3200?page=com.atlassian.jira.plugin.... ]
Manik Surtani reassigned ISPN-3200:
-----------------------------------
Assignee: Manik Surtani (was: Mircea Markus)
> Allow KeyFilters to be applied to listeners
> -------------------------------------------
>
> Key: ISPN-3200
> URL: https://issues.jboss.org/browse/ISPN-3200
> Project: Infinispan
> Issue Type: Feature Request
> Components: Listeners
> Affects Versions: 5.3.0.Final
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Labels: leads
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> When registering a listener, users should be able to provide a {{KeyFilter}}, a simple interface that determines whether a listener is invoked or not based on whether the affected key(s) matches the filter.
> The proposed API may overload the {{addListener(Object listener)}} method on {{Cache}}, adding:
> {code}
> void addListener(Object listener, KeyFilter filter);
> {code}
> where {{KeyFilter}} may be an interface that looks like:
> {code}
> public interface KeyFilter {
> boolean match(Object key);
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-3451:
-----------------------------------
True, GMU achieves (Extended-) Updated Serializability. So, if you have a read operation, you will see both A and B equals to 1 or A and B equals to 2 depending if your tx starts after or before the commit of the write transaction.
Of course we have the cost of keeping multiple versions for a key in the data container and more restrict validation phase. Also, read-only transactions can read a old snapshot (i.e. it's not the most recent). but that snapshot is always consistent!
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3451:
-------------------------------------
Even if the entries would be committed in a defined order in which they hace been written, the problem still exists due to Infinispan's distributed nature.
For simplicity let's consider that both A and B are owned by N1 and N2.
There is a moment in which the TX is committed on N2 but not yes committed on N1.
All the tx that would read the data from N2 would see the new value, the others seeing the old one.
If the users really require this semantic, they should use Flag.FORCE_WRITE_LOCK on read operations as well.
Possible that [~pruivo]'s GMU to handle this scenario implicitly, Pedro care to comment?
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-3451.
---------------------------------
Resolution: Rejected
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
> Key: ISPN-3451
> URL: https://issues.jboss.org/browse/ISPN-3451
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Alpha3
> Reporter: Radim Vansa
> Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months