Client nodes are unable to discover server nodes using kubernetes IpFinder

[Manu]

Hi!

We are trying to deploy an ignite cluster(s) into kubernetes and found some
issues.

Sample deployed topology into kubernetes (we need each ignite server cluster
has different discovery port)

Ignite Server(s) cluster to store main data (discoPort 49500)
\
  Client App with 2 ignite clients (discoPort 49500, discoPort 48500) to
talk with both clusters
/
Ignite Server(s) cluster to store cached data (discoPort 48500)

Apparently, client nodes are unable to discover server nodes using
kubernetes IpFinder whether non default discovery port, for example 49500,
is used on server side ignite configuration.

TcpDiscoverySpi local port configuration is ignored on client mode, so port
47500 is always used to connect to ignite servers (we don't want to use
forceServerMode=true as it is a deprecated feature and may have negative
performance impact)

In general seems that any IpFinder implementation that has this behaviour
(not provides server port when registered addresses were returned) will have
same issue.

Fix suggestion, modify org.apache.ignite.spi.discovery.tcp.ClientImpl
spiStart, apparently this change has no collateral effects:

Original 
   @Override public void spiStart(@Nullable String igniteInstanceName)
throws IgniteSpiException {
spi.initLocalNode(
0,
true);

Fix
   @Override public void spiStart(@Nullable String igniteInstanceName)
throws IgniteSpiException {
// FIX ignored TcpDiscoverySpi local port configuration on client
mode, takes configured one
spi.initLocalNode(
spi.locPort,
true);
 

How to reproduce issue:

1. Deploy a server node with tcp discovery kubernetes IpFinder and non
default discovery port 49500 into kubernetes

2. Deploy client nodes with tcp discovery kubernetes IpFinder and non
default discovery port 49500 into kubernetes

3. You will see on client nodes logs that will try to connect to servers on
port 47500, instead of configured 49500.

Ignite configuration for both server and client node(s)
[...]

  



  
  



https://kubernetes.default.svc.cluster.local:443"/>

  

  

[...]

Regards!

Manu.






--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: New blog post on Apache Ignite in AWS

[sri hari kali charan Tummala]

cant open second screenshot I mean cant expand , a simple example to read
and write with spark would be nice using thrift jdbc etc ...

connecting Ignite from outside ec2 with spark.

https://github.com/kali786516/ApacheIgnitePoc/blob/ef95cdd65ef2a91aeef59dd2b4ebafec4da19a17/src/main/scala/com/ignite/examples/spark/SparkClientConnectionTest.scala#L75




On Fri, Jan 24, 2020 at 5:20 PM Denis Magda  wrote:

> Sergey,
>
> Thanks for a compact and clear article. I especially enjoyed the part that
> explains how to connect from a local laptop to an already running Ignite
> cluster on AWS. Looking forward to more content from you!
>
> -
> Denis
>
>
> On Wed, Jan 22, 2020 at 11:35 PM Sergey Chugunov <
> sergey.chugu...@gmail.com> wrote:
>
>> Hello community,
>>
>> Recently I published a new blog post on getting started with Apache
>> Ignite in AWS [1]. I tried to make my example as simple as possible while
>> keeping it usable.
>>
>> Let me know if this post is useful for you.
>>
>> I plan to write several follow-up posts about AWS-specific things but
>> based on feedback may cover other topics in more detail.
>>
>> Any feedback is welcome, thank you!
>>
>> [1] https://www.gridgain.com/node/6247
>>
>

-- 
Thanks & Regards
Sri Tummala

Re: New blog post on Apache Ignite in AWS

[Denis Magda]

Sergey,

Thanks for a compact and clear article. I especially enjoyed the part that
explains how to connect from a local laptop to an already running Ignite
cluster on AWS. Looking forward to more content from you!

-
Denis


On Wed, Jan 22, 2020 at 11:35 PM Sergey Chugunov 
wrote:

> Hello community,
>
> Recently I published a new blog post on getting started with Apache Ignite
> in AWS [1]. I tried to make my example as simple as possible while keeping
> it usable.
>
> Let me know if this post is useful for you.
>
> I plan to write several follow-up posts about AWS-specific things but
> based on feedback may cover other topics in more detail.
>
> Any feedback is welcome, thank you!
>
> [1] https://www.gridgain.com/node/6247
>

Re: Please a reviewer for the case IGNITE-12518

[Denis Magda]

Hi Luis,

Presently, the community is on the route of Ignite simplification. We're
trying to define Ignite core that has minimal dependencies with 3rd party
libraries. That also led to the modularization initiative [1] with the
first results in the form of Ignite Extensions repository where we're
moving all 3rd party integrations.

Saikat, do you think Luis's contribution needs to reside in the extensions
repository?

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization

-
Denis


On Thu, Jan 23, 2020 at 8:48 PM Luis Arce  wrote:

> Hi Saikat,
> Thanks for you response:
>
> My system need a web server for work. i work correctly with Wildfly and i
> use Ignite as Backend for database.
> My problem is the combination of both is around 6 GB RAM for work in the
> VPS.
> For this reason i modified the unique plugin with webserver inside
> (rest-http module).
> The change enabled the possibility for use only 3GB RAM in a VPS (
> vpsserver.com) saving money and enabling horizontal scalling.
> I shared this change in the Jira ticket touching the two classes of
> rest-http plugin.
> The change has less impact (programaticly), the point is the library
> dependencies (quantity of jars).
>
> It change has sense for you?, i think is a util because that technologies
> dont has present inside of ignite currently and is friendly with the code
> of rest-ignite.
>
>
>
>
> Best regards,
>
>
> *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión
> 09-57861903
> Linkedin:
> https://cl.linkedin.com/in/luisalejandroarcemartinez
>
>
>
>
>
> El mié., 22 ene. 2020 a las 0:38, Saikat Maitra ( >)
> escribió:
>
> > Hello Luis,
> >
> > Thank you for your email. You can plan to create a separate application
> for
> > jaxws service and use any build tools like gradle or maven to define your
> > dependencies.
> >
> > Please find below some of the performance tips related to Ignite
> >
> > https://apacheignite.readme.io/docs/durable-memory-tuning
> >
> > You can use IgniteClient in your service and can connect to remote
> cluster
> > of Apache Ignite for data persistence.
> >
> > Can you please correct my understanding on the usage of ignite-rest-http
> > in IGNITE-12518, I see the dependencies you have mentioned are related to
> > your project and my understanding is you are trying to use
> ignite-rest-http
> > jetty server for running your application. My understanding is this
> change
> > will make ignite-rest-http very large jar file with dependencies
> > like tomcat-servlet-api-9.0.10.jar may not needed outside of your project
> > scope.
> >
> > Please let me know your thoughts.
> >
> > Regards,
> > Saikat
> >
> >
> > On Sun, Jan 19, 2020 at 9:47 PM Luis Arce  wrote:
> >
> > > Hi Saikat,
> > > I agree, the impact of changes is bigger on the module.
> > > I have a question: If i need create a jaxws service what is your
> > > recomendation?
> > > My motivation for the changes is the next:
> > > *Introduction.*
> > > A few time ago i design a ABB for traceability for Oracle Service Bus
> > with
> > > the objective of detecting failures points in many processes of a
> > customer.
> > > In first instance my team worked with rest-http module in ignite 2.4
> with
> > > poor results, the quantity of TPS was 4.Then we make a implementation
> of
> > > Rest service inside Apache Tomcat and call to Apache Ignite directly to
> > > Database with persistence activated. This change, enabled the
> possibility
> > > for work with 4 environment of the customer (Development, Testing, QA,
> > > Production) with 8GB of RAM in the machine, the configuration of the
> > client
> > > had a Oracle Portal for the View layer, EJB for composition of the
> > > controller layer, and OSB for the integration the TPS of the client are
> > > biggest.
> > >
> > > *AS-IS*
> > >
> > > [image: imagen.png]
> > >
> > > *To Be roadmap*
> > >
> > > [image: imagen.png]
> > >
> > > With the ignite modification published in Jira is possible run JSF for
> > run
> > > my reports and forms, JaxWS for the service SOAP and Jersey for Rest (i
> > > start modification in this task).
> > > The code published in Jira have capabilites for work with Primefaces
> > > (tested ok), JaxWS (tested ok), but jersey is not included yet.
> > >
> > > Best regards,
> > >
> > >
> > > *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión
> > > 09-57861903
> > > Linkedin:
> > > https://cl.linkedin.com/in/luisalejandroarcemartinez
> > >
> > >
> > >
> > >
> > >
> > > El jue., 16 ene. 2020 a las 0:25, Saikat Maitra (<
> > saikat.mai...@gmail.com>)
> > > escribió:
> > >
> > >> Hi Luis,
> > >>
> > >> Thank you for sharing the details on the changes. I reviewed the
> > >> dependencies that you shared in the jira issue and wanted to discuss
> on
> > >> the
> > >> changes.
> > >>
> > >> The purpose of ignite-rest-http is to provide a web based interface to
> > >> easily access and use the ignite features and the changes you
> suggested
> > >> can
> > >> be 

Re: Feature masks for thin clients

[Igor Sapego]

Taras,

I believe we should have the same mechanism but different
set of flags.

Alexey,

The idea is to add new flag when you make changes instead of
increment protocol version. This way client maintainer can introduce
the same change (probably fix) in they client without the necessity to
implement all other features that were introduced in between.

Probably the "feature" word is confusing here. Maybe we should use
term "Changes Mask" or something like that.

Best Regards,
Igor


On Thu, Jan 23, 2020 at 5:27 PM Pavel Tupitsyn  wrote:

> Igor, great idea, I think this should be our priority for all thin clients.
>
> Alexei, protocol version bump can be still required for major changes (e.g.
> if we want to change handshake format).
> But for simpler things like new features that don't affect existing ones,
> feature masks allow us to keep current protocol version.
>
> On Thu, Jan 23, 2020 at 3:55 PM Taras Ledkov  wrote:
>
> > Alexei,
> >
> > After the flags is introduced we can change the flag set instead of
> > change protocol version.
> > Of course, we will need to up the protocol  version for introducing
> flags.
> >
> > On 23.01.2020 15:47, Alexei Scherbakov wrote:
> > > Igor Sapego,
> > >
> > > I do not understand how feature masks can remove the necessity of
> having
> > > protocol versioning.
> > > A protocol for one feature can change from release to release.
> > >
> > > чт, 23 янв. 2020 г. в 15:36, Igor Sapego :
> > >
> > >> Hi Igniters,
> > >>
> > >> As we have a lot of different thin clients now, maintained by
> different
> > >> people, the issues with our backward compatibility mechanism becomes
> > >> more and more prominent.
> > >>
> > >> Currently, we use protocol versioning as the only approach to provide
> > >> backward compatibility. The main issue of this approach is that we can
> > >> not skip some change in protocol and implement i.e. protocol of
> version
> > >> 1.5 without implementation of 1.4. There are many cases when one may
> > >> want to do so: e.g. when feature provided in 1.4 is not relevant for a
> > >> specific client, or when protocol version 1.5 contains urgent fix or
> > >> feature
> > >> which is easy to implement, but its blocked by not-so-urgent and
> > >> hard-to-implement feature introduced in 1.4.
> > >>
> > >> So to fix this issue I propose to introduce another backward
> > compatibility
> > >> mechanism. The idea is to send "supported features" mask by a client
> to
> > >> a server, which should be answered with the same mask by the server.
> > >> The resulting set of enabled features is acquired with a simple
> logical
> > >> "AND"
> > >> operation on these two masks.
> > >>
> > >> This change has many other positive effects:
> > >> 1. It improves readability and also potentially simplifies debugging.
> > >> 2. It gives users the ability to enable or disable features of thin
> > clients
> > >> on both
> > >> server and client as they desire.
> > >>
> > >> What are your thoughts guys?
> > >>
> > >> Best Regards,
> > >> Igor
> > >>
> > >
> > --
> > Taras Ledkov
> > Mail-To: tled...@gridgain.com
> >
> >
>

Re: AWS EBS Discovery: Contributor Wanted

[Sergey Chugunov]

Hello Emmanouil,

It would be great if we have at least basic integration tests in real AWS
environment. Even though they may require more work to keep them green (I
mean here AWS quotas and additional configuration/reconfiguration efforts)
it worth it because these tests can also be useful as an examples.

As the same time as IpFinder is such a basic component I don't think we
need to include them in constantly triggered suites like Run All but to
trigger them manually before/right after merging them to master branch or
when developing something in related code.

What do you think?

--
Thank you,
Sergey Chugunov.

On Thu, Jan 23, 2020 at 5:32 PM Emmanouil Gkatziouras 
wrote:

> Hi all!
>
> Yes It seems possible to get some free quota for integration tests on AWS
> [1] however most probably they are not gonna last forever.
>
> [1]
>
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
>
> King Regards
> *Emmanouil Gkatziouras*
> https://egkatzioura.com/ |
> https://www.linkedin.com/in/gkatziourasemmanouil/
> https://github.com/gkatzioura
>
>
> On Wed, 22 Jan 2020 at 16:48, Denis Magda  wrote:
>
> > Hi Emmanouil,
> >
> > Thanks for preparing a pull-request for Application Load Balancer:
> > https://issues.apache.org/jira/browse/IGNITE-8617
> >
> > Igniters, who is willing to step in as a primary reviewer?
> >
> > As for automated testing on AWS, are you aware of any sponsorship program
> > of AWS for open source projects of our kind? It will be ideal to have
> real
> > testing on AWS but someone needs to pay.
> >
> > -
> > Denis
> >
> >
> > On Sun, Jan 19, 2020 at 6:45 AM Emmanouil Gkatziouras <
> > gkatzio...@gmail.com>
> > wrote:
> >
> > > Hi all!
> > >
> > > I have spinned up an Application Load Balancer and an autoscaling group
> > on
> > > AWS and the Ignite discovery using TcpDiscoveryAlbIpFinder works as
> > > expected.
> > >
> > >- On startup nodes discover each other.
> > >- On ec2 node down, connection is lost and the cluster decreases.
> > >- On an extra node addition the cluster size increases
> > >
> > > This contribution is essential since the Previous ELB based discovery
> > uses
> > > the Classic Load Balancer which is still available however
> > > AWS advices users to use the Application one. [1]
> > > While my pull request gets reviewed I will also have a look at
> > > the IGNITE-12398 [2] issue which has to do with the S3 discovery.
> > > Another idea would also be to implement a `TCP Load Balancer based`
> > > discovery.
> > >
> > > In order to test this issue and future ones I implemented some
> terraform
> > > scripts (which I shall use for other issues too) [3].
> > > If some automated e2e testing on AWS is being considered they might be
> of
> > > value.
> > > I can help on implementing those tests by provisioning the
> infrastructure
> > > in an automated way and validate the discovery.
> > >
> > > [1]
> > >
> > >
> >
> https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-to-application-load-balancer.html
> > > [2] https://issues.apache.org/jira/browse/IGNITE-12398
> > > [3] https://github.com/gkatzioura/ignite-aws-deploy
> > >
> > > Kind regards,
> > > *Emmanouil Gkatziouras*
> > > https://egkatzioura.com/ |
> > > https://www.linkedin.com/in/gkatziourasemmanouil/
> > > https://github.com/gkatzioura
> > >
> > >
> > > On Tue, 14 Jan 2020 at 22:22, Denis Magda  wrote:
> > >
> > > > Hi Emmanouil,
> > > >
> > > > Agree, let's check that the IP finder functions normally in the cloud
> > > > environment and the mock tests can be used for regular testing on
> Team
> > > > City. That's the way we tested other environment-specific IP finders
> > > > including the Kubernetes one.
> > > >
> > > > Let us know once the IP finder is tested on AWS and then we can
> proceed
> > > > with the review.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Tue, Jan 14, 2020 at 2:47 AM Emmanouil Gkatziouras <
> > > > gkatzio...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all!
> > > > >
> > > > > With regards to the `Node Discovery Using AWS Application ELB`
> issue
> > > [1]
> > > > > I made this pull request to fix the merge conflicts [2].
> > > > > Will also check if the concerns described on the mailing list topic
> > > > > `Volunteer needed: AWS Elastic Load Balancer IP Finders
> implemented`
> > > are
> > > > > addressed [3]
> > > > > Since I did not test it on an AWS infrastructure the next step
> would
> > be
> > > > to
> > > > > spin up some AWS resources and test it.
> > > > > By doing so it will help me on checking the Amazon S3 Based
> Discovery
> > > > issue
> > > > > [4] .
> > > > > I will try to make the deployment as infrastructure as code, and
> see
> > if
> > > > > this can be of value for the ignite project and testing.
> > > > >
> > > > > Kind regards,
> > > > > Emmanouil
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8617
> > > > > [2]  https://github.com/apache/ignite/pull/7247
> > > > 

Re: Internal classes are exposed in public API

[Andrey Gura]

> My point - that your contribution that took a long time, already, can’t be an 
> argument to postpone creation of the API in the current release.

Argument is not about time. But about API which is known will be changed.
Second argument: why we should add this experimental API to the
already existing experimental API? Just to making API more
experimental? As I told already it is commit for commit and doesn't
bring any value but brings some inconvenience to me (e.g. merge
problems).

BTW, does it exist issue about marking IEP-35 API's as experimental?

On Thu, Jan 23, 2020 at 8:33 PM Николай Ижиков  wrote:
>
> > You want say didn't discuss?
>
> Yes.
>
> > Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
>
> No, of course.
> My point - that your contribution that took a long time, already, can’t be an 
> argument to postpone creation of the API in the current release.
>
>
> > 23 янв. 2020 г., в 18:11, Andrey Gura  написал(а):
> >
> >> We don’t discuss your changes and your proposals for the Metric API.
> >
> > You want say didn't discuss? Actually we did it [1] but you told ok
> > let's see code :)
> >
> >> So I don’t think we can make the existence of some PR is an argument to 
> >> introduce(or not introduce) this facade.
> >
> > You definitely right in case of competition development. But I think
> > that collaborative development is more effective. Isn't it?
> >
> >> Moreover, As far as I know, you developing changes for the Metric API for 
> >> 5 months without public discussion, for now. Let's start it.
> >
> > Firsty, with discussion. See above.
> > Secondly, yes it took a lot of time due to a lot of changes. Is it problem?
> >
> >> Let’s do the following:
> >> 1. Review `IgniteMetric` facade and introduce it to the users as an 
> >> experimental API.
> >
> > It just doesn't make sense. Just commit for commit.
> >
> >> 2. Discuss your proposal to the Metric API in the separate thread you are 
> >> referencing.
> >
> > You a re welcome to thread [1] again. But please, take into account.
> > because discussion is postponed by you it's late enough to discuss
> > proposed solution. But of course I'll answer on your questions and
> > will be glade to your comments and suggestions.
> >
> >> I think we should start a discussion from the simplified explanation of:
> >> 1. API intentions - What we want to gain with it? What is our focus?
> >> 2. Simple, minimal example of API main interfaces and desired usages.
> >
> > All this already described at [1]. You also can take a look on PR (see
> > MetricSource implementations, there are complex and simple ones).
> >
> > [1] 
> > http://apache-ignite-developers.2346864.n4.nabble.com/IEP-35-Metrics-management-in-Ignite-tp43243.html
> >
> > On Thu, Jan 23, 2020 at 5:42 PM Николай Ижиков  wrote:
> >>
> >> Andrey.
> >>
> >>> IGNITE-11927 implementation so your changes are incompatible with my 
> >>> changes
> >>
> >> We don’t discuss your changes and your proposals for the Metric API.
> >> So I don’t think we can make the existence of some PR is an argument to 
> >> introduce(or not introduce) this facade.
> >> Moreover, As far as I know, you developing changes for the Metric API for 
> >> 5 months without public discussion, for now. Let's start it.
> >>
> >> Let’s do the following:
> >>
> >> 1. Review `IgniteMetric` facade and introduce it to the users as an 
> >> experimental API.
> >>
> >> 2. Discuss your proposal to the Metric API in the separate thread you are 
> >> referencing.
> >>
> >> I think we should start a discussion from the simplified explanation of:
> >>
> >> 1. API intentions - What we want to gain with it? What is our focus?
> >> 2. Simple, minimal example of API main interfaces and desired usages.
> >>
> >> This will help to the community and me personally better understand your 
> >> idea and share feedback.
> >>
> >> Thanks.
> >>
> >>> 23 янв. 2020 г., в 17:15, Andrey Gura  написал(а):
> >>>
> >>> Nikolay,
> >>>
> >>> as I wrote early in this thread API significantly changed during
> >>> IGNITE-11927 implementation so your changes are incompatible with my
> >>> changes.
> >>>
> >>> ReadOnlyMetricRegistry will be removed at all (still exists in a
> >>> couple of places where it uses).
> >>>
> >>> Also I don't want to introduce IgniteMetric facade in this rush. In
> >>> current implementation this interface just provides access to the
> >>> ReadOnlyMetricManager instance (which will be removed) but it is not
> >>> enough.
> >>>
> >>> I agree with Denis. We should mark current API as experimental and
> >>> continue IEP-35 development. See my process proposal [1] described
> >>> early this thread. We can release Apache Ignite 2.8.1 specially for
> >>> this changes.
> >>> Public APIs require deeper thinking in order to provide comprehensive,
> >>> consistent and convenient way of metrics management for end users.
> >>>
> >>> Let's add IgniteExperimental, release 2.8 and finish metrics related
> >>> issues after it.
> >>>
> 

Re: Thin client: compute support

[Alex Plehanov]

We've discussed thin client compute protocol with Pavel Tupitsyn and Igor
Sapego and come to the conclusion that approach with two-way requests
should be used: client generates taskId and send a request to the server to
execute a task. The server responds that the request has been accepted.
After task has finished the server notifies the client (send a request
without waiting for a response). The client can cancel the task by sending
a corresponding request to the server.

Also, a node list should be passed (optionally) with a request to limit
nodes to execute the task.

I will create IEP and file detailed protocol changes shortly.

вт, 21 янв. 2020 г. в 18:46, Alex Plehanov :

> Igor, thanks for the reply.
>
> > Approach with taskId will require a lot of changes in protocol and thus
> more "heavy" for implementation
> Do you mean approach with server notifications mechanism? Yes, it will
> require a lot of changes. But in most recent messages we've discussed with
> Pavel approach without server notifications mechanism. This approach have
> the same complexity and performance as an approach with requestId.
>
> > But such clients as Python, Node.js, PHP, Go most probably won't have
> support for this API, at least for now.
> Without a server notifications mechanism, there will be no breaking
> changes in the protocol, so client implementation can just skip this
> feature and protocol version and implement the next one.
>
> > Or never.
> I think it still useful to execute java compute tasks from non-java thin
> clients. Also, we can provide some out-of-the-box java tasks, for example
> ExecutePythonScriptTask with python compute implementation, which can run
> python script on server node.
>
> > So, maybe it's a good time for us to change our backward compatibility
> mechanism from protocol versioning to feature masks?
> I like the idea with feature masks, but it will force us to support both
> backward compatibility mechanisms, protocol versioning and feature masks.
>
> пн, 20 янв. 2020 г. в 20:34, Pavel Tupitsyn :
>
>> Huge +1 from me for Feature Masks.
>> I think this should be our top priority for thin client protocol, since it
>> simplifies change management a lot.
>>
>> On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego  wrote:
>>
>> > Sorry for the late reply.
>> >
>> > Approach with taskId will require a lot of changes in protocol and thus
>> > more "heavy" for implementation, but it definitely looks to me less
>> hacky
>> > than reqId-approach. Moreover, as was mentioned, server notifications
>> > mechanism will be required in a future anyway with high probability. So
>> > from this point of view I like taskId-approach.
>> >
>> > On the other hand, what we should also consider here is performance.
>> > Speaking of latency, it looks like reqId will have better results in
>> case
>> > of
>> > small and fast tasks. The only question here, if we want to optimize
>> thin
>> > clients for this case.
>> >
>> > Also, what are you talking about mostly involves clients on platforms
>> > that already have Compute API for thick clients. Let me mention one
>> > more point of view here and another concern here.
>> >
>> > The changes you propose are going to change protocol version for sure.
>> > In case with taskId approach and server notifications - even more so.
>> >
>> > But such clients as Python, Node.js, PHP, Go most probably won't have
>> > support for this API, at least for now. Or never. But current
>> > backward-compatibility mechanism implies protocol versions where we
>> > imply that client that supports version 1.5 also supports all the
>> features
>> > introduced in all the previous versions of the protocol.
>> >
>> > Thus implementing Compute API in any of the proposed ways *may*
>> > force mentioned clients to support changes in protocol which they not
>> > necessarily need in order to introduce new features in the future.
>> >
>> > So, maybe it's a good time for us to change our backward compatibility
>> > mechanism from protocol versioning to feature masks?
>> >
>> > WDYT?
>> >
>> > Best Regards,
>> > Igor
>> >
>> >
>> > On Fri, Jan 17, 2020 at 9:37 AM Alex Plehanov 
>> > wrote:
>> >
>> > > Looks like we didn't rich consensus here.
>> > >
>> > > Igor, as thin client maintainer, can you please share your opinion?
>> > >
>> > > Everyone else also welcome, please share your thoughts about options
>> to
>> > > implement operations for compute.
>> > >
>> > >
>> > > чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov > >:
>> > >
>> > > > > Since all thin client operations are inherently async, we should
>> be
>> > > able
>> > > > to cancel any of them
>> > > > It's illogical to have such ability. What should do cancel
>> operation of
>> > > > cancel operation? Moreover, sometimes it's dangerous, for example,
>> > create
>> > > > cache operation should never be canceled. There should be an
>> explicit
>> > set
>> > > > of processes that we can cancel: queries, transactions, tasks,
>> > services.
>> > > > The 

Re: New contributor

[Ivan Pavlukhin]

Vladimir,

Welcome to Apache Ignite Community!

I added a contributor role to your Jira account. Now you can assign
tickets to yourself. Please get familiar with the contribution process
[1].

By the way,

> I've just joined a team with the commiters.

Could you tell us what team did you join?

[1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

пт, 24 янв. 2020 г. в 16:01, Vladimir Steshin :
>
> Hello everyone!
>
> My name is Vladimir. I'd like to become new contributor of Apache Ignite as
> a developer. I've just joined a team with the commiters. I've been working
> as Java developer more than 10 years with a bunch of various frameworks and
> solutions. Now I'm interrested in modern open source pojects, distributed
> data bases and computations. I have an expirience of working with Apache
> Ignite in real project on production. I'd be happy to participate in
> evolving of this project. A couple of fix-tickets have been already issued
> some time ago by my questions on the user forum :)
>
> You can find me in Jira as 'vladsz83'.
>
> Thanks!



-- 
Best regards,
Ivan Pavlukhin

Re: JAVADOC fails on local build. Should it be checked on TC?

[Ivan Pavlukhin]

Actually, I got stuck with a question what do modules like
ignite-hibernate mean from a javadoc standpoint. It seems that modules
sharing same packages and classes cannot be aggregated into valid
javadoc bundle. And actually this problem should be solved as well
(modularization?). But I suppose that it is closer to a release
process rather than daily TC check.

So, my current understanding is:
1. Javadoc job should be fixed to reveal problems (with code links).
2. "javadoc" profile is not needed for daily TC check, but it
highlights some release-related problems.

пт, 24 янв. 2020 г. в 15:44, Maxim Muzafarov :
>
> Folks,
>
>
> It's true that my simple assumption (to include Javadoc profile) will
> not work by reasons mentioned by Petr. I've tested it under a new
> experimental suite [1] which I've created earlier. We will always have
> such warnings due to we have multiple modules with the same package
> declarations (e.g. ignite-hibernate_5.1, hibernate_4.2, hibernate_5.3
> modules and the same for others like spring-data):
>
> [WARNING] Javadoc: warning - Multiple sources of package comments
> found for package "org.apache.ignite.cache.store.hibernate"
>
> So, if we build all modules it's not correct to fail the whole JavaDoc
> suite by existing such warnings in the suite logs.
>
>
> I'm still thinking of how can we handle all such cases and I don't
> have an easy solution for now. At least we can do checks with two
> steps:
> 1. build with Javadoc profile ignore warnings (fail on an error)
> 2. build and check that there is no warnings for ignite-core module
>
> Thoughts?
>
>
> [1] 
> https://ci.ignite.apache.org/viewLog.html?buildId=4927599=IgniteTests24Java8_JavadocExtended
>
>
>
> On Fri, 24 Jan 2020 at 13:47, Ivan Pavlukhin  wrote:
> >
> > Petr,
> >
> > Thank you for that detail! Unfortunately I do not know how to fix it easily.
> >
> > Also I found that even without "javadoc" profile we miss some javadoc
> > problems. I believe that it can be fixed by updating post-build
> > javadoc checking condition. See below what problems do we miss (and
> > there are a bit more in full logs):
> > [05:08:51]W: [Step 2/2] [WARNING] Javadoc Warnings
> > [05:08:51]W: [Step 2/2] [WARNING]
> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
> > warning - Tag @link: reference not found:
> > GridDistributedCacheAdapter.GlobalRemoveAllJob
> > [05:08:51]W: [Step 2/2] [WARNING]
> > /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
> > warning - Tag @link: reference not found:
> > GridDistributedCacheAdapter.GlobalRemoveAllJob
> >
> > пт, 24 янв. 2020 г. в 11:56, Petr Ivanov :
> > >
> > > We could not because of multiple hibernate modules, what is considered 
> > > from the javadoc's point as warning, that always fails test.
> > >
> > >
> > > > On 24 Jan 2020, at 11:02, Ivan Pavlukhin  wrote:
> > > >
> > > > Maxim,
> > > >
> > > > I suppose we can try to enable "javadoc" profile for a corresponding
> > > > job. Are there any objections to do so?
> > > >
> > > > пн, 20 янв. 2020 г. в 13:25, Ivan Pavlukhin :
> > > >>
> > > >> Maxim,
> > > >>
> > > >> From the first glance it seems that "javadoc" profile was really
> > > >> missed. Are there any other problems except springdata22? If no then
> > > >> we can add the profile. Also it is interesting how it influence on
> > > >> execution time?
> > > >>
> > > >> пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
> > > >>>
> > > >>> Igniters,
> > > >>>
> > > >>>
> > > >>> I've run locally maven command according to DEVNOTES:
> > > >>>
> > > >>> mvn initialize -Pjavadoc
> > > >>>
> > > >>> and it fails due to: 'Other Packages' section should not be present,
> > > >>> all packages should have corresponding documentation groups. The
> > > >>> reason of that is a newly added `org.apache.ignite.springdata22`
> > > >>> package [1]  is missing in maven-javadoc-plugin configuration [2].
> > > >>>
> > > >>>
> > > >>> We have Javadoc Suite [3] but it not checks such issues due to
> > > >>> `javadoc` maven profile required to be enabled.
> > > >>> Should we enable `javadoc` profile for this suite?
> > > >>> Any other thoughts?
> > > >>>
> > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12259
> > > >>> [2] https://issues.apache.org/jira/browse/IGNITE-12528
> > > >>> [3] 
> > > >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Ivan Pavlukhin
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin



-- 
Best regards,
Ivan Pavlukhin

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

[Maxim Muzafarov]

Folks,


I've cherry-picked these issues [1] [2] to the 2.8 release branch.


[1] https://issues.apache.org/jira/browse/IGNITE-12540
Update versions of vulnerable dependencies

[2] https://issues.apache.org/jira/browse/IGNITE-12486
Truncation of archived WAL segments doesn't work

On Thu, 23 Jan 2020 at 11:08, Ivan Bessonov  wrote:
>
> Hi igniters,
>
> there's a potential data corruption fix that I'd like you to include in the
> next release:
> https://issues.apache.org/jira/browse/IGNITE-12486https://issues.apache.org/jira/browse/IGNITE-12486
> 
>
> Can you please cherry-pick it? Thank you!
>
> ср, 22 янв. 2020 г. в 17:45, Pavel Tupitsyn :
>
> > Good idea about pre-release build of ignite-2.8 branch.
> > However, I would not name it `rc`, since it is not really a release
> > candidate. Make it `pre0` or something like that.
> >
> > For Ignite.NET I've uploaded pre-release NuGet packages built from current
> > ignite-2.8 branch:
> > https://www.nuget.org/packages/Apache.Ignite/2.8.0-alpha20200122
> >
> >
> > On Wed, Jan 22, 2020 at 3:09 PM Ilya Kasnacheev  > >
> > wrote:
> >
> > > Hello!
> > >
> > > I have committed the bumping of essential dependencies' versions:
> > > https://issues.apache.org/jira/browse/IGNITE-12540
> > >
> > > Would you mind including this change into the scope of 2.8? No point of
> > > shipping known problematic JARs in our deliverable.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 22 янв. 2020 г. в 14:00, Maxim Muzafarov :
> > >
> > > > Alexey,
> > > >
> > > > Sure, I've just thought about it too a few days ago.
> > > >
> > > > On Wed, 22 Jan 2020 at 12:09, Anton Vinogradov  wrote:
> > > > >
> > > > > Good Idea, this will also check that the release process is alive.
> > > > >
> > > > > On Wed, Jan 22, 2020 at 12:04 PM Alexey Goncharuk <
> > > > > alexey.goncha...@gmail.com> wrote:
> > > > >
> > > > > > Folks, Maxim,
> > > > > >
> > > > > > Do you mind if I build the current state of ignite-2.8 branch and
> > > > upload a
> > > > > > maven staging as rc0 (step 4.3.2 of the release process)? I want
> > run
> > > > some
> > > > > > tests for the fixes that are already included to the branch.
> > > > > >
> > > > > > вт, 21 янв. 2020 г. в 14:28, Maxim Muzafarov :
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > >
> > > > > > > I think both of these issues [1] [2] are critical to 2.8 release
> > > and
> > > > > > > we must include them.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12547
> > > > > > > Excessive AtomicLong instantiations lead to GC pressure.
> > > > > > >
> > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12530
> > > > > > > Pages list caching can cause IgniteOOME when the checkpoint is
> > > > > > > triggered by "too many dirty pages" reason.
> > > > > > >
> > > > > > >
> > > > > > > On Mon, 20 Jan 2020 at 19:00, Alex Plehanov <
> > > plehanov.a...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > There is an issue [1] caused by page list caching [2], which
> > also
> > > > > > affects
> > > > > > > > 2.8 release. IgniteOutOfMemoryException can be thrown in some
> > > cases
> > > > > > (data
> > > > > > > > region is small, a checkpoint is triggered by "too many dirty
> > > > pages"
> > > > > > > reason
> > > > > > > > and pages list cache is rather big).
> > > > > > > > The fix is ready and merged to master, I suggest to include
> > this
> > > > fix to
> > > > > > > 2.8
> > > > > > > > release. What do you think?
> > > > > > > >
> > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-12530
> > > > > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-6930
> > > > > > > >
> > > > > > > > пн, 20 янв. 2020 г. в 12:57, Alexey Goncharuk <
> > > > > > > alexey.goncha...@gmail.com>:
> > > > > > > >
> > > > > > > > > Maxim,
> > > > > > > > >
> > > > > > > > > I took a quick look at IGNITE-12456 and I am not sure it's
> > > about
> > > > data
> > > > > > > > > corruption. In the attached logs blocked system threads are
> > > > reported,
> > > > > > > > > however, there is no enough information to investigate the
> > > issue
> > > > (the
> > > > > > > full
> > > > > > > > > thread dump was not attached). I asked the ticket creator to
> > > > attach
> > > > > > > missing
> > > > > > > > > pieces.
> > > > > > > > >
> > > > > > > > > Should we consider moving this ticket to a next release?
> > > > > > > > >
> > > > > > > > > пн, 20 янв. 2020 г. в 08:54, Zhenya Stanilovsky
> > > > > > >  > > > > > > > > >:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Maxim, performance fix issue [1] already in master, if no
> > > > > > > objections, can
> > > > > > > > > > u merge it into 2.8 ? Thanks !
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12547
> > > > > > > > > >
> > > > > > > > > > >Igniters,
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > 

New contributor

[Vladimir Steshin]

Hello everyone!

My name is Vladimir. I'd like to become new contributor of Apache Ignite as
a developer. I've just joined a team with the commiters. I've been working
as Java developer more than 10 years with a bunch of various frameworks and
solutions. Now I'm interrested in modern open source pojects, distributed
data bases and computations. I have an expirience of working with Apache
Ignite in real project on production. I'd be happy to participate in
evolving of this project. A couple of fix-tickets have been already issued
some time ago by my questions on the user forum :)

You can find me in Jira as 'vladsz83'.

Thanks!

Re: JAVADOC fails on local build. Should it be checked on TC?

[Maxim Muzafarov]

Folks,


It's true that my simple assumption (to include Javadoc profile) will
not work by reasons mentioned by Petr. I've tested it under a new
experimental suite [1] which I've created earlier. We will always have
such warnings due to we have multiple modules with the same package
declarations (e.g. ignite-hibernate_5.1, hibernate_4.2, hibernate_5.3
modules and the same for others like spring-data):

[WARNING] Javadoc: warning - Multiple sources of package comments
found for package "org.apache.ignite.cache.store.hibernate"

So, if we build all modules it's not correct to fail the whole JavaDoc
suite by existing such warnings in the suite logs.


I'm still thinking of how can we handle all such cases and I don't
have an easy solution for now. At least we can do checks with two
steps:
1. build with Javadoc profile ignore warnings (fail on an error)
2. build and check that there is no warnings for ignite-core module

Thoughts?


[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=4927599=IgniteTests24Java8_JavadocExtended



On Fri, 24 Jan 2020 at 13:47, Ivan Pavlukhin  wrote:
>
> Petr,
>
> Thank you for that detail! Unfortunately I do not know how to fix it easily.
>
> Also I found that even without "javadoc" profile we miss some javadoc
> problems. I believe that it can be fixed by updating post-build
> javadoc checking condition. See below what problems do we miss (and
> there are a bit more in full logs):
> [05:08:51]W: [Step 2/2] [WARNING] Javadoc Warnings
> [05:08:51]W: [Step 2/2] [WARNING]
> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
> warning - Tag @link: reference not found:
> GridDistributedCacheAdapter.GlobalRemoveAllJob
> [05:08:51]W: [Step 2/2] [WARNING]
> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
> warning - Tag @link: reference not found:
> GridDistributedCacheAdapter.GlobalRemoveAllJob
>
> пт, 24 янв. 2020 г. в 11:56, Petr Ivanov :
> >
> > We could not because of multiple hibernate modules, what is considered from 
> > the javadoc's point as warning, that always fails test.
> >
> >
> > > On 24 Jan 2020, at 11:02, Ivan Pavlukhin  wrote:
> > >
> > > Maxim,
> > >
> > > I suppose we can try to enable "javadoc" profile for a corresponding
> > > job. Are there any objections to do so?
> > >
> > > пн, 20 янв. 2020 г. в 13:25, Ivan Pavlukhin :
> > >>
> > >> Maxim,
> > >>
> > >> From the first glance it seems that "javadoc" profile was really
> > >> missed. Are there any other problems except springdata22? If no then
> > >> we can add the profile. Also it is interesting how it influence on
> > >> execution time?
> > >>
> > >> пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
> > >>>
> > >>> Igniters,
> > >>>
> > >>>
> > >>> I've run locally maven command according to DEVNOTES:
> > >>>
> > >>> mvn initialize -Pjavadoc
> > >>>
> > >>> and it fails due to: 'Other Packages' section should not be present,
> > >>> all packages should have corresponding documentation groups. The
> > >>> reason of that is a newly added `org.apache.ignite.springdata22`
> > >>> package [1]  is missing in maven-javadoc-plugin configuration [2].
> > >>>
> > >>>
> > >>> We have Javadoc Suite [3] but it not checks such issues due to
> > >>> `javadoc` maven profile required to be enabled.
> > >>> Should we enable `javadoc` profile for this suite?
> > >>> Any other thoughts?
> > >>>
> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12259
> > >>> [2] https://issues.apache.org/jira/browse/IGNITE-12528
> > >>> [3] 
> > >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Ivan Pavlukhin
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> >
>
>
> --
> Best regards,
> Ivan Pavlukhin

[jira] [Created] (IGNITE-12580) NPE in GridMetricManager

[Alexey Scherbakov (Jira)]

Alexey Scherbakov created IGNITE-12580:
--

 Summary: NPE in GridMetricManager
 Key: IGNITE-12580
 URL: https://issues.apache.org/jira/browse/IGNITE-12580
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Scherbakov
 Fix For: 2.9


NPE is thrown during cache recovery:

{noformat}
class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7534)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:234)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:152)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:816)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:675)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1375)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:615)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1017)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:958)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:946)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:895)
at 
org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.doTestSimple(LocalWalModeChangeDuringRebalancingSelfTest.java:263)
at 
org.apache.ignite.internal.processors.cache.persistence.LocalWalModeChangeDuringRebalancingSelfTest.testWalDisabledDuringRebalancing(LocalWalModeChangeDuringRebalancingSelfTest.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.metric.GridMetricManager.remove(GridMetricManager.java:396)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.stop(GridCacheAdapter.java:669)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1024)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:998)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCaches(GridCacheProcessor.java:754)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onBaselineChange(GridCacheProcessor.java:5460)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:982)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:849)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3236)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3085)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
... 1 more
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12579) SQL INSERT operation hangs with security enabled.

