Which client for an JEE application?

Dear all,

I am integrating ES in one of our application. The application itself is
a classical JEE application based on Glassfish. Among other things the
application will be responsible for updating the documents in ES. So
which client can I use? I assume that node client as well as the
transport client manage their own thread pool? Or should I use only the
Jest client? So, which of the available Java clients does not conflict
the JEE requirement not to manage your own thread pool in your application?

It would be great if someone could change his experience on ES and JEE
with us.

Best,

Oliver

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

1 Like

I use TransportClient as a singleton instantiated by web app context
listener in my JEE environments, Glassfish, JBoss, or Jetty.

While NodeClient has no config for TCP/IP, TransportClient is most flexible
for remote access via network interfaces. It is recommended not to run
frontends like JEE servers on the same server, so an ES data node can run
with best resource usage.

Maybe I don't understand the threadpool question. The threadpool in the ES
client is builtin, you can't disable it, otherwise, you simply can't
contact other nodes. There are a lot of config options to tailor the client
threadpool.

Why are you asking for conflict with JEE requirements? I am not aware of
any conflicts. ES TransportClient is easy to use.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Am 27.07.13 21:01, schrieb joergprante@gmail.com:

Why are you asking for conflict with JEE requirements? I am not aware of
any conflicts. ES TransportClient is easy to use.

I am asking because of EJB restriction not to "create or manage threads"
in your application [1]. So using a component that has its own thread
management would violate this requirement. Mostly its work but I prefer
to respect the EJB restrictions.

Best,

Oliver

[1]: http://www.oracle.com/technetwork/java/restrictions-142267.html)

Jörg

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

1 Like

Yeah. You're not suppose to do that but it works well.
What you should avoid is to reload your webapp without stopping the container (redeploy for example). You will get OOM as some threads won't be stopped (old issue in Guava as far as I remember).

I used Node Client first and then Transport client within Jboss and did not see any particular issue.

HTH

David :wink:
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

Le 28 juil. 2013 à 17:56, "Oliver B. Fischer" mailsink@swe-blog.net a écrit :

Am 27.07.13 21:01, schrieb joergprante@gmail.com:

Why are you asking for conflict with JEE requirements? I am not aware of
any conflicts. ES TransportClient is easy to use.

I am asking because of EJB restriction not to "create or manage threads" in your application [1]. So using a component that has its own thread management would violate this requirement. Mostly its work but I prefer to respect the EJB restrictions.

Best,

Oliver

[1]: http://www.oracle.com/technetwork/java/restrictions-142267.html)

Jörg

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

1 Like