Hi Dan,

1. If you use, Client.setUniqueConnectionPerThread(false); you'll get one shared connection across all threads.
2. The default behavior continues to be one connection per thread.

If you're interested in pooling, check out TrendrrBeanstalk, which was announced yesterday. I haven't pulled it down yet, but it does support client pooling.

On 11/15/2010 02:36 PM, dan wrote:
I would like to understand more about your comments.

I am implementing a Client pool because each Client opens a socket,
and even if I client.close() properly, lingering (TIME_WAIT) sockets
eventually take up all the available sockets on my machine.

1. Would whatever you're talking about simplify pooling?

2. The fact that the tube a client is using is local to a thread is
awkward in a multithreaded program, including for pooling. I'd like to
understand if that is changing.

On Nov 10, 5:49 pm, Bob Tykulsker<[email protected]>  wrote:
I was thinking about an option to instantiate the ClientImpl with either
a single, shared connected to the beanstalk daemon or per-thread,
non-shared connections to the beanstalk daemon.

On 11/10/2010 05:40 AM, Alexander Azarov wrote:

Bob, what do you mean?
On 9 ноя, 21:51, Bob Tykulsker<[email protected]>    wrote:
How about a single-threaded ClientImpl versus a multi-threaded
ClientImpl .... ?
Bob
On 11/09/2010 10:31 AM, Alexander Azarov wrote:
09.11.2010, в 21:13, dan wrote:
Aha, thanks!
May I suggest to whomever controls the docs that it be documented.
Sounds like the right thing is to watch in the run() method.
An alternative approach is to queue all the requests to "single thread" 
ExecutorService (see Executors.newSingleThreadExecutor). Probably overkill, but this 
guarantees the calls to ClientImpl are made from the same thread always.
On Nov 4, 12:23 pm, Alexander Azarov<[email protected]>      wrote:
Yes, I do understand.
There is ProtocolHandler object in ClientImpl and it is ThreadLocal:
https://github.com/RTykulsker/JavaBeanstalkClient/blob/master/src/mai...
Which means a new ProtocolHandler gets initialized watching "default"
tube only, when you call ClientImpl methods from another thread.
On 4 ноя, 06:29, Dan Frankowski<[email protected]>      wrote:
Does anyone understand why I am seeing the following behavior in
JavaBeanstalkClient?
Consumer watches a particular tube (mytube) in its constructor, then in
run() (new thread) all of a sudden it is watching the default tube again! If
I watch mytube in run() it sticks. Output and code below.
Ubuntu 10.4
beanstalk version 1.4.3-1
Java BeanstalkClient 1.2.2
All latest I can get.
Dan
*Output:
*
20101103 22:17:16 INFO: watching [mytube]
20101103 22:17:16 INFO: watching [mytube]
20101103 22:17:16 INFO: watching [default]
*Code:
*
import java.util.logging.Logger;
import com.surftools.BeanstalkClient.Client;
import com.surftools.BeanstalkClientImpl.ClientImpl;
public class Foo5 {
       private static Logger logger = Logger.getLogger(Foo5.class.getName());
       private static final String TUBE_NAME = "mytube";
       private static class Consumer implements Runnable {
           private Client client;
           public Consumer() {
               client = new ClientImpl("localhost", 11300);
               watch();
           }
           private void watch() {
               client.watch(TUBE_NAME);  // for reserve()
               client.ignore("default"); // Don't get tasks from "default"
queue
               logWatching();  // mytube
           }
           public void logWatching() {
               logger.info("watching " + client.listTubesWatched());
           }
           @Override
           public void run() {
             // watch();     // Uncomment this to watch mytube
             logWatching();  // default?!  why?
           }
       }
       public static void main(String[] args) throws Exception {
           Consumer consumer = new Consumer();
           consumer.logWatching();  // mytube
           new Thread(consumer).start();
       }
}
--
You received this message because you are subscribed to the Google Groups 
"beanstalk-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group 
athttp://groups.google.com/group/beanstalk-talk?hl=en.

--
You received this message because you are subscribed to the Google Groups 
"beanstalk-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/beanstalk-talk?hl=en.

Reply via email to