Client lefts socket in TIME_WAIT state

even though this is a bug in the example code, I am marking the bug as medium priority since the example should show to correctly use the library and this example clearly is not using it correctly

Hi Ivan

I checkin some changes to the reverseclient.java example (as well as some of the other examples) that show the proper way to use the client and should not result in a large number of sockets in TIME_WAIT when submitting many jobs.

Eric

yes, maybe is about best practice using the library rather than a bug in it

with any other library accesing a gearmand server, the normal behaviour is to see also a TIME_WAIT state for every connection done to the server, but the trick is trying to reuse connections for all the jobs sent to gearmand from a client, thus reducing the risk of running out of sockets/file descriptors

is there actual support in the library for working like this?

Yes, you can accomplish that behavior by simply re-using a single client
instance for job submission. Each instance of the GearmanClient class
will establish a single connection to the job servers that have been
registered with that client and will 're-use' that connection for all
jobs it submits to the client.

Lets a take scenario where I have an array of 1,000 strings that I want
to submit to gearman reverse function. If you did something like the
following, then all 1,000 jobs would be submitted over a single
connection and when the execution completes there should only be on
socket in TIME_WAIT state.

//create the string array
String [] myStrings = new String [] {"one","two","three" .... "nine
hundred ninety nine","one thousand"};

//create a client and register the server
GearmanClient gearmanClient = new GearmanClientImpl();
gearmanClient.addJobServer(new
GearmanNIOJobServerConnection("localhost", 4730));

//submit the jobs
GearmanJob job = null;
for (int i = 0; i < myStrings.length; i++) {
    job = GearmanJobImpl.createJob("reverse", myString[i].getBytes(), null);
    gearmanClient.submit(job);
}

//close the client
gearmanClient.shutdown();

Eric

ivan wrote:
> yes, maybe is about best practice using the library rather than a bug in
> it
>
> with any other library accesing a gearmand server, the normal behaviour
> is to see also a TIME_WAIT state for every connection done to the
> server, but the trick is trying to reuse connections for all the jobs
> sent to gearmand from a client, thus reducing the risk of running out of
> sockets/file descriptors
>
> is there actual support in the library for working like this?
>
>

thanks Eric, I should have figured it out myself before blaming the library for not such a bug :-) at least, the examples show a more clear and better use practice now

congrats for this excellent work, we are looking forward to use it asap in our environment and I'm happy to help in any way