[PetrovMikhail (Jira)]

PetrovMikhail created IGNITE-12579:
--

 Summary: SQL INSERT operation hangs with security enabled.
 Key: IGNITE-12579
 URL: https://issues.apache.org/jira/browse/IGNITE-12579
 Project: Ignite
  Issue Type: Bug
Reporter: PetrovMikhail


 

SQL INSERT operation may hangs in case INSERT KEY belongs to remote node(node 
that is different from one to which jdbc connection was established) with the 
following exception in log:
{code:java}
[2020-01-24 
14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][IgniteTestResources]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, 
err=java.lang.NullPointerException]][2020-01-24 
14:59:42,189][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][IgniteTestResources]
 Critical system error detected. Will be handled accordingly to configured 
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, 
err=java.lang.NullPointerException]]java.lang.NullPointerException at 
org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
 at 
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
 at 
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
 at 
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1470)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
 at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) 
at java.lang.Thread.run(Thread.java:748)[2020-01-24 14:59:42,198][WARN 
][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][CacheDiagnosticManager] Page 
locks dump:
Thread=[name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1%, id=116], 
state=WAITINGLocked pages = []Locked pages log: 
name=auth-#83%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 2020-01-24 
14:59:42.194)Thread=[name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1%,
 id=135], state=TIMED_WAITINGLocked pages = []Locked pages log: 
