[lovelyliatroim]

Looks good......


Cheers Manik.

LL

[lovelyliatroim]

Actually.......just thinking, i dont see where you are keeping hold of the original write lock or am i not seeing something


T1 gets write lock
T2 waits for lock
T1 Throws exception
T2 acquires lock
T2 throws exception
T1 kicks off re-initialisation of component
T3 acquires lock
T3 writes but doesnt read
T1 successfully restarted connection
T2 starts re-init process (Now T2 never executed while T1 was re-init)
T3 reads.......

I dont see where you are holding the original write lock, i dont think you can release it until you have cleaned up the socket or are you keeping a hold of the lock somewhere that i dont see?? As soon as you throw the IOException you loose your writeLock and if thats the case the next thread can step in and use the in and out streams while the previous thread re-creates them!!

[manik]

I don't rely on that lock. This assumes that the restart process will take a while (a few seconds, maybe) so that other threads will get the lock on the monitor, enter the sync block as well, and then also attempt to perform a restart. And here is where they block (on restartComponent()) until the first restarter finishes, then they can all resume.

Your approach - to have the restart call within the sync block - is also valid, but it would mean repeating the restart try/catch block for every cache loader method.

[manik]

Another approach could be to acquire the lock before invoking the operational call in invokeWithRetries(). Still a bit coarse grained though.

Anyway, all this is due for redesign in the next major release, using a more flexible and highly performant transport like Netty, MINA or XNIO. Actually, more likely, I'd abstract the transport away so that we could provide impls based on all 3 of the above, and in future on NIO2 with JDK 7.

[lovelyliatroim]

I just dont like the way the input and output streams are essentially left unprotected. The fact that you can use the old outputstream and with the call for read you can be using the new input stream, so what happens when that scenario occurs??

T1 acquires lock
T2 waits
T1 throws exception
T2 now has the lock
T2 writes but doesnt read
T1 creates new socket
T2 attempts to read but is now using the new sockets input stream......what happens to him now? He will probably timeout and cycle will restart.


On another note, it would be great as well if one could make a bulk get, so retrieving many Fqns in one call, I have the scenario where a client might want 20 data items from the server, 10 of those data items live on a remote cache. Clients timeout is 5 seconds, now remote server is down, i currently make 10 get calls remotely but if the remote server is down and i have a timeout of 1 second, the client will timeout before i even finish making the 10 calls.

So if i made one bulk call for all 10 then i would timeout just once and still be able to provide 2nd best data to the client.


Cheers,
LL

[lovelyliatroim]

Another scenario that can currently happen is this


T1 acquires lock
T1 Writes and attempts to read but times out and throws exception
T2 acquires lock
T2 Writes
T2 Reads but he will read T1s response (not 100% sure but I would say it would)
T1 Resets the socket


Now if an app starts returning wrong data to what it asked for........would lead to alot of problems.

[manik]

On another note, it would be great as well if one could make a bulk get, so retrieving many Fqns in one call, I have the scenario where a client might want 20 data items from the server, 10 of those data items live on a remote cache. Clients timeout is 5 seconds, now remote server is down, i currently make 10 get calls remotely but if the remote server is down and i have a timeout of 1 second, the client will timeout before i even finish making the 10 calls.

So if i made one bulk call for all 10 then i would timeout just once and still be able to provide 2nd best data to the client.

Create a JIRA request for this.

[lovelyliatroim]

Done

https://jira.jboss.org/jira/browse/JBCACHE-1464