compute best practices / examples

[vm <go...@gmail.com>]

I'm running some tests and wondering what should be provided by closure
state, and what should _not_ be. For example, if I'm going to "broadcast" to
the cluster - should my closure create Ignite-related objects like the
caches/queues or should each of the node runnables create those explicitly?
What are the implications of either cases?

Thanks



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

Re: compute best practices / examples

[vkulichenko <va...@gmail.com>]

Hi L,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscribe@ignite.apache.org and follow simple instructions in
the reply.


landon9720 wrote
> I have noticed @IgniteInstanceResource not working when used in the
> configuration file read when running ignite.sh. Looking the implementation
> it doesn't support this. This raises the question:
> 
> How can Spring-managed beans get a reference to Ignite? It seems that in
> this part of the program the Ignite has not be instantiated yet.

Ignite instance is injected to objects that are executed in scope of Ignite
(closures, entry processors, services, etc.). The main use case for such
injection is remote execution. I.e., a closure is sent to a remote node and
the instance which is actually executing the closure is injected there
before the execution.

As for Spring beans, you're correct. Ignite will start after the Spring
context is initialized, so there is nothing to inject (and actually Ignite
is not aware of these annotation, so I don't think it's even possible).
What's the exact use case you're trying to address? Can you show an example
of something that doesn't work?

-Val



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

Re: compute best practices / examples

[vkulichenko <va...@gmail.com>]

Hi Pires,

Can you please provide more details (ideally a test that reproduces the
issue)?

-Val



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

Re: compute best practices / examples

[Paulo Pires <pi...@littlebits.cc>]

While I use this approach, I have seen the injected object become null. I
didn't use transient. Would that be the cause of it?

Pires

On Tue, Aug 2, 2016 at 4:02 AM, vkulichenko <va...@gmail.com>
wrote:

> Hi,
>
> I would not recommend to serialize instances of Ignite, IgniteCache,
> IgniteQueue, etc. This is supported, but  provides unnecessary overhead.
> You
> can always inject Ignite into your job using annotation:
>
> @IgniteInstanceResource
> private transient Ignite ignite;
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/compute-best-practices-examples-tp6663p6664.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 

*Paulo Pires*

senior infrastructure engineer | littleBits
<http://www.google.com/url?q=http%3A%2F%2Flittlebits.cc%2F&sa=D&sntz=1&usg=AFrqEzdmD1TfneYzn_vRGBO0a4wHpG-Ivg>

*T* (917) 464-4577
unleash your inner inventor. <https://youtu.be/fMg5QPQQOOI>

Re: compute best practices / examples

[vkulichenko <va...@gmail.com>]

Hi,

I would not recommend to serialize instances of Ignite, IgniteCache,
IgniteQueue, etc. This is supported, but  provides unnecessary overhead. You
can always inject Ignite into your job using annotation:

@IgniteInstanceResource
private transient Ignite ignite;

-Val



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