name=db-checkpoint-thread-#101%jdbc.JdbcRemoteKeyInsertTest1% 
time=(1579867182194, 2020-01-24 
14:59:42.194)Thread=[name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1%, 
id=126], state=WAITINGLocked pages = []Locked pages log: 
name=dms-writer-thread-#92%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 
2020-01-24 
14:59:42.194)Thread=[name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1%, 
id=117], state=TIMED_WAITINGLocked pages = []Locked pages log: 
name=exchange-worker-#84%jdbc.JdbcRemoteKeyInsertTest1% time=(1579867182194, 
2020-01-24 14:59:42.194)Thread=[name=main, id=1], state=TIMED_WAITINGLocked 
pages = []Locked pages log: name=main time=(1579867182193, 2020-01-24 
14:59:42.193)
[2020-01-24 
14:59:42,198][ERROR][sys-stripe-4-#48%jdbc.JdbcRemoteKeyInsertTest1%][G] Failed 
to execute runnable.java.lang.NullPointerException at 
org.apache.ignite.internal.processors.security.SecurityUtils.nodeSecurityContext(SecurityUtils.java:132)
 at 
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.lambda$withContext$0(IgniteSecurityProcessor.java:106)
 at 
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
 at 
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:105)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1844)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1470)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
 at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) 
