Blocking Requests Interrupts

[T M]

Hi All,

I've been trying to setup a thread that works in the background
waiting to pop log events off the queue and write them to a log
database.

It is running inside of tomcat. The controllers pull a jedis instance
out of the jedis pool and pushes the log onto the logging list.

The worker is spawned inside the context and runs in the background
reading the logs and writing them to a db so that we can have the
controller return as quickly as possible.

Everything is working smoothly except when I want to kill the service.
Since the thread blocks on brpoplpush/blpop waiting for a log event,
when we stop the application we want to interrupt the blocking event
and then exit the thread properly.

None of the calls throw an interrupted exception so I can't try and
catch one within the thread to skip the blocking. I have played with
setting a timeout but I'd rather not have to set a small timeout since
we want the thread to be killed within a few seconds of shutting it
down meaning we'd have a 1 second timeout or something like that.

Has anyone had any experience with this? Would it be an idea to make
an interruptible version of these calls? Happy to contribute code, was
looking more for a discussion at this stage!

Cheers Guys

[Jonathan Leibiusky]

So if I understood correctly, you are killing the tomcat process which has threads blocking on a brpoplpush and it won't throw a InterrupedException?

[T M]

Hi.

Yes, currently we have a thread running off rabbitmq (legacy app) and
redis (new app) that pulls logs. When the process is taken down it
calls

thread.interrupt() on each log worker.

The rabbitmq client has a blocking request that throws an interrupted
exception which we catch and the thread then exits normally (we set
the while flag to false and the thread exits).
The jedis client thread ignores the interrupt and stays active in the
background. I am not sure how to interrupt brpoplpush to kill the
thread.

If there's a better way to Implement this i'd be very grateful.

Thanks

[Peter Neubauer]

Hi there,

I have exactly the same problem for SUBSCRIBE - I am just not able to kill the thread in a consistent way. Is there anything available to exit the blocking calls that sit in a background thread?

/peter

On Thursday, February 7, 2013 9:16:08 AM UTC+1, Xiu Calvin wrote:

Hi, Any updates on this ?

On Saturday, October 20, 2012 7:19:57 PM UTC+8, aji wrote:

Hi, Any updates on this ? 

[임정택]

Hello.

As I tested recent, Interrupting thread to Blocking socket with waiting for response is no effect.

Jedis blpop / brpop implementation uses infinite timeout, so we can meet this situation.

I think there're two ways of avoid it.

1. socket.close() releases this situation - equvalent statement for jedis is jedis.disconnect() or jedis.close()

But jedis instance is not thread-safe, and it could be broken when jedis.disconnect() is called.

So we should to discard jedis instance immediately. (If you're using pool, call JedisPool.returnBrokenResource())

Please see https://gist.github.com/HeartSaVioR/11158991 for details.

2. specify short timeout for each blpop/brpop call, as you would to avoid.

Actually I think this is better solution, but solution 1 is not bad if you clean up perfectly.

Hope this helps.

Sincerely

Jungtaek Lim (HeartSaVioR)

2011년 7월 22일 금요일 오후 12시 46분 40초 UTC+9, T M 님의 말:

[임정택]

Hello.

If you have JedisPubSub instance, it's time to use JedisPubSub.unsubscribe() method.

If you cannot pass JedisPubSub instance to thread you're in, Jedis.discard() or Jedis.close() helps.

But jedis instance is not thread-safe, and it could be broken when jedis.disconnect() is called.

So we should to discard jedis instance immediately. (If you're using pool, call JedisPool.returnBrokenResource())

Hope this helps.

Regard.

Jungtaek Lim (HeartSaVioR)

2014년 4월 21일 월요일 오전 7시 22분 47초 UTC+9, Peter Neubauer 님의 말:

[Peter Neubauer]

Thank you so much Jungtaek,

this seems to work. Your help is much appreciated!

/peter

G:  neubauer.peter
S:  peter.neubauer
P:  +46 704 106975
L:   http://www.linkedin.com/in/neubauer
T:   @peterneubauer

Open Data    - @mapillary
Open Source - @neo4j
Open Future  - @coderdojo

--
You received this message because you are subscribed to a topic in the Google Groups "Jedis" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jedis_redis/u1h4-7dlrAs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.