Re: [ANNOUNCE] SCOPE FREEZE for Apache Ignite 3.0.0 beta 1 RELEASE

[Stanislav Lukyanov]

I also added
https://issues.apache.org/jira/browse/IGNITE-17989
and
https://issues.apache.org/jira/browse/IGNITE-17357
to the scope.

Stan

> On 4 Nov 2022, at 18:26, Игорь Гусев  wrote:
> 
> 
> Hi Igniters,
>  
> I’d like to include some doc into beta1 if its not too late
> https://issues.apache.org/jira/browse/IGNITE-17948
> This change should not affect beta functionality.
>   
>> Пятница, 4 ноября 2022, 12:10 +02:00 от Юрий :
>>  
>> Hi Igniters,
>> 
>> I would like to add last one bugfix to the beta1:
>> https://issues.apache.org/jira/browse/IGNITE-18090
>> 
>> It will be ready in a few hours.
>> 
>> чт, 3 нояб. 2022 г. в 19:28, Alexander Lapin < lapin1...@gmail.com >:
>>  
>>> Hi Igniters,
>>> 
>>> I would like to ask you to add one more bugfix to the beta1:
>>> https://issues.apache.org/jira/browse/IGNITE-18003
>>> 
>>> Best regards,
>>> Aleksandr
>>> 
>>> вт, 1 нояб. 2022 г. в 17:17, Aleksandr Pakhomov < apk...@gmail.com >:
>>> 
 Hi Igniters,
 
 I would like to ask you to add two more tickets to the beta1:
 
 -  https://issues.apache.org/jira/browse/IGNITE-18036 <
 https://issues.apache.org/jira/browse/IGNITE-18036 >
 -  https://issues.apache.org/jira/browse/IGNITE-18025 <
 https://issues.apache.org/jira/browse/IGNITE-18025 >
 
 Both of them now have PR's into the main.
 
 Best regards,
 Aleksandr
 
> On 15 Oct 2022, at 00:45, Andrey Gura < ag...@apache.org > wrote:
> 
> Igniters,
> 
> The 'ignite-3.0.0-beta1' branch was created (the latest commit is
> 8160ef31ecf8d49f227562b6f0ab090c6b4438c1).
> 
> The scope for the release is frozen.
> 
> It means the following:
> 
> - Any issue could be added to the release (fixVersion == 3.0.0-beta1)
> only after discussion with the community and a release manager in this
> thread.
> - Any commit to the release branch must be also applied to the 'main'
 branch.
 
 
>>> 
>> 
>> --
>> Живи с улыбкой! :D 
>  
>  
> --
> Igor Gusev
>  

RE: [DISCUSSION] Enable Doclint for Ignite 3

[Aleksandr Pakhomov]

Here is my PR with enabling DocLint 
https://github.com/apache/ignite-3/pull/1320 
 

I wonder if someone can take a look.

-- 
Best regards,
Aleksandr

On 2022/11/07 11:45:48 Aleksandr Pakhomov wrote:
> Hi Igniters,
> 
> I'm working on the javadoc generation in gradle and I mentioned that now 
> standard Doclint [1] is disabled in the maven javadoc generation. I wonder to 
> know why it is disabled.
> 
> I would suggest enabling Doclint by default because it is a recommended and 
> standard approach to dealing with javadoc. Now blind enabling causes lint 
> errors but I think I can fix all of them in my PR. 
> 
> WDYT?
> 
> [1] https://openjdk.org/jeps/172 
> 
> --
> Best regards, 
> Aleksandr

[ANNOUNCE] Release pyignite-0.6.0

[Ivan Daschinsky]

Hi, Igniters!

I suppose it is time to release pyignite 0.6.0, since we have released our
previous release more than a year ago.

Firstly, python 3.6 reached its EOL, the brand new python, 3.11, was just
released. So it is a good idea to build new wheels targeting the new
versions.

Also, there are few new features, namely support of timeouts in asyncio
client for cache operations. This patch also fixes one tiny but annoying
bug in asyncio client [1]

