Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

I can't stop indefinite loop in asynchrnous method  RSS feed

 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't know how to close this method running asynchronously and it's not because f a lack of researches :

 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is Client? Is it a class you created or a third-party class from a library? What does its Javadoc say about its isDone() method, and are there any methods to tell it that its done?

Ideally I would not rely on just the client to determine when you are done. Use an instance field boolean in your service as a flag, and have a method to set it to true when the service should exit. You can then use both the flag and the client.isDone() method to determine when to exit.

Don't forget to make the flag volatile or use an AtomicBoolean so that it is threadsafe.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike. J. Thompson wrote:What is Client?
It's twitter streaming client. I'm not sure when the client is done, the client reconnects automatically. But ultimately it should never be done since the stream should run as long as the app is running.

I just took a glance at the code and it is like so ::


Mike. J. Thompson wrote:Don't forget to make the flag volatile or use an AtomicBoolean so that it is threadsafe.


Oh god, I used a normal boolean to do that and it didn't work. Is that why ? I used a normal thread instead because I was annoyed I couldn't make it work.

So I'd like to have your opinion on which method I should use, a non managed thread or a managed one and a volatile boolean.
My current code looks like this (I'm not even sure it's entirely thread safe, especially the list in backgroundtask) :





So yeah:


should be better in your opinion ?
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cedric Bosch wrote:
Mike. J. Thompson wrote:Don't forget to make the flag volatile or use an AtomicBoolean so that it is threadsafe.


Oh god, I used a normal boolean to do that and it didn't work. Is that why ? I used a normal thread instead because I was annoyed I couldn't make it work.


Well I can't see the code where you used a boolean so I don't know if there are other problems with it, but certainly if you have two threads accessing shared memory without synchronization then the code is not thread safe. That situation is what is called a data race, and basically it means that if your first thread writes to the variable there is no guarantee when or if the second thread will see the effect of that write. It is entirely possible that you could set the boolean to false intending the second thread to exit the while loop, but the second thread will keep going forever.

Cedric Bosch wrote:I used a normal thread instead because I was annoyed I couldn't make it work.

So I'd like to have your opinion on which method I should use, a non managed thread or a managed one and a volatile boolean.


By managed thread I assume you mean you're using some kind of application framework, and it is automatically creating a second thread (hence the use of the @Asynchronous annotation)? If so then I don't have any direct experience with those sort of frameworks, but I assume that there isn't essentially any difference between the framework creating the thread for you and you creating the thread. Your issue here is in how to end the Thread, and that issue is the same whether or not the thread was created by you or the framework.

Cedric Bosch wrote:My current code looks like this (I'm not even sure it's entirely thread safe, especially the list in backgroundtask) :[/code]


Your TwitterLatestTweets class has two collections in it. One is an instance field called userIds, and one is the local variable called msgQueue. msgQueue is a LinkedBlockingQueue which is a threadsafe collection so there is nothing to worry about there. userIds is assigned a value from the return of a method call, and I don't see the implementation of that method so I don't know its runtime type. That list may or may not be thread safe.

One other thing I would say though is if the lists are only accessed from a single thread then they are guaranteed to be threadsafe no matter what their implementation is. I don't see anything in your code that looks like either of those collections is being accessed from multiple threads, but I can't be certain from just that code snippet.

Cedric Bosch wrote:[code]
AtomicBoolean continue = true;
//...
while(client.isDone() && continue){...}
[/code]
should be better in your opinion ?


Well your code snippet here won't compile. Firstly 'continue' is a Java keyword so you can't use that word as an identifier. Secondly AtomicBoolean is a class so you can't assign a primitive boolean to it. You need to create a new AtomicBoolean (as you would with any reference type).

But your overall intent is good. You will either have a volatile boolean or an AtomicBoolean, and use this flag to control the loop.

What I would say though is that I haven't seen the documentation for Client. It may tell you that you need to call a specific method on it to stop it. I would read the documentation of that class closely and see if there are any methods called something like stop(), disconnect(), close() or cancel() etc. It sounds like it has made a network connection and that should probably be closed when you stop your thread.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your input. I was away the past few days so I'm gonna play with things around tonight. The bottom line is that it actually works as intended at the moment but I was a bit anxious of using that code. I was afraid of spawning my own threads when threads should be / are managed by the container the CDI thingy.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!