Closed GoogleCodeExporter closed 9 years ago
_executorService.submit( task ) is just a method call, I don't see, how it
should block there.
Do you have a thread dump?
We can also take this to the mailing list btw.
Original comment by martin.grotzke
on 28 Feb 2012 at 12:58
Ok.Sorry, I only judge from the code it maybe hang. because i found
SynchronousExecutorService's submit just invoke task's call method.
it Equivalent to invoke task's call method.
if task's call is aync(but it is not), result.get( _sessionBackupTimeout,
TimeUnit.MILLISECONDS ) will not make sense.
(another reason i does use another memcached client which does not spport
Future instead of the client).
last,i found storeSessionInMemcached method which is invoked by task's call
method.
There is " if ( !_sessionBackupAsync ) {
try {
future.get( _sessionBackupTimeout, TimeUnit.MILLISECONDS );" sentence.
is it repeated on sentence above(in BackupSessionService.backupSession)?
Original comment by anran.gu...@gmail.com
on 3 Mar 2012 at 2:31
Not sure where you think there's an issue.
You should be aware that in BackupSessionService.backupSession the
ExecutorService (Executors.newFixedThreadPool( backupThreadCount ) or new
SynchronousExecutorService()) is executing the Callable (BackupSessionTask),
while in BackupSessionTask.storeSessionInMemcached the MemcachedClient is
performing the asynchronous action (_memcached.set). The latter is *always* run
asynchronously, therefore when msm is running in synchronous mode
(sessionBackupAsync=false), we must invoke "get" on the returned future to know
that spymemcached has processed the command.
If you still think there's an issue please provide a patch that shows what you
think should be changed.
Original comment by martin.grotzke
on 4 Mar 2012 at 12:08
Original comment by martin.grotzke
on 8 Jun 2012 at 6:52
Original issue reported on code.google.com by
anran.gu...@gmail.com
on 28 Feb 2012 at 3:32