at java.lang.Thread.run(Thread.java:748)
{code}
 Reproducer is attached 

Re: [MTCGA]: new failures in builds [4939116] needs to be handled

[Maxim Muzafarov]

Folks,


This test began to constantly fail in the master branch [2] and the
2.8 [1] also. It seems it's related to the [3] issue (IGNITE-12531:
Cluster is unable to change BLT on 2.8 if storage was initially
created on 2.7 or less) which have been recently fixed and
cherry-picked to 2.8.

Can you please double-check you commit?


[1] 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5923369202582779855=%3Cdefault%3E=testDetails_IgniteTests24Java8=ignite-2.8
[2] 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5923369202582779855=%3Cdefault%3E=testDetails_IgniteTests24Java8=%3Cdefault%3E
[3] https://issues.apache.org/jira/browse/IGNITE-12531

On Sat, 18 Jan 2020 at 14:41,  wrote:
>
> Hi Igniters,
>
>  I've detected some new issue on TeamCity to be handled. You are more than 
> welcomed to help.
>
>  If your changes can lead to this failure(s): We're grateful that you were a 
> volunteer to make the contribution to this project, but things change and you 
> may no longer be able to finalize your contribution.
>  Could you respond to this email and indicate if you wish to continue and fix 
> test failures or step down and some committer may revert you commit.
>
>  *New test failure in master-nightly 
> DistributedMetaStoragePersistentTest.testUnstableTopology 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5923369202582779855=%3Cdefault%3E=testDetails
>  Changes may lead to failure were done by
>  - maxim muzafarov  
> https://ci.ignite.apache.org/viewModification.html?modId=895676
>  - aleksei scherbakov  
> https://ci.ignite.apache.org/viewModification.html?modId=895694
>  - denis garus  
> https://ci.ignite.apache.org/viewModification.html?modId=895630
>  - slava koptilin  
> https://ci.ignite.apache.org/viewModification.html?modId=895689
>  - slava koptilin  
> https://ci.ignite.apache.org/viewModification.html?modId=895688
>  - evgeny stanilovskiy  
> https://ci.ignite.apache.org/viewModification.html?modId=895672
>  - andrew v. mashenkov  
> https://ci.ignite.apache.org/viewModification.html?modId=895683
>
>  - Here's a reminder of what contributors were agreed to do 
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>  - Should you have any questions please contact dev@ignite.apache.org
>
> Best Regards,
> Apache Ignite TeamCity Bot
> https://github.com/apache/ignite-teamcity-bot
> Notification generated at 14:41:19 18-01-2020

