Re: Ignite 2.8.1 ContinuousQuery: ClassNotFoundException on a client node

[Michael Cherkasov]

Hello Ivan,

Right now CQ deployed remote filter on all nodes, even on client nodes that
don't store any data and this doesn't make sense, I think Ignite should not
deploy it at all on non-affinity nodes. I filed a ticket for this:
https://issues.apache.org/jira/browse/IGNITE-13432

Regarding the warning, the CQ is already deployed, but if you will try to
deploy a new one while the client is online it will fail, just make sure
that you deploy all CQ while clients are offline or put a remote filter to
client nodes too, btw peer class loading can help with this.

Thanks,
Mike.
чт, 10 сент. 2020 г. в 10:14, :

> Hi everyone!
>
> I am getting ClassNotFoundException on a client node when a server node
> registers a new ContinuousQuery with a remote filter class that is not in
> the classpath of a client node. Could someone please clarify if this is the
> expected behavior and all the client nodes must have all remove filters in
> their classpath? I wonder if it is correct that client nodes are
> participating in continuous query execution at all?
>
> According to the ticket (
> https://issues.apache.org/jira/browse/IGNITE-11907) it looks like a
> client node can even break some functionality on a server node that tries
> to initialize a new continuous query.
>
> At the same time I see the following message when a new client node enters
> the topology:
>
> 55
> 10.09.20 18:55:00.407 [tcp-client-disco-msg-worker-#4]  WARN
> tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on
> client node. Can be ignored.
> 10.09.20 18:55:00.410 [tcp-client-disco-msg-worker-#4]  WARN
> tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on
> client node. Can be ignored.
>
> So in case when a new client node joins all the running queries continue
> to work as expected (at least it is written in the log).
>
> Best regards,
> Ivan Fedorenkov
>

Ignite 2.8.1 ContinuousQuery: ClassNotFoundException on a client node

[Ivan.Fedorenkov]

Hi everyone!

I am getting ClassNotFoundException on a client node when a server node 
registers a new ContinuousQuery with a remote filter class that is not in the 
classpath of a client node. Could someone please clarify if this is the 
expected behavior and all the client nodes must have all remove filters in 
their classpath? I wonder if it is correct that client nodes are participating 
in continuous query execution at all?

According to the ticket (https://issues.apache.org/jira/browse/IGNITE-11907) it 
looks like a client node can even break some functionality on a server node 
that tries to initialize a new continuous query.

At the same time I see the following message when a new client node enters the 
topology:

55
10.09.20 18:55:00.407 [tcp-client-disco-msg-worker-#4]  WARN 
tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on 
client node. Can be ignored.
10.09.20 18:55:00.410 [tcp-client-disco-msg-worker-#4]  WARN 
tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on 
client node. Can be ignored.

So in case when a new client node joins all the running queries continue to 
work as expected (at least it is written in the log).

Best regards,
Ivan Fedorenkov

Re: Preload all indexes to memory

[Dmitry Lazurkin]

Alexandr, thank you. I'll be in the loop.

On 10.09.2020 17:36, Alexandr Shapkin wrote:
> Hi,
>
> Looks like this is the part of the upcoming warmup feature [1] that should
> be published with the next Ignite release (2.10) or the upcoming GridGain
> edition (v8.7.26?) [2].
>
> Please, check the IEP-40 for the detailed explanation [3]
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-13345
> [2] -
> https://www.gridgain.com/docs/latest/release-notes/8.7.25/release-notes_8.7.25
> [3] -
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-40+Cache+warm-up
>
>
>
>
> -
> Alex Shapkin
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Preload all indexes to memory

[Alexandr Shapkin]

Hi,

Looks like this is the part of the upcoming warmup feature [1] that should
be published with the next Ignite release (2.10) or the upcoming GridGain
edition (v8.7.26?) [2].

Please, check the IEP-40 for the detailed explanation [3]

[1] - https://issues.apache.org/jira/browse/IGNITE-13345
[2] -
https://www.gridgain.com/docs/latest/release-notes/8.7.25/release-notes_8.7.25
[3] -
https://cwiki.apache.org/confluence/display/IGNITE/IEP-40+Cache+warm-up




-
Alex Shapkin
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Preload all indexes to memory

[Vladimir Pligin]

As far as know there's no such functionality at the moment.
The only way that comes to my mind is to try making a SQL query that scans
it.
For example if you created a index like that:

CREATE INDEX indexName ON tableName (field1, field2);
Then you can try to execute:

SELECT field1, field2 FROM tableName USE INDEX(indexName);

By the way I suppose it's going to be possible soon, have a look at
https://cwiki.apache.org/confluence/display/IGNITE/IEP-40+Cache+warm-up



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

RE: ClusterGroupEmptyException: Topology projection is empty.

[kay]

Hello,

I don't use Visor for cluster monitoring.. then Why that log is showing
up..?


Thank you so much!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Unable to read fields value from BinaryObject

[Alexandr Shapkin]

Hi,

Yes, I can reproduce the behavior. It could be an issue with the custom
binary mappers. 

The weird thing is that the CustomBinaryIdMapper works fine with a single
node, i.e. if it reads and writes the value from a cache, then the mapper is
working. But fails on the other node.

Meanwhile, it's quite interesting, why do you want to replace the default
mapper with a custom one? What tasks are you trying to solve?



-
Alex Shapkin
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

DC replication via Kafka Connect for Apache Ignite

[adipro]

We are trying to implement the replication of data between two Ignite data
clusters.

For this purpose, we are using Kafka Connect.

We have followed the things mentioned in this document ->
https://dzone.com/articles/linking-apache-ignite-and-apache-kafka-for-highly

Everything is working fine till we use one cache and PUT operation.

But when I use the same for REMOVED operation, in the consumer thread of the
connector, I can see the CacheEvent record, but the data is not being
removed from the Sink Cluster nodes.

When checked the remove functionality is missing in IgniteSinkTask class.

Is IgniteSink connector only for injecting data? The data record type at
receiving end is of type CacheEvent. Based on operation it should put or
remove right? As of now only PUT is working.

Can someone please help with this case?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite NPE when try to loadCache from persistent mysql database

[Alexandr Shapkin]

Hi,

Is it possible to share a simple reproducer or to get the full logs from the
failed node?




-
Alex Shapkin
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: [Webinar] Networking in Apache Ignite - Talk at Sep 9 2020

[Kseniya Romanova]

Hi all! If you missed the webinar, you can watch the recording here:
https://youtu.be/QheK3riWVqk

ср, 9 сент. 2020 г. в 12:07, Stanislav Lukyanov :

> Hi Igniters,
>
> I'll be giving a webinar titled Networking in Apache Ignite. We'll look at
> Apache Ignite's networking components - Discovery and Communication - to
> see how they work together to implement various networking functions.
> The webinar will be held at 10 AM PT / 1 PM ET / 5 PM GMT. Details are
> here
> https://www.gridgain.com/resources/webinars/how-apache-ignite-achieves-performance-and-fault-tolerance-its-network
> .
>
> Will be glad to see you there!
>
> Stan

Re: "When you should not use Apache Ignite", 8 Sept, Online

[Kseniya Romanova]

Hi! Here are the links:

Video: https://youtu.be/7UjENQBFvIQ
Slides:
https://go.gridgain.com/rs/491-TWR-806/images/EPAM_AIMeetup_When_you_should_note_use_Apache_Ignite.pdf


Join Virtual Meetup not to miss the next Ignite talks! September 15 visit
the Community Gathering and learn more about planned changes in Ignite 3.0
https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272675408/

вс, 6 сент. 2020 г. в 21:26, Dmitriy Pavlov :

> Dear Apache Ignite community members,
>
> We are all subscribed to this list because we are interested in Apache
> Ignite.  I participated in its development, and now I have the honor of
> serving as VP, Apache Ignite (PMC chair).
>
> It is quite natural to share only the benefits and strengths of your
> solution, avoiding limitations. As a technical guy, I understand that this
> is not really possible to create a limitless product that fits every
> imaginable case.
>
> And on September 8, 2020, I'll give a talk about cases when Apache Ignite
> won't suit your needs, cases in which it is better to take something else.
> Join the Apache Ignite Virtual meetup on September 8th, join to get the
> zoom link and chat after the talk.
>
> https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/272551117/
>
> Hope to see you soon.
> Have an awesome week,
> Dmitriy Pavlov
>

Re: Lag before records are visible after transaction commit

[ssansoy]

unfortunately the 's' on B here can't be derived from a number 0..n - e.g. it
isn't a numeric id.

E.g. in practice lets say:

A is a "Location"
it has properties: "city", "street" etc

B is a "Person" with key:
p = city
q = street
r = social security number

E.g. an A and associated B's are updated in a transaction, we want our
client app to see the updated A and B's where the Person lives at that that
Location.

E.g. A is updated and our continuous query on A picks up:
city = London
street = Downing Street

We would like to say:
Select * from B where city="London" and street="Downing Street"

Is there any way at all in Ignite to do this transactionally, so if an A and
associated B's are updated in one transaction (e.g. a street is renamed from
"Downing Street" to "Regent Street"), then our client app can see them
consistently?







--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/