Re: Setting both offHeapMaxMemory and cacheStoreFactory

[Denis Magda]

Hi,

Please see my answers inline

On 1/13/2016 10:44 AM, Ambha wrote:

I have a few doubts on off heap cache configuration
1. Is it possible to set both off-heap and cache store with write behind
mode for a cache?
The configuration looks like:









 




   
  


Yes, it's possible to use off-heap space for a cache and sync data to a 
storage in either write-through or write-behind mode.


Actually, cache store is not bound to any cache memory mode (on-heap, 
off-heap, swap) where cache data can reside.

Please refer to [1] to get more details.


2. from which place (onheap or offheap or both) the cached objects are
written to cache store (MySQL above) if write behind is enabled?
If write-behind is enabled cache objects that must be synced to a 
storage are queued up in the write-behind store implementation and 
flushed up later.
There is no difference whether the objects are actually stored - in 
on-heap or off-heap.

You can find more details on write-behind store here [2].


3. What will happen to a new item to be placed in cache when the size (both
onheap and offheap) has already exceeded the limit?
You will face with out of memory situation unless you configured an 
eviction policy that moves data to swap. [3]


[1] https://apacheignite.readme.io/docs/off-heap-memory
[2] 
https://apacheignite.readme.io/docs/persistent-store#write-behind-caching

[3] https://apacheignite.readme.io/docs/evictions

Regards,
Denis



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Setting-both-offHeapMaxMemory-and-cacheStoreFactory-tp2527.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cache.put latencies high

[Dmitriy Setrakyan]

This is usually a problem with one-threaded benchmarks.

1. You should add a warm up step, i.e. have your system work for about a
minute before starting measuring.

2. You should decide whether your application will be single-threaded or
multi-threaded. If it is multi-threaded, then your test should also be
multi-threaded.

3. And finally you should verify that network works well in your
environment. Do you have 10G ethernet?

D.

On Tue, Jan 12, 2016 at 8:27 PM, babu prasad  wrote:

> Hi,
>
> I have configured 2 ignite servers with a heap size of 8G each.
> Running with backups=1 and primary_sync mode.
>
> Ignite servers are being used as a write behind cache for my Aurora
> database.
>
> I am trying to run a load test with 3 clients talking to the remote cache
> in the 2 ignite servers.
> All the hosts are in the same availability zone.
>
> My clients do a simple put and I calculate time taken for put on the
> client side.
>
> long startTime = System.currentTimeMillis();
> cache.put(k, c1);
> long elapsedTime = System.currentTimeMillis() - startTime;
> System.out.println("Total elapsed timein milliseconds: " + elapsedTime);
>
> Here is the latency from the last few requests:
> Total elapsed timein milliseconds: 31
> Total elapsed timein milliseconds: 29
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 29
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 29
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 29
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 28
> Total elapsed timein milliseconds: 26
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 27
> Total elapsed timein milliseconds: 29
>
> Not sure what is going on here. I am pretty sure I am doing something
> wrong here.
>
>
> Thanks!
>
>

Re: putting to cache as generic object

[Anton Vinogradov]

Hello Ambha,