Re: Request for review: @IgniteExperimental

[Anton Vinogradov]

Great, Thanks!

On Fri, Jan 24, 2020 at 1:14 PM Alexey Goncharuk 
wrote:

> Thanks to all for the review, the annotation has been added, also created
> an additional ticket for documentation.
>
> вт, 21 янв. 2020 г. в 16:23, Alexey Goncharuk  >:
>
> > Pavel, Igor,
> >
> > Can you add similar annotations/attributes to platforms?
> >
> > вт, 21 янв. 2020 г. в 16:01, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> >> Igniters,
> >>
> >> As discussed in the thread [1], we want to add an annotation marking an
> >> API or feature experimental. The corresponding ticket and PR are
> [2],[3].
> >>
> >> Please take a look at the description and suggest any edits to the
> >> javadoc if necessary.
> >>
> >> A side question - Anton Vinogradov asked me to mark the read-repair
> >> feature as experimental in this PR. Should I also mark the IEP-35
> >> interfaces there as well or should we move that change to a separate
> ticket?
> >>
> >> [1]
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
> >> [2] https://issues.apache.org/jira/browse/IGNITE-12559
> >> [3] https://github.com/apache/ignite/pull/7279
> >>
> >
>

[jira] [Created] (IGNITE-12578) CAS cache operations (replace(K, V, V), remove(K, V)) don't work with array data type

