I think you confuse two things:
- the Java platform (Java Language, Java Virtual Machine)
- the Java EE specification
These two things are different.
As the Java EE specification is community-driven and defined, it does not
mean to put any burden or restrictions on the Java platform, or on any
applications running on the JVM.
Note that ES nodes solve problems for distributed applications that Java EE
is not even aware of.
It is possible to give up certain ES features and write another ES node to
use the Java EE specification regarding the managed components and thread
pools very exactly but there is not much sense in it. Why should you expect
a Java EE container like Tomcat/Wildfly to operate like an ES cluster? They
simply can not do so and they will never do like this. You will challenge
many fields: resource allocation, reduced performance, less throughput,
less fault tolerance, distributed JVM orchestration etc.
Jörg
On Tue, Sep 9, 2014 at 9:57 AM, Tasha CARL <tasha....@gmail.com> wrote:
> >Elasticsearch was never designed to run as a container managed Java EE
>
> >component in a Java EE container, so the question about thread creation
>
> >is unrelated.
>
>
>
> That's exactly my point and that's why I ask this question.
>
>
>
> >If you want to use an ES client from within a Java EE container,
>
> >start a node client or transport client as a singleton,
>
> >and stop it when the service stops.
>
>
>
> That's the obvious way to handle this and that's exactly what I do. Still,
> you include you ES JAR in your application and this JAR creates threads out
> of the control of the Java EE container. Practically, they are part of the
> application and the ES client runs inside the Java EE container.
>
>
>
> >Can you be more specific about "strange side effects on application
> servers"?
>
>
>
> I cannot be more specific since I did not yet encounter such effects. I
> imagine that for example under heavy load, the ES client (JAR) could create
> too many threads of which the container is not aware of that together with
> the threads created by the container itself, the OS/VM limits/quota are
> hit.
>
>
>
> Tasha
>
>
>
> On 9 September 2014 09:39, joergpra...@gmail.com <joergpra...@gmail.com>
> wrote:
>
>> Your question is not very clear, but maybe you refer to JSR 236 for Java
>> EE.
>>
>> Elasticsearch was never designed to run as a container managed Java EE
>> component in a Java EE container, so the question about thread creation is
>> unrelated.
>>
>> If you want to use an ES client from within a Java EE container, start a
>> node client or transport client as a singleton, and stop it when the
>> service stops.
>>
>> Can you be more specific about "strange side effects on application
>> servers"?
>>
>> Jörg
>>
>> On Mon, Sep 8, 2014 at 9:54 PM, Tasha <tasha....@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> As you know, ElasticSearch relies a lot on multi-threading.
>>>
>>>
>>>
>>> I'm currently using ES in a Java EE 6 application (using the node client
>>> as pure client node) and the Java EE specifications state that classic
>>> thread creation (à la "new Thread() { @Override public void run() {}}") is
>>> actually forbidden.
>>>
>>>
>>>
>>> I know that it is working, at least on the application servers I know,
>>> but I'm wondering what the ES teams says to this dilemma.
>>>
>>>
>>>
>>> After all, doing something "illegal" against the specs might become
>>> blocked/impossible in the future (not likely in this case) and it might
>>> also cause strange side-effects on application servers.
>>>
>>>
>>>
>>> Your opinions?
>>>
>>>
>>>
>>> Best,
>>>
>>> Tasha
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/elasticsearch/aa786741-30fa-4ee8-a3ad-7e3b007b74de%40googlegroups.com
>>> <https://groups.google.com/d/msgid/elasticsearch/aa786741-30fa-4ee8-a3ad-7e3b007b74de%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "elasticsearch" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elasticsearch/VqJMG87S9jk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elasticsearch+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFwxuEEZ0h_WPr5S4JSFKbQjzNEW1osdi6edMVC32_nKg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/elasticsearch/CAKdsXoFwxuEEZ0h_WPr5S4JSFKbQjzNEW1osdi6edMVC32_nKg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/CABeBvCeXV-Fg-%3DjHS434_oKi7i8Dr839dAsB0PA6EmobrMeqsg%40mail.gmail.com
> <https://groups.google.com/d/msgid/elasticsearch/CABeBvCeXV-Fg-%3DjHS434_oKi7i8Dr839dAsB0PA6EmobrMeqsg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAKdsXoEXnqUk9Kn3kd53yiWYG8vi2uas5NrkOLGHGeoOiNGE3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
