> The command stream is serial, and there would be no semantic
> difference with this feature. The only difference is that
> reserve-with-timeout might, at its discretion, time out earlier than
> normal.
>From the server side it's ok to read next command from client when it
is in reserve
mode. But, how would you suggest coping with this on client side? For
example let's
see this snippet:
job = client.reserve()
When you execute this command, client is blocked (at least in python
and java implementations)
and waits for a response. So if you want to send any other command,
you have to do it in other
thread which shares this client. If we want to work with client in one
thread, we have to apply some
tricks like listener to reserve completion event, of Future (in java).
But it involves implicit
multithreading or event-loop in the client.
I tried to write some meta code here to be sure that I understood you
correctly. Am I right here, or I missed
something in your explanations? :
------------------------------------------------------------------------------------------------------------------------------------------------
class SmartClient {
FutureJob reserve() {
FutureJob j;
start Thread {
try {
job = client.reserve()
j.job = job
j.reserved = true
catch (TimedOutException e) {
j.cancelled = true
}
}
return j;
}
}
class FutureJob {
Job job;
boolean cancelled = false;
boolean reserved = false;
}
--------------------------------------------
Usage code:
FutureJob j = smartClient.reserve()
int i = 0;
while(not j.reserved and not j.cancelled) {
print "Still don't get a job"
if (++i == 10) {
// already checked 10 times, let's kick some buried jobs
client.kick(100);
// here the server side returns TIMED_OUT ,
// we catch this exception and exit this while loop
// because of j.cancelled == true
} else {
sleep(1000);
}
}
if (j.reserved) {
job = j.job
// do some useful staff
} else {
assert j.job == null
// we are here because we sent kick() during reserve
}
-------------------------------------------------------------------------------------------------------------------------------------------
Best regards,
Andrew
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