[Aleksey Plekhanov (Jira)]

Aleksey Plekhanov created IGNITE-12578:
--

 Summary: CAS cache operations (replace(K, V, V), remove(K, V)) 
don't work with array data type
 Key: IGNITE-12578
 URL: https://issues.apache.org/jira/browse/IGNITE-12578
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Aleksey Plekhanov


Values are compared using {{CacheEntryPredicateContainsValue}} predicate, this 
predicate call {{F.eq(thisVal, cacheVal)}} to compare, which gives false for 
two instances of arrays with the same content.

Reproducer:
{code:java}
IgniteCache cache = 
startGrid().getOrCreateCache(DEFAULT_CACHE_NAME);
Object val = new byte[] {1};
cache.put(1, val);
assertTrue(cache.replace(1, val, val));
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: JAVADOC fails on local build. Should it be checked on TC?

[Ivan Pavlukhin]

Petr,

Thank you for that detail! Unfortunately I do not know how to fix it easily.

Also I found that even without "javadoc" profile we miss some javadoc
problems. I believe that it can be fixed by updating post-build
javadoc checking condition. See below what problems do we miss (and
there are a bit more in full logs):
[05:08:51]W: [Step 2/2] [WARNING] Javadoc Warnings
[05:08:51]W: [Step 2/2] [WARNING]
/opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
warning - Tag @link: reference not found:
GridDistributedCacheAdapter.GlobalRemoveAllJob
[05:08:51]W: [Step 2/2] [WARNING]
/opt/buildagent/work/7bc1c54bc719b67c/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheContext.java:2351:
warning - Tag @link: reference not found:
GridDistributedCacheAdapter.GlobalRemoveAllJob