Full list of tickets for release is here [2]

Actually, I have tested a new approach for testing and building artifacts
-- Github Actions, nowadays it is a preferred approach in the ASF.

I think that code freeze will be at 15:00 UTC 11/11. And on monday, 11/14 I
will publish a release candidate for voting.

WDYT?

[1] -- https://issues.apache.org/jira/browse/IGNITE-18006
[2] --
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.6.0

Re: Ignite OpenSSL Vulnerability

[Ivan Daschinsky]

So you should just download the latest openssl binaries, add them to PATH
and that's it. The ignite odbc driver will load them automatically.
You could also set OPENSSL_HOME env variable to the specific folder with
the valid openssl binaries.

Re: Ignite OpenSSL Vulnerability

[Ivan Daschinsky]

Hi, we don't link our odbc driver with openssl libraries. We load them
dynamically. So don't worry, our odbc driver is not affected at all.
Moreover, it supports multiple versions of openssl, up to 3.0.x

пн, 7 нояб. 2022 г. в 12:17, Ilya Kasnacheev :

> Hello!
>
> For the most part, we to not supply compiled versions of our C++ code, and
> our Java code does not use OpenSSL.
>
> So you should check if you can build ODBC driver against non-affected
> OpenSSL version.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 3 нояб. 2022 г. в 15:45, Entwicklung <
> entwickl...@giftinfo.uni-mainz.de
> >:
>
> > Hello,
> >
> > i hope i use the correct email address.
> >
> > (u...@ignite.apache.org returned wrong
> > email address.)
> >
> >
> >
> > I plan to install Apache Ignite version 2.14.0 binary release (latest) on
> > a windows server. I prefer ODBC-Connection to my application.
> >
> >
> >
> > Problem:
> >
> > ODBC uses OpenSSL, but Version 3.0.0 to 3.0.6 has critical vulnerability.
> > Version 3.0.7 has fixed the problems. Is 2.14.0 binary release
> (especially
> > ODBC) affected ? If yes, when is a new binary release available with
> > OpenSSL 3.0.7.
> >
> > I could not find any information about  the OpenSSL version that Ignite
> > binaries were built from, especially ODBC.
> >
> >
> >
> > Thank you for your help
> > Regards
> > Guido Clesius
> > __
> > Dipl.-Ing. Guido Clesius
> > Externer Mitarbeiter
> > Softwareentwicklung Guido Clesius
> > Im Sand 1
> > 55252 Mainz-Kastel
> > *   06134-9589649
> > Ë 0170-4430211
> > *   supp...@swe-clesius.de
> > þwww.swe-clesius.de
> >
> >
> >
> >
> >
> >
> >
> >
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: IgniteLogger improvement

[Łukasz Dywicki]

Hello Ilya,
I think that you might satisfy your requirements using MDC. It is 
refereed as Managed/Mapped Diagnostic Context [1], some logging 
libraries call it also Nested Diagnostic Context. Using it you can mark 
log entries with context specific information which is provided 
elsewhere. Standard mechanism of log4j keep MDC using thread locals.

Using MDC require some small adjustments in the code.

Looking at Log4j2Logger which is injectable into each ignite instance 
you can try managing MDC inside ignite logger itself. Instead of placing 
application and node id inside system property you push it using log4j2 
thread context. All you need to do is to surround each "impl" logger call:


try (final CloseableThreadContext.Instance ctc = 
CloseableThreadContext.put("app", application)

.put("node", String.valueOf(nodeId))) {
impl.info(getMarkerOrNull(marker), msg);
}

Both of these keys will be available under $X{app} and $X{node}.
Very similar mechanism is available with an old log4j 1.x.

[1] https://logging.apache.org/log4j/2.x/manual/thread-context.html

Kind regards,
Łukasz

On 6.11.2022 09:05, Ilya Korol wrote:

Hi Igniters,

