It uses Instrumentation API. I am not aware how to access it outside of agent.
пн, 4 мар. 2019 г. в 01:17, Dmitriy Pavlov :
>
> Looks promising. Is it possible to run this code from main? Or it has to be
> an agent.
>
> вс, 3 мар. 2019 г., 20:26 Павлухин Иван :
>
> > I did an exercise setting up a
Looks promising. Is it possible to run this code from main? Or it has to be
an agent.
вс, 3 мар. 2019 г., 20:26 Павлухин Иван :
> I did an exercise setting up a project which uses maven dependency to
> ignite-core module. And it seems that it is not practical to simply
> add dependency section to
I did an exercise setting up a project which uses maven dependency to
ignite-core module. And it seems that it is not practical to simply
add dependency section to pom, instruction is needed to avoid
surprises.
Also I succeed in creating a java agent which effectively allows to
access all packages
Dmitriy,
Thank you for details. Yes it looks really troublesome to start Ignite
development with Java 9+. I am not happy to say that but even more
hacky workarounds could help us. In short term.
I will try to do an exercise of setting up development environment
from scratch to feel the real situa
In a standalone mode user have to specify options. He or she may use
application templates to simplify launch just like
https://github.com/apache/ignite/tree/master/examples#running-examples-on-jdk-91011
but
it is anyway required.
As a user in the past (and currently) I may say: Ignite-based (or a
Dmitriy,
I am a little bit confused by statement that "user should specify
options". I thought that we can setup all needed variables in our
startup scripts. Or are you talking about library case?
And answering the question. Yes, more options will be needed.
--add-exports makes not exported packa
Would it require a user to specify more options or use longer parameter
values if we change from -add-exports to -add-opens?
Stanislav, could you prepare PR to demonstrate the idea. PR will probably
answer to all questions.
пт, 1 мар. 2019 г. в 15:09, Павлухин Иван :
> Dmitriy,
>
> > Would add o
Dmitriy,
> Would add opens require user to set up a longer line?
I am not sure that got that question right. Could you please elaborate?
пт, 1 мар. 2019 г. в 09:39, Dmitriy Pavlov :
>
> Would add opens require user to set up a longer line?
>
> пт, 1 мар. 2019 г., 9:01 Павлухин Иван :
>
> > By th
Would add opens require user to set up a longer line?
пт, 1 мар. 2019 г., 9:01 Павлухин Иван :
> By the way. It is interesting that Unsafe class is not the source of
> warnings. I checked (with java 10) that there is no warnings issued
> when Unsafe instance is accessed with good old reflective w
By the way. It is interesting that Unsafe class is not the source of
warnings. I checked (with java 10) that there is no warnings issued
when Unsafe instance is accessed with good old reflective way.
пт, 1 мар. 2019 г. в 08:05, Павлухин Иван :
>
> Here is how our friends from Hazelcast tackle the
Here is how our friends from Hazelcast tackle the problem [1]. Using
--add-opens as Stan proposed looks like a good option in short
perspective. By the way to determine all illegally accessed packages
we can use --illegal-access=warn, which does not deny operation but
only prints a warning. I guess
Flags/hacks is not a way to go for serious and mature projects like Ignite.
We should switch to another mode - how to replace Unsafe completely.
-
Denis
On Thu, Feb 28, 2019 at 4:32 AM Dmitriy Pavlov wrote:
> > may become unavailable in any time.
>
> I remember this was discussed in 2013 that
Ivan, thanks, great consideration.
And probably for this warning, Java will probably resist to redirecting it
at Java level.
Anyway, we could try it because we know where the first Unsafe call is
performed in Ignite.
чт, 28 февр. 2019 г. в 09:36, Павлухин Иван :
> Also it worth to consider a ca
> may become unavailable in any time.
I remember this was discussed in 2013 that Unsafe will be removed soon. But
nothing is changed yet, so I hope unsafe will be available for a long time
(with flags/hacks/etc).
чт, 28 февр. 2019 г. в 09:11, Petr Ivanov :
> According to warning message, there
From: Павлухин Иван
Sent: 28 февраля 2019 г. 9:36
To: dev@ignite.apache.org
Subject: Re: JVM warnings during Java 11 startup
Also it worth to consider a case when Ignite is used as a library. In
that case it is not correct to disable these warnings because there
could be warnings for other
Also it worth to consider a case when Ignite is used as a library. In
that case it is not correct to disable these warnings because there
could be warnings for other libraries too.
On the other hand we might employ some tricks in CommandLineStartup
when running alone.
чт, 28 февр. 2019 г. в 09:11
According to warning message, there are no options at all, as Unsafe may become
unavailable in any time.
> On 27 Feb 2019, at 22:53, Denis Magda wrote:
>
> It's fine as long as the project can be launched. I would better start
> looking for Unsafe alternatives as the next step. We can't live w
It's fine as long as the project can be launched. I would better start
looking for Unsafe alternatives as the next step. We can't live with it
forever, the time to phase it out has come :)
-
Denis
On Wed, Feb 27, 2019 at 9:53 AM Dmitriy Pavlov wrote:
> Sure, we could try this option.
>
> ср, 2
Sure, we could try this option.
ср, 27 февр. 2019 г. в 19:16, Ilya Kasnacheev :
> Hello!
>
> I wonder if we could try to redirect output to null, initialize GridUnsafe
> and then bring output back :)
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov :
>
> > Hi
Hello!
I wonder if we could try to redirect output to null, initialize GridUnsafe
and then bring output back :)
Regards,
--
Ilya Kasnacheev
ср, 27 февр. 2019 г. в 18:30, Dmitriy Pavlov :
> Hi Ignite Developers,
>
> During the start of Ignite node under Java 11 (actually 9+) or during local
>
Hi Ignite Developers,
During the start of Ignite node under Java 11 (actually 9+) or during local
development you may face with warning related to illegal access.
You know that Ignite uses Unsafe operation for durable memory.
Accessing to Unsafe requires --illegal-access=permit (Now it is the de
21 matches
Mail list logo