пт, 24 янв. 2020 г. в 11:56, Petr Ivanov :
>
> We could not because of multiple hibernate modules, what is considered from 
> the javadoc's point as warning, that always fails test.
>
>
> > On 24 Jan 2020, at 11:02, Ivan Pavlukhin  wrote:
> >
> > Maxim,
> >
> > I suppose we can try to enable "javadoc" profile for a corresponding
> > job. Are there any objections to do so?
> >
> > пн, 20 янв. 2020 г. в 13:25, Ivan Pavlukhin :
> >>
> >> Maxim,
> >>
> >> From the first glance it seems that "javadoc" profile was really
> >> missed. Are there any other problems except springdata22? If no then
> >> we can add the profile. Also it is interesting how it influence on
> >> execution time?
> >>
> >> пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
> >>>
> >>> Igniters,
> >>>
> >>>
> >>> I've run locally maven command according to DEVNOTES:
> >>>
> >>> mvn initialize -Pjavadoc
> >>>
> >>> and it fails due to: 'Other Packages' section should not be present,
> >>> all packages should have corresponding documentation groups. The
> >>> reason of that is a newly added `org.apache.ignite.springdata22`
> >>> package [1]  is missing in maven-javadoc-plugin configuration [2].
> >>>
> >>>
> >>> We have Javadoc Suite [3] but it not checks such issues due to
> >>> `javadoc` maven profile required to be enabled.
> >>> Should we enable `javadoc` profile for this suite?
> >>> Any other thoughts?
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-12259
> >>> [2] https://issues.apache.org/jira/browse/IGNITE-12528
> >>> [3] 
> >>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>


-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-12577) High persistence load can trigger erroneous assert: "Page was pin when we resolve abs pointer, it can not be evicted".

[Stanilovsky Evgeny (Jira)]

Stanilovsky Evgeny created IGNITE-12577:
---

 Summary: High persistence load can trigger erroneous assert: "Page 
was pin when we resolve abs pointer, it can not be evicted".
 Key: IGNITE-12577
 URL: https://issues.apache.org/jira/browse/IGNITE-12577
 Project: Ignite
  Issue Type: Bug
  Components: data structures
Affects Versions: 2.7.6
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Fix For: 2.8






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] ThreadGroup for IgniteThread

[Alexey Goncharuk]

Ivan,

I believe that the removal of the thread group is harmless. Let's check
with the rest of the community, and if there is no objections, remove it.

пт, 24 янв. 2020 г. в 11:13, Ivan Pavlukhin :

> Alex,
>
> > We can either remove it (not sure if this is a breaking public API
> change?)
> > or create a separate thread group per Ignite instance and pass it to the
> > constructor of IgniteThread (quite a lot of refactoring).
>
> Recently there were a discussion about "magic stuff" in codebase. And
> it seems that we should eliminate such stuff if there is no chance to
> understand why is it needed.
>
> I run TC after dropping special ThreadGroup and did not get any new
> failures [1]. It can imagine that dedicated ThreadGroup has some sense
> for application servers. But personally I would prefer to get rid of
> that ThreadGroup. A more conservative approach is to use some flag
> (system property) to control it.
>
> [1]
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/7297/head=Latest
>
> вт, 21 янв. 2020 г. в 16:39, Alexey Goncharuk  >:
> >
> > Ivan,
> >
> > I cannot recall why exactly a separate thread group was needed. I guess
> the
> > intention was to collect all threads related to Ignite to one group, but
> I
> > see no practical use of that particular implementation.
> >
> > We can either remove it (not sure if this is a breaking public API
> change?)
> > or create a separate thread group per Ignite instance and pass it to the
> > constructor of IgniteThread (quite a lot of refactoring).
> >
> > вт, 21 янв. 2020 г. в 13:17, Ivan Pavlukhin :
> >
> > > Hi,
> > >
> > > As you might know, IgniteThread class captures calling ThreadGroup on
> > > initialization (as IgniteThread.DFLT_GRP) and includes all new ignite
> > > threads into this group. A user reported an issue [1] related to it.
> > > And the root cause here is that captured DFLT_GRP is out of control of
> > > IgniteThread class. Looks like a design fault. Consequently several
> > > unclear points:
> > > 1. What is the real need for IgniteThread.DFLT_GRP?
> > > 2. Can we simply stop using this trick?
> > > 3. Could there be any better options to do the same?
> > >
> > > Please share your thoughts.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12554
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: Request for review: @IgniteExperimental

[Alexey Goncharuk]

Thanks to all for the review, the annotation has been added, also created
an additional ticket for documentation.

вт, 21 янв. 2020 г. в 16:23, Alexey Goncharuk :

