EOFException when using REST API

473 views
Skip to first unread message

Daniel E

unread,
May 3, 2011, 2:38:02 PM5/3/11
to Hazelcast
I've noticed that whenever a message is sent to Hazelcast through the
REST API (for instance, putting an object into a map), it logs a WARN
level message indicating there was an EOFException.
I traced this code in the debugger and found that
com.hazelcast.nio.ReadHandler.handle() throws an EOFException whenever
the number of readBytes = -1.

It seems to me that it is an expected state for the socket to
eventually be closed which would cause readBytes to be -1, so I'm not
sure why an EOFException is thrown nor why it would be logged since
that would mean that every single request to the REST API would result
in a WARN being logged.

Is there some different code path that causes a clean close of the
socket? I've try hitting the API with an application called RESTClient
and also with curl. Both generate this WARN.

Talip Ozturk

unread,
May 4, 2011, 5:29:26 AM5/4/11
to haze...@googlegroups.com
You are looking at the right place. Yes it is a normal disconnection.
We logged disconnections as WARNING because we wanted to watch the
cluster member disconnections. Because cluster members rarely
disconnect. But as you stated REST client disconnections are quite
normal and expected. Maybe we should log them as INFO.

Are you OK getting connections and disconnections logged as INFO? Does
it bother you at all?

http://twitter.com/oztalip

> --
> You received this message because you are subscribed to the Google Groups "Hazelcast" group.
> To post to this group, send email to haze...@googlegroups.com.
> To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.
>
>

Talip Ozturk

unread,
May 5, 2011, 5:45:21 AM5/5/11
to haze...@googlegroups.com
REST Queue.poll support is also added.

HTTP DELETE
http://member-ip:5701/hazelcast/rest/queues/myq/3

means

Hazelcast.getQueue("myq").poll(3, SECONDS);

http://twitter.com/oztalip

Daniel E

unread,
May 5, 2011, 5:44:24 PM5/5/11
to Hazelcast
No, in our performance tests, we are seeing some degraded throughput
and client visible errors when using the built in Hazelcast REST API
vs a simple one written with Jetty. Trying to get a complete set of
tests and numbers before reporting.

I was hesitant to add any support for polling the queue because it
seems to me that it is difficult to make any guarantee that the client
received the polled item before closing the transaction or removing
the item without a follow-up request. That could cause items to be
removed from the queue without the object being processed.

On May 5, 5:45 am, Talip Ozturk <ta...@hazelcast.com> wrote:
> REST Queue.poll support is also added.
>
> HTTP DELETEhttp://member-ip:5701/hazelcast/rest/queues/myq/3
>
> means
>
> Hazelcast.getQueue("myq").poll(3, SECONDS);
>
> http://twitter.com/oztalip
>
>
>
>
>
>
>
> On Wed, May 4, 2011 at 12:29 PM, Talip Ozturk <ta...@hazelcast.com> wrote:
> > You are looking at the right place. Yes it is a normal disconnection.
> > We logged disconnections as WARNING because we wanted to watch the
> > cluster member disconnections. Because cluster members rarely
> > disconnect. But as you stated REST client disconnections are quite
> > normal and expected. Maybe we should log them as INFO.
>
> > Are you OK getting connections and disconnections logged as INFO? Does
> > it bother you at all?
>
> >http://twitter.com/oztalip
>

Talip Ozturk

unread,
May 5, 2011, 6:13:59 PM5/5/11
to haze...@googlegroups.com
On Fri, May 6, 2011 at 12:44 AM, Daniel E <deins...@gmail.com> wrote:
> No, in our performance tests, we are seeing some degraded throughput
> and client visible errors when using the built in Hazelcast REST API
> vs a simple one written with Jetty.  Trying to get a complete set of
> tests and numbers before reporting.
>
> I was hesitant to add any support for polling the queue because it
> seems to me that it is difficult to make any guarantee that the client
> received the polled item before closing the transaction or removing
> the item without a follow-up request.  That could cause items to be
> removed from the queue without the object being processed.


I just did a quick performance test.. single thread putting 5000 items
and logging the time it takes.

You can find the code below. Just copy and run. It takes about 1500ms
to offer 5000 items. Here is the complete output on my laptop:

Took 4275
5000
Took 2535
5000
Took 2495
5000
Took 1397
5000
Took 1368
5000
Took 1471
5000
Took 1374
5000
Took 1512
5000
Took 1392
5000
Took 1378
5000
Took 1377
5000
Took 1381
5000
Took 1391
5000
Took 1398
5000
Took 1428
5000

-------------------------------------------------------------------


import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.IQueue;

import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLConnection;

public class HttpUtil {

public static void post(String httpURL, byte[] data) {
try {
URL url = new URL(httpURL);
URLConnection conn = url.openConnection();
conn.setDoOutput(true);
DataOutputStream dos = new DataOutputStream(conn.getOutputStream());
if (data != null) {
dos.write(data);
}
dos.flush();
BufferedReader rd = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
String line;
while ((line = rd.readLine()) != null) {
// do nothing
}
dos.close();
rd.close();
} catch (Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) {
IQueue queue = Hazelcast.getQueue("default");
while (true) {
long start = System.currentTimeMillis();
for (int i = 0; i < 5000; i++) {

post("http://127.0.0.1:5701/hazelcast/rest/queues/default/item" + i,
null);
}
System.out.println("Took " + (System.currentTimeMillis() - start));
System.out.println(queue.size());
queue.clear();
}
}
}

Reply all
Reply to author
Forward
0 new messages