ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Павлухин Иван <vololo...@gmail.com>
Subject Re: JVM warnings during Java 11 startup
Date Sun, 03 Mar 2019 06:01:00 GMT
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 situation.

сб, 2 мар. 2019 г. в 20:39, Dmitriy Pavlov <dpavlov@apache.org>:
>
> 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 any other
> grid-based) soft is often developed in IDEA in the same process with server
> nodes. Ignite.sh (or another grid node launcher) is used in prod, but not
> for dev.
>
> сб, 2 мар. 2019 г. в 10:01, Павлухин Иван <vololo100@gmail.com>:
>
> > 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 packages from some module visible to
> > other specified modules.
> > --add-opens allows reflective access to non-public members in other
> > module packages (they call it "deep reflection").
> >
> > Of course we should check everything carefully during implementation.
> >
> > пт, 1 мар. 2019 г. в 22:26, Dmitriy Pavlov <dpavlov@apache.org>:
> > >
> > > 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, Павлухин Иван <vololo100@gmail.com>:
> > >
> > > > 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 <dpavlov@apache.org>:
> > > > >
> > > > > Would add opens require user to set up a longer line?
> > > > >
> > > > > пт, 1 мар. 2019 г., 9:01 Павлухин Иван <vololo100@gmail.com>:
> > > > >
> > > > > > 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, Павлухин Иван
<vololo100@gmail.com>:
> > > > > > >
> > > > > > > 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 we can found the majority
of
> > packages
> > > > > > > by analyzing TC logs.
> > > > > > >
> > > > > > > WDYT?
> > > > > > >
> > > > > > > [1]
> > > > > >
> > > >
> > https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/1988aa92075eb2a60328e28b3a5933a7c7cbc347/hz-java9.png
> > > > > > >
> > > > > > > пт, 1 мар. 2019 г. в 03:04, Denis Magda <dmagda@apache.org>:
> > > > > > > >
> > > > > > > > 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 <
> > dpavlov@apache.org
> > > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > > 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
<
> > mr.weider@gmail.com>:
> > > > > > > > >
> > > > > > > > > > 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
<dmagda@apache.org
> > >
> > > > 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
> > > > > > with it
> > > > > > > > > > > forever, the time to phase it out has
come :)
> > > > > > > > > > >
> > > > > > > > > > > -
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Feb 27, 2019 at 9:53 AM Dmitriy
Pavlov <
> > > > > > dpavlov@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> Sure, we could try this option.
> > > > > > > > > > >>
> > > > > > > > > > >> ср, 27 февр. 2019 г. в
19:16, Ilya Kasnacheev <
> > > > > > > > > > ilya.kasnacheev@gmail.com>:
> > > > > > > > > > >>
> > > > > > > > > > >>> 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 <
> > > > > > dpavlov@apache.org>:
> > > > > > > > > > >>>
> > > > > > > > > > >>>> 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
> > > > > > > > > > >>> default
> > > > > > > > > > >>>> for JVM. From the doc:
> > > > > > > > > > >>>> permit: ... The first reflective-access
operation to
> > any
> > > > such
> > > > > > > > > package
> > > > > > > > > > >>>> causes a warning to be
issued. However, no warnings
> > are
> > > > > > issued after
> > > > > > > > > > >> the
> > > > > > > > > > >>>> first occurrence. This
single warning describes how to
> > > > enable
> > > > > > > > > further
> > > > > > > > > > >>>> warnings.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Warning example:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> WARNING: An illegal reflective
access operation has
> > > > occurred
> > > > > > > > > > >>>> WARNING: Illegal reflective
access by
> > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2
> > > > > > > > > > >>>> (file:..libs/ignite-core-2.7.0.jar)
to field
> > > > > > java.nio.Buffer.address
> > > > > > > > > > >>>> WARNING: Please consider
reporting this to the
> > > > maintainers of
> > > > > > > > > > >>>> org.apache.ignite.internal.util.GridUnsafe$2
> > > > > > > > > > >>>> WARNING: Use --illegal-access=warn
to enable warnings
> > of
> > > > > > further
> > > > > > > > > > >>>> illegal reflective access
operations
> > > > > > > > > > >>>> WARNING: All illegal access
operations will be denied
> > in a
> > > > > > future
> > > > > > > > > > >> release
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Unfortunately removing
or disabling this warning is
> > > > absolutely
> > > > > > > > > > >>> impossible,
> > > > > > > > > > >>>> it is generated by JVM
and there is no option to
> > disable
> > > > it:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > >
> > https://docs.oracle.com/en/java/javase/11/tools/java.html#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Sincerely,
> > > > > > > > > > >>>> Dmitriy Pavlov
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >



-- 
Best regards,
Ivan Pavlukhin

Mime
View raw message