I would like to discuss the Ignite logging.
I found current logging implementation a little bit inflexible for 
several use-cases.


Assume that I want to run multiple Ignite instances in same JVM process and
I also want that all messages from each Ignite instance go to separate 
file.
Actually we have an log4j config in our examples that, at first glance, 
should do the trick:



     
     
     
     pattern="[%d{ISO8601}][%-5p][%t][%c{1}]%notEmpty{[%markerSimpleName]} 
%m%n"/>

     
     modulate="true" />

     
     
     
     
     
     

This works good if we will feed this config to separate ignite instances 
(each in its own JVM), however in my case this will not work as expected.
In this log4j config we rely on java System properties ${sys.nodeId} and 
${sys.appId} that we set inside Log4jLogger:


@Override public void setApplicationAndNode(@Nullable String 
application, UUID nodeId) {


     ...

     // Set nodeId as system variable to be used at configuration.
     System.setProperty(NODE_ID, U.id8(nodeId));
     System.setProperty(APP_ID, application != null
     ? application
     : System.getProperty(APP_ID, "ignite"));

     ...
     }

But when second Ignite instance will be initialized this code will 
overwrite nodeId property with id of current node, so eventually I will 
get two files:


ignite-node1.log   // contains messages of first instance up to the 
moment when second instance overwrite nodeId sys property
ignite-node2.log   // contains messages from both nodes from mentioned 
moment



The problem is that there is no reliable *discriminator* for 
RoutingAppender. So I want to propose a some rework
of IgniteLogger implementations, to add some logic for logger 
customization where user would be able to configure such *discriminator 
/ tag*,

and later exploit in appender configuration.

1. What IgniteLogger implementation it affects
*Log4j2Logger* (we rely on RoutingAppender)
*Slf4jLogger* (we rely on Logback SiftingAppender)

Other logging frameworks/libraries (JUL / JCL) don't provide required 
features, so there is nothing we can do about.


2. What to use for discriminator
 From my perspective (after some googling, and studying log4j/slf4j 
docs) so called "Markers" would be perfect fit for such purpose.
Marker conception exist in both slf4j and log4j frameworks, and there is 
already exist possibility to supply markers in IgniteLogger.*() methods.
Additional benefit that I see from using markers is that, we would be 
able to avoid to add Ignite instance name post-fixes

in IgniteKernal loggers and thread names:

