Let me ask a different question then:
Do you agree when I say that if you include ES in your Java EE application
(JAR file) and you create a single tone to manage the ES connection to the
cluster. That in this case, the ES engine runs inside of your Java EE
application container?
Tasha
On 9 September 2014 10:15, joergpra...@gmail.com <joergpra...@gmail.com>
wrote:
> 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/CABeBvCfqwPz%3DnkWi4Tgx8i3RZWafreJy%2BtXr1SBWZPzsMWLsvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