> Pavel, Igor,
>
> Can you add similar annotations/attributes to platforms?
>
> вт, 21 янв. 2020 г. в 16:01, Alexey Goncharuk  >:
>
>> Igniters,
>>
>> As discussed in the thread [1], we want to add an annotation marking an
>> API or feature experimental. The corresponding ticket and PR are [2],[3].
>>
>> Please take a look at the description and suggest any edits to the
>> javadoc if necessary.
>>
>> A side question - Anton Vinogradov asked me to mark the read-repair
>> feature as experimental in this PR. Should I also mark the IEP-35
>> interfaces there as well or should we move that change to a separate ticket?
>>
>> [1]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Internal-classes-are-exposed-in-public-API-td45146.html
>> [2] https://issues.apache.org/jira/browse/IGNITE-12559
>> [3] https://github.com/apache/ignite/pull/7279
>>
>

[jira] [Created] (IGNITE-12576) [IEP-35] TCP communication metrics use node ID instead of consistent ID

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-12576:
--

 Summary: [IEP-35] TCP communication metrics use node ID instead of 
consistent ID
 Key: IGNITE-12576
 URL: https://issues.apache.org/jira/browse/IGNITE-12576
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


TcpCommunicationMetricsListener uses nodeId for metrics name. consistentId 
should be used instead.

Also all metrics for registry should be created at once before registry added 
to GridMetricManager. There is no need in separate initialization for sent and 
received counters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-12575) Document @IgniteExperimental annotation

[Alexey Goncharuk (Jira)]

Alexey Goncharuk created IGNITE-12575:
-

 Summary: Document @IgniteExperimental annotation
 Key: IGNITE-12575
 URL: https://issues.apache.org/jira/browse/IGNITE-12575
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.8
Reporter: Alexey Goncharuk
 Fix For: 2.8


We introduced the annotation to mark APIs which are exposed to users to try out 
new features, but the APIs are likely to evolve in the future.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: JAVADOC fails on local build. Should it be checked on TC?

[Petr Ivanov]

We could not because of multiple hibernate modules, what is considered from the 
javadoc's point as warning, that always fails test.


> On 24 Jan 2020, at 11:02, Ivan Pavlukhin  wrote:
> 
> Maxim,
> 
> I suppose we can try to enable "javadoc" profile for a corresponding
> job. Are there any objections to do so?
> 
> пн, 20 янв. 2020 г. в 13:25, Ivan Pavlukhin :
>> 
>> Maxim,
>> 
>> From the first glance it seems that "javadoc" profile was really
>> missed. Are there any other problems except springdata22? If no then
>> we can add the profile. Also it is interesting how it influence on
>> execution time?
>> 
>> пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
>>> 
>>> Igniters,
>>> 
>>> 
>>> I've run locally maven command according to DEVNOTES:
>>> 
>>> mvn initialize -Pjavadoc
>>> 
>>> and it fails due to: 'Other Packages' section should not be present,
>>> all packages should have corresponding documentation groups. The
>>> reason of that is a newly added `org.apache.ignite.springdata22`
>>> package [1]  is missing in maven-javadoc-plugin configuration [2].
>>> 
>>> 
>>> We have Javadoc Suite [3] but it not checks such issues due to
>>> `javadoc` maven profile required to be enabled.
>>> Should we enable `javadoc` profile for this suite?
>>> Any other thoughts?
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-12259
>>> [2] https://issues.apache.org/jira/browse/IGNITE-12528
>>> [3] 
>>> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
>> 
>> 
>> 
>> --
>> Best regards,
>> Ivan Pavlukhin
> 
> 
> 
> -- 
> Best regards,
> Ivan Pavlukhin

[jira] [Created] (IGNITE-12574) Fix failing IoStatisticsBasicIndexSelfTest

[Ivan Pavlukhin (Jira)]

Ivan Pavlukhin created IGNITE-12574:
---

 Summary: Fix failing IoStatisticsBasicIndexSelfTest
 Key: IGNITE-12574
 URL: https://issues.apache.org/jira/browse/IGNITE-12574
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Ivan Pavlukhin
Assignee: Ivan Pavlukhin
 Fix For: 2.9


Need to move 
org.apache.ignite.internal.processors.cache.index.IoStatisticsBasicIndexSelfTest
 into a test suite with enabled persistence.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[DISCUSS] When can we drop IndexingSpi?

[Ivan Pavlukhin]

Hi,

As you might know IndexingSpi is a candidate for removal in Ignite
3.0. But perhaps we can drop it earlier (e.g. in 2.9). Are there any
strong reasons to keep it? And is there an evidence that it works fine
in current versions? Does someone use it?

My personal concern here are complexities in GridCacheQueryManager and
related code. While working with text queries I found tightly coupled
and semi-dead code. Dropping IndexingSpi can significantly simplify a
refactoring here.

-- 
Best regards,
Ivan Pavlukhin

Re: [DISCUSS] ThreadGroup for IgniteThread

[Ivan Pavlukhin]

Alex,

> We can either remove it (not sure if this is a breaking public API change?)
> or create a separate thread group per Ignite instance and pass it to the
> constructor of IgniteThread (quite a lot of refactoring).

Recently there were a discussion about "magic stuff" in codebase. And
it seems that we should eliminate such stuff if there is no chance to
understand why is it needed.

I run TC after dropping special ThreadGroup and did not get any new
failures [1]. It can imagine that dedicated ThreadGroup has some sense
for application servers. But personally I would prefer to get rid of
that ThreadGroup. A more conservative approach is to use some flag
(system property) to control it.

[1] 
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/7297/head=Latest

вт, 21 янв. 2020 г. в 16:39, Alexey Goncharuk :
>
> Ivan,
>
> I cannot recall why exactly a separate thread group was needed. I guess the
> intention was to collect all threads related to Ignite to one group, but I
> see no practical use of that particular implementation.
>
> We can either remove it (not sure if this is a breaking public API change?)
> or create a separate thread group per Ignite instance and pass it to the
> constructor of IgniteThread (quite a lot of refactoring).
>
> вт, 21 янв. 2020 г. в 13:17, Ivan Pavlukhin :
>
> > Hi,
> >
> > As you might know, IgniteThread class captures calling ThreadGroup on
> > initialization (as IgniteThread.DFLT_GRP) and includes all new ignite
> > threads into this group. A user reported an issue [1] related to it.
> > And the root cause here is that captured DFLT_GRP is out of control of
> > IgniteThread class. Looks like a design fault. Consequently several
> > unclear points:
> > 1. What is the real need for IgniteThread.DFLT_GRP?
> > 2. Can we simply stop using this trick?
> > 3. Could there be any better options to do the same?
> >
> > Please share your thoughts.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12554
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >



-- 
Best regards,
Ivan Pavlukhin

Re: JAVADOC fails on local build. Should it be checked on TC?

[Ivan Pavlukhin]

Maxim,

I suppose we can try to enable "javadoc" profile for a corresponding
job. Are there any objections to do so?

пн, 20 янв. 2020 г. в 13:25, Ivan Pavlukhin :
>
> Maxim,
>
> From the first glance it seems that "javadoc" profile was really
> missed. Are there any other problems except springdata22? If no then
> we can add the profile. Also it is interesting how it influence on
> execution time?
>
> пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
> >
> > Igniters,
> >
> >
> > I've run locally maven command according to DEVNOTES:
> >
> > mvn initialize -Pjavadoc
> >
> > and it fails due to: 'Other Packages' section should not be present,
> > all packages should have corresponding documentation groups. The
> > reason of that is a newly added `org.apache.ignite.springdata22`
> > package [1]  is missing in maven-javadoc-plugin configuration [2].
> >
> >
> > We have Javadoc Suite [3] but it not checks such issues due to
> > `javadoc` maven profile required to be enabled.
> > Should we enable `javadoc` profile for this suite?
> > Any other thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12259
> > [2] https://issues.apache.org/jira/browse/IGNITE-12528
> > [3] 
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
>
>
>
> --
> Best regards,
> Ivan Pavlukhin



-- 
Best regards,
Ivan Pavlukhin