2022-11-05T23:24:17,365 INFO  [main] [o.a.i.i.IgniteKernal%server-0] 
Daemon mode: off
2022-11-05T23:24:17,368 INFO  [main] [o.a.i.i.IgniteKernal%server-0] OS: 
Linux 5.13.0-28-generic amd64
2022-11-05T23:24:17,372 INFO  [main] [o.a.i.i.IgniteKernal%server-0] OS 
user: ikorol
2022-11-05T23:24:17,375 INFO  [main] [o.a.i.i.IgniteKernal%server-0] 
PID: 2791603
2022-11-05T23:24:17,555 WARN  [pub-#21%server-0%] 
[o.a.i.i.GridDiagnostic] Initial heap size is 498MB (should be no less 
than 512MB, use -Xms512m -Xmx512m).
2022-11-05T23:24:19,993 INFO [disco-notifier-worker-#51%server-0%] 
[o.a.i.i.p.c.GridClusterStateProcessor] Received activate cluster 
request ...


Instead we can have (just need to add marker to appender message layout):

2022-11-05T23:24:17,365 INFO [server-0] [main] [o.a.i.i.IgniteKernal] 
Daemon mode: off
2022-11-05T23:24:17,368 INFO [server-0] [main] [o.a.i.i.IgniteKernal] 
OS: Linux 5.13.0-28-generic amd64
2022-11-05T23:24:17,372 INFO [server-0] [main] [o.a.i.i.IgniteKernal] OS 
user: ikorol
2022-11-05T23:24:17,375 INFO [server-0] [main] [

[DISCUSSION] Enable Doclint for Ignite 3

[Aleksandr Pakhomov]

Hi Igniters,

I'm working on the javadoc generation in gradle and I mentioned that now 
standard Doclint [1] is disabled in the maven javadoc generation. I wonder to 
know why it is disabled.

I would suggest enabling Doclint by default because it is a recommended and 
standard approach to dealing with javadoc. Now blind enabling causes lint 
errors but I think I can fix all of them in my PR. 

WDYT?

[1] https://openjdk.org/jeps/172 

--
Best regards, 
Aleksandr

Re: ignite-spark3.2-ext release

[Maxim Muzafarov]

Folks,

I can help with releasing this module (and actually it's pretty easy
to do a release using GA), but I have some notes according to
contribution:

1. We should merge spark3.2-ext and spark-ext and separate development
streams of different versions using branches with appropriate spark
versions in them (like we do it before). For instance,
ignite-spark-3.2 branch with 3.2 version etc. You can find an example
with the following branches [1][2].

2. We should update DEVNOTES with the release actions that should be
performed using GA (I can do it).


I would not be able to verify that everything works with spark 3.2
integration, but I can help with the release.

WDYT?


[1] 
https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-4.2.0
[2] 
https://github.com/apache/ignite-extensions/tree/release/ignite-hibernate-ext-5.1.0

On Mon, 7 Nov 2022 at 08:15, Ivan Gagarkin  wrote:
>
> Hi Alexandr,
> I would be glad if you can.
> Not sure about all information. Vladimir Pligin has more details.
> Right, no progress.
>
> On Fri, 4 Nov 2022 at 02:12, Alexandr Shapkin  wrote:
>
> > Hi Ivan,
> >
> > I’d like to help with that. Is all release-related information described
> > in the DEVNOTES?
> >
> > I suppose there has not been any progress on the release since your
> > initial message, correct?
> >
> > > On 26 Oct 2022, at 09:05, Ivan Gagarkin  wrote:
> > >
> > > Hi, Igniters
> > > ignite-spark3.2-ext is ready for release. We have to make some steps to
> > do
> > > that:
> > >
> > >   - Create a branch
> > >   - Run some jobs on github
> > >
> > > https://github.com/apache/ignite-extensions/blob/master/DEVNOTES.md
> > > Who can help me with that?
> > >
> > >
> > >
> > > --
> > > Best Regards, Ivan
> >
> >
>
> --
> С уважением, Гагаркин И.Ю.

Re: Ignite OpenSSL Vulnerability

[Ilya Kasnacheev]

Hello!

For the most part, we to not supply compiled versions of our C++ code, and
our Java code does not use OpenSSL.

So you should check if you can build ODBC driver against non-affected
OpenSSL version.

Regards,
-- 
Ilya Kasnacheev


чт, 3 нояб. 2022 г. в 15:45, Entwicklung :

> Hello,
>
> i hope i use the correct email address.
>
> (u...@ignite.apache.org returned wrong
> email address.)
>
>
>
> I plan to install Apache Ignite version 2.14.0 binary release (latest) on
> a windows server. I prefer ODBC-Connection to my application.
>
>
>
> Problem:
>
> ODBC uses OpenSSL, but Version 3.0.0 to 3.0.6 has critical vulnerability.
> Version 3.0.7 has fixed the problems. Is 2.14.0 binary release (especially
> ODBC) affected ? If yes, when is a new binary release available with
> OpenSSL 3.0.7.
>
> I could not find any information about  the OpenSSL version that Ignite
> binaries were built from, especially ODBC.
>
>
>
> Thank you for your help
> Regards
> Guido Clesius
> __
> Dipl.-Ing. Guido Clesius
> Externer Mitarbeiter
> Softwareentwicklung Guido Clesius
> Im Sand 1
> 55252 Mainz-Kastel
> *   06134-9589649
> Ë 0170-4430211
> *   supp...@swe-clesius.de
> þwww.swe-clesius.de
>
>
>
>
>
>
>
>
>