Seem you need to use BinaryMarshaller (
https://apacheignite.readme.io/docs/binary-marshaller)
In this case you can create objects using binary builder and read field's
values using BinaryObject (Reflection like mechanism)

On Wed, Jan 13, 2016 at 7:58 AM, Ambha  wrote:

> In our project, we plan to deploy ignite caching as a shared service
> available for other modules. The caching module is visible to all the
> modules but any module's classes are not visible to caching.
>
> The objects of different components are put into cache, but it requires
> classes of different modules to be on Ignite's classpath.I plan to use
> Reflection like mechanism at ignite server to fetch the property of the
> cached object. But before this Ignite OptmizedMarshaller expects class to
> be
> present in classpath while serializing.  For some security reason I can't
> put other modules classes into Ignite classpath and also can't use
> peerClassLoading. I want a solution which can make ignite to treat objects
> to be cached as generic 'java.lang.Object's and don't expect cached
> object's
> class to be present in Ignite's classpath
>
>
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/putting-to-cache-as-generic-object-tp2525.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Ignite "bugs" ?

[Yann BLAZART]

Hello everybody.

I'm currently evaluation Ignite vs Hazelcast on a poc.

I'm facing some issues.
I'm coding some integration/unit test using the ApplicationComposer of TomEE 
7.0.0. I have no problem with Hazelcast on it.


* The first one is when I'm start Ignite in the applicationComposer 
(with a CDI @Produces), Ignite complain about some System.properties that are 
not String :


it try to "serialize" System.properties by using 
System.getProperties().store(new PrintWriter(sw));



In fact, TomEE (as other framework like hibernate) use System.properties to 
store prop objects.



So I made something to remove this properties before Ignite start and recover 
its after. Well. Pehraps it will be nice to change the way to "serialize" 
System.properties.



* The second problem is strange, very strange. If I'm making a call to 
Ignite.start in @Before or using a @Inject in the test class (that use the 
@Produce that make the call to start(), everything is ok. But if the start is 
called in the @Test method (so after ApplicationComposer has made some things), 
Ignite is "locked".

o   Precisely in IgniteKernel.java:917  :



// Start discovery manager last to make sure that grid is fully initialized.
startManager(discoMgr);



The call to  this method never exit.



Any idea to help me to understand ? Anybody has tried to use Ignite with EE or 
CDI ?



Regards







This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential. 
If you receive this message in error,or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose, 
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet 
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS 
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified. 
Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message") 
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de 
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas 
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie. 
N'imprimez ce message que si necessaire, pensez a l'environnement.

Re: TcpDiscoveryVmIpFinder's isShared property

[Vladimir Ozerov]

+1 to the question. Very confusing property. At the very least JavaDocs
should be reworked significantly.

On Wed, Jan 13, 2016 at 8:32 PM, Andrey Kornev 
wrote:

> Hi there,
>
> I'm a bit confused about the purpose and usage of this property. What is
> being shared with who? What are the consequences of setting the property to
> true or false? Under what circumstances would one want to set it to either
> true or false? Does one care at all?
>
> Thanks
> Andrey
>

isManagementEnabled vs isStatisticsEnabled.

[vinshar]

Hi,

I see that Ignite registers same bean in case if any of the above flags are
true. Bean is of type
/"org.apache.ignite.internal.processors.cache.CacheMetricsMXBeanImpl"/. This
/CacheMetricsMXBeanImplclass /implements /CacheMetricsMXBean / which extends
below both interfaces defined in JSR107.
/"import javax.cache.management.CacheMXBean"
"import javax.cache.management.CacheStatisticsMXBean"/

So it seems like setting any of isManagementEnabled and isStatisticsEnabled
flags will do the same thing.
Is there anything where setting one flag is different from setting the other
one? 

Regards,
Vinay



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/isManagementEnabled-vs-isStatisticsEnabled-tp2549.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Ignite "bugs" ?

[vkulichenko]

Yann,

It sounds like you have some misconfiguration for discovery. Can you also
provide your configuration file?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-bugs-tp2534p2550.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Ignite "bugs" ?

[Yann BLAZART]

I will do ASAP. I have some support case for now.

Thanks for your help :)

Regarding the System.properties, I've made my own patch in my code by filtering 
System.properties hashtable before calling ignite start, then I restore 
values... Ugly, but working.

From: Denis Magda [mailto:dma...@gridgain.com]
Sent: mercredi 13 janvier 2016 16:26
To: user@ignite.apache.org
Subject: Re: Ignite "bugs" ?

Hi Yann,

Could you provide thread dumps from all the nodes? It should help to see the 
place that "locket" the execution.

Regards,
Denis
On 1/13/2016 4:23 PM, Yann BLAZART wrote:
Hello everybody.

I'm currently evaluation Ignite vs Hazelcast on a poc.

I'm facing some issues.
I'm coding some integration/unit test using the ApplicationComposer of TomEE 
7.0.0. I have no problem with Hazelcast on it.


* The first one is when I'm start Ignite in the applicationComposer 
(with a CDI @Produces), Ignite complain about some System.properties that are 
not String :


it try to "serialize" System.properties by using 
System.getProperties().store(new PrintWriter(sw));



In fact, TomEE (as other framework like hibernate) use System.properties to 
store prop objects.



So I made something to remove this properties before Ignite start and recover 
its after. Well. Pehraps it will be nice to change the way to "serialize" 
System.properties.



* The second problem is strange, very strange. If I'm making a call to 
Ignite.start in @Before or using a @Inject in the test class (that use the 
@Produce that make the call to start(), everything is ok. But if the start is 
called in the @Test method (so after ApplicationComposer has made some things), 
Ignite is "locked".

o   Precisely in IgniteKernel.java:917  :



// Start discovery manager last to make sure that grid is fully initialized.
startManager(discoMgr);



The call to  this method never exit.



Any idea to help me to understand ? Anybody has tried to use Ignite with EE or 
CDI ?



Regards






This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified.
Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Re: Ignite "bugs" ?

[Alexey Kuznetsov]

Yann,

Take into account that this mail list does not allow binary attachments,
 you should upload them on some public service (like dropbox or any) and
provide a link.


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

RE: Ignite "bugs" ?

[Yann BLAZART]

I will

From: Alexey Kuznetsov [mailto:akuznet...@gridgain.com]
Sent: mercredi 13 janvier 2016 16:42
To: user@ignite.apache.org
Subject: Re: Ignite "bugs" ?

Yann,

Take into account that this mail list does not allow binary attachments,
 you should upload them on some public service (like dropbox or any) and 
provide a link.


--
Alexey Kuznetsov
GridGain Systems
www.gridgain.com


This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential. 
If you receive this message in error,or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose, 
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet 
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS 
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified. 
Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message") 
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de 
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas 
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie. 
N'imprimez ce message que si necessaire, pensez a l'environnement.

RE: Ignite "bugs" ?

[Yann BLAZART]

Well, TomEE is using System.properties to store its IVmContext… I can’t make 
change all open source projects on this point, even if I’m agree with you.

I have only one Ignite instance started in this case. This is really strange.

From: Matt Hoffman [mailto:m...@mhoffman.org]
Sent: mercredi 13 janvier 2016 15:31
To: user@ignite.apache.org
Subject: Re: Ignite "bugs" ?

Using System.properties() to store non-strings is really poor behavior. It 
violates the contract of the System.setProperty and System.getProperty, as well 
as the contract of the Properties object itself, from right at the top of the 
javadoc:  "Each key and its corresponding value in the property list is a 
string."
I've hit something like that in Hibernate before, years ago; I'm surprised they 
haven't fixed it yet. It's a long-standing bug in Hibernate. Not to say Ignite 
shouldn't have a workaround for badly-behaved libraries that do things like 
that, but it's definitely a Hibernate bug.

Someone else will have to talk the locking behavior you're seeing. Are you 
starting Ignite more than once in parallel in that case?

On Wed, Jan 13, 2016 at 8:23 AM, Yann BLAZART 
>
 wrote:
Hello everybody.

I’m currently evaluation Ignite vs Hazelcast on a poc.

I’m facing some issues.
I’m coding some integration/unit test using the ApplicationComposer of TomEE 
7.0.0. I have no problem with Hazelcast on it.


• The first one is when I’m start Ignite in the applicationComposer 
(with a CDI @Produces), Ignite complain about some System.properties that are 
not String :


it try to "serialize" System.properties by using 
System.getProperties().store(new PrintWriter(sw));



In fact, TomEE (as other framework like hibernate) use System.properties to 
store prop objects.



So I made something to remove this properties before Ignite start and recover 
its after. Well. Pehraps it will be nice to change the way to “serialize” 
System.properties.



• The second problem is strange, very strange. If I’m making a call to 
Ignite.start in @Before or using a @Inject in the test class (that use the 
@Produce that make the call to start(), everything is ok. But if the start is 
called in the @Test method (so after ApplicationComposer has made some things), 
Ignite is “locked”.

o   Precisely in IgniteKernel.java:917  :



// Start discovery manager last to make sure that grid is fully initialized.
startManager(discoMgr);



The call to  this method never exit.



Any idea to help me to understand ? Anybody has tried to use Ignite with EE or 
CDI ?



Regards






This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified.
Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Re: Ignite "bugs" ?

[Matt Hoffman]

No, I understand that you can't control what other projects do, and it's
not always possible to fix bugs at their source.

I imagine the best thing for Ignite to do in this case is to iterate
through the properties and just ignore anything that isn't a String. It
wouldn't be meaningful when deserialized anyway.

On Wed, Jan 13, 2016 at 10:26 AM, Yann BLAZART <
yann.blaz...@externe.bnpparibas.com> wrote:

> Well, TomEE is using System.properties to store its IVmContext… I can’t
> make change all open source projects on this point, even if I’m agree with
> you.
>
>
>
> I have only one Ignite instance started in this case. This is really
> strange.
>
>
>
> *From:* Matt Hoffman [mailto:m...@mhoffman.org]
> *Sent:* mercredi 13 janvier 2016 15:31
> *To:* user@ignite.apache.org
> *Subject:* Re: Ignite "bugs" ?
>
>
>
> Using System.properties() to store non-strings is really poor behavior. It
> violates the contract of the System.setProperty and System.getProperty, as
> well as the contract of the Properties object itself, from right at the top
> of the javadoc:  "Each key and its corresponding value in the property
> list is a string."
>
> I've hit something like that in Hibernate before, years ago; I'm surprised
> they haven't fixed it yet. It's a long-standing bug in Hibernate. Not to
> say Ignite shouldn't have a workaround for badly-behaved libraries that do
> things like that, but it's definitely a Hibernate bug.
>
>
>
> Someone else will have to talk the locking behavior you're seeing. Are you
> starting Ignite more than once in parallel in that case?
>
>
>
> On Wed, Jan 13, 2016 at 8:23 AM, Yann BLAZART <
> yann.blaz...@externe.bnpparibas.com> wrote:
>
> Hello everybody.
>
>
>
> I’m currently evaluation Ignite vs Hazelcast on a poc.
>
>
>
> I’m facing some issues.
>
> I’m coding some integration/unit test using the ApplicationComposer of
> TomEE 7.0.0. I have no problem with Hazelcast on it.
>
>
>
> · The first one is when I’m start Ignite in the
> applicationComposer (with a CDI @Produces), Ignite complain about some
> System.properties that are not String :
>
>
>
> it try to "serialize" System.properties by using
> System.getProperties().store(new PrintWriter(sw));
>
>
>
> In fact, TomEE (as other framework like hibernate) use System.properties
> to store prop objects.
>
>
>
> So I made something to remove this properties before Ignite start and
> recover its after. Well. Pehraps it will be nice to change the way to
> “serialize” System.properties.
>
>
>
> · The second problem is strange, very strange. If I’m making a
> call to Ignite.start in @Before or using a @Inject in the test class (that
> use the @Produce that make the call to start(), everything is ok. But if
> the start is called in the @Test method (so after ApplicationComposer has
> made some things), Ignite is “locked”.
>
> o   Precisely in IgniteKernel.java:917  :
>
>
>
>
> *// Start discovery manager last to make sure that grid is fully
> initialized. *startManager(discoMgr);
>
>
>
> The call to  this method never exit.
>
>
>
> Any idea to help me to understand ? Anybody has tried to use Ignite with
> EE or CDI ?
>
>
>
> Regards
>
>
>
>
>
>
>
> This message and any attachments (the "message") is
> intended solely for the intended addressees and is confidential.
> If you receive this message in error,or are not the intended recipient(s),
> please delete it and any copies from your systems and immediately notify
> the sender. Any unauthorized view, use that does not comply with its
> purpose,
> dissemination or disclosure, either whole or partial, is prohibited. Since
> the internet
> cannot guarantee the integrity of this message which may not be reliable,
> BNP PARIBAS
> (and its subsidiaries) shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary,consider the environment.
>
>
> --
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont etablis a l'intention exclusive de ses destinataires et sont
> confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
> merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
> immediatement l'expediteur. Toute lecture non autorisee, toute utilisation
> de
> ce message qui n'est pas conforme a sa destination, toute diffusion ou
> toute
> publication, totale ou partielle, est interdite. L'Internet ne permettant
> pas d'assurer
> l'integrite de ce message electronique susceptible d'alteration, BNP
> Paribas
> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
> dans l'hypothese
> ou il aurait ete modifie, deforme ou falsifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>
>
>

Re: Ignite "bugs" ?

[Denis Magda]

Hi Yann,

Could you provide thread dumps from all the nodes? It should help to see 
the place that "locket" the execution.


Regards,
Denis

On 1/13/2016 4:23 PM, Yann BLAZART wrote:


Hello everybody.

I’m currently evaluation Ignite vs Hazelcast on a poc.

I’m facing some issues.

I’m coding some integration/unit test using the ApplicationComposer of 
TomEE 7.0.0. I have no problem with Hazelcast on it.


·The first one is when I’m start Ignite in the applicationComposer 
(with a CDI @Produces), Ignite complain about some System.properties 
that are not String :


it try to "serialize" System.properties by using 
System.getProperties().store(new PrintWriter(sw));


In fact, TomEE (as other framework like hibernate) use 
System.properties to store prop objects.


So I made something to remove this properties before Ignite start and 
recover its after. Well. Pehraps it will be nice to change the way to 
“serialize” System.properties.


·The second problem is strange, very strange. If I’m making a call to 
Ignite.start in @Before or using a @Inject in the test class (that use 
the @Produce that make the call to start(), everything is ok. But if 
the start is called in the @Test method (so after ApplicationComposer 
has made some things), Ignite is “locked”.


oPrecisely in IgniteKernel.java:917  :

//

/// Start discovery manager last to make sure that grid is fully 
initialized.

/startManager(discoMgr);

The call to  this method never exit.

Any idea to help me to understand ? Anybody has tried to use Ignite 
with EE or CDI ?


Regards

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended 
recipient(s),

please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its 
purpose,
dissemination or disclosure, either whole or partial, is prohibited. 
Since the internet
cannot guarantee the integrity of this message which may not be 
reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if 
modified, changed or falsified.

Do not print this message unless it is necessary,consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont 
confidentiels.

Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en 
avertir
immediatement l'expediteur. Toute lecture non autorisee, toute 
utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou 
toute
publication, totale ou partielle, est interdite. L'Internet ne 
permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP 
Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce 
message dans l'hypothese

ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.