RE: 2.8.1 : CacheEntryProcessor for insert/update within Transaction supported ?

Hi Anton, Thanks for the reply . As per the definition of entry processor - it is used to execute updates on entries on the nodes that store it - currently this is not the case. It runs on the client side as well.  Will this issue not be resolved if the entry processor ran only on the

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

HI Alexey, Thank you for the response, The below are the details from our Linux env. test : The log files from the test are attached here :

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi all, Continuation of this post ( Page 1 : http://apache-ignite-users.70518.x6.nabble.com/2-8-1-INFO-org-apache-ignite-spi-communication-tcp-TcpCommunicationSpi-Accepted-incoming-communicatin-td33854.html Page 2 :

Re: Too many TCP discovery accepted incoming connections

Hi Ilya, I was wondering if it was a case of Node1 trying to connect to the old node id of Node2 , but the Node2 has got a new node id since it was last connected. ( That is the issue we faced in that link shared ) . Maybe that is not what is happening here. Please ignore if so, regards,

Re: Too many TCP discovery accepted incoming connections

Hi Ilya, Could the issue be as mentioned here : http://apache-ignite-users.70518.x6.nabble.com/2-8-1-INFO-org-apache-ignite-spi-communication-tcp-TcpCommunicationSpi-Accepted-incoming-communicatin-tp33854p35224.html regards, Veena. -- Sent from:

2.8.1 : CacheEntryProcessor for insert/update within Transaction supported ?

Hi Team, Is the functionality to use CacheEntryProcessor for insert/update within Transaction supported ? As mentioned in this post, insert of a record using cacheentryprocessor always fails with UnregisteredBinaryTypeException if the insert is done within a transaction :

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hello all, Please guide me on the right way to use cacheentryprocessor within a transaction to update cache records . As shown in the example above, insert of a new record always throws UnregisteredBinaryTypeException - unless a metadata is registered on the client side before starting the

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hello, Did anyone get a chance to look at this ? Also I noticed that I can skip the execution of the entry processor if it is executing on the client side ( could pass a variable that identifies where it runs ) . i.e. at the start of the entry processor put something like public Object

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hi Anton, Did you get a chance to look at this ? regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hi Anton, Please find a sample project with one of the 'unregisteredbinarytypeexception' . The readme.txt is present in the attached zip. TestProject.zip As mentioned in the readme.txt , the behaviour noticed is as

Re: Ignite PME query

Hi Kamlesh, PME related questions have been answered in this forum earlier as well. Maybe if you search for these, you might get some of your questions answered. regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hi Anton, >>I read somewhere that this exception happens if registering metadata happens while the topology is locked. Could you kindly help me understand this exception. Also what is the right way to handle any runtimeexception within the entry processor ? Is it by wrapping it with an

Re: Right Handling of UnRegisteredBinaryObjectTypeException

Hi Anton , Thank you for the reply, We sync tables/caches in from a source db. i.e. we read all the records of a table and insert/update records into the table/cache in ignite. When the sync application runs just for a single table - we dont see the unregisteredbinarytypeexception . When we

Right Handling of UnRegisteredBinaryObjectTypeException

Hello Team Our configuration is as follows : Ignite Version : 2.8.1 Server nodes : 3 Native Persistence : yes Cache Mode : Replicated Write Sync Mode : FULL_SYNC Updates/Inserts : Through entry processor . No. of caches : ~ 30 No. of records per cache : ~30k Our entry processor code looks

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes and UnregisteredBinaryTypeExceptio

On further debugging, it looks like all the clients that had failed the count, were executing their query on the same server machinename002. When I looked at the server logs, it looks like that the records that were missing were not present on this server when the query was executed but were

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi Andrei, Did you get a chance to look at my comments . Regarding doing the continuous query as per this example : https://github.com/gridgain/gridgain/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheContinuousQueryExample.java Our code is pretty much as shown in

Re: Regarding Connection timed out observed during client startup

Hi Ilya, >>Generally a reducer node will need to connect to all map nodes while doing SQL query. >>You will not see this message if connection was already up. *Here are examples of 'outgoing communication' when the count was incorrect : *Example 1 : 2021-01-15T17:04:35,905 INFO

Re: Regarding Connection timed out observed during client startup

Hi Ilya, >>I don't think it could have affected CQ initial query, since queries/cache operations are supposed to block until they are successful, but not fail silently. I have another observation related to this

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

HI Andrei, Some more points : 1. Also the javadocs for the querycursor says : https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/QueryCursor.html#getAll-- List getAll() Gets all query results and stores them in the collection. Use this method when you know in

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi Andrei, Also as I said it is a trimmed down version of the actual code. In the actual code, the cursor is taken into a instance variable and closed. Made modifications accordingly to the client class . Please find the same attached, InitialQueryProject-1.zip

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Alexey, Please find the debug logs attached. This log "Client creation failed" is present in server2.log regards, Veena. serverlogs.zip -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Sure. Let me get back on this. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi Andrei, >>From your source code, I can see that the QueryCursor was created inside startContinuousQuery. Then you return it from that method, but don't store it in any variable:

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Alexey, I am able to reproduce this on my linux env. by doing a kill -9 . Please find the logs from my linux env. attached. temp.log Also note in our linux env. we have dual ip for our boxes - not sure if that contributes

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Unfortunately , will be difficult to try this - since we are working from home and are connected to office network through citrix . -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Regarding Connection timed out observed during client startup

>>It's possible that you have more than one network/interface and some combinations are causing problems. Please try to specify localHost property on every node pointing to a current actual external IP address of the node. This does seem to help the points 1,2,3,4. Do you think this could have

Re: Regarding Connection timed out observed during client startup

Thanks Ilya, I will check if adding localhost improves the issue mentioned in point 1, 2, 3 , 4. Could you guide on point 5,6 , regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi Andrei, Please find a trimmed down version of the code attached. Have a look at the ContinuousQueryHelper -> setInitialQuery to check how the initial query has been coded. regards, Veena. InitialQueryProject.zip

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

HI Andrei, The initial query(sql query) is failing, not the continuous update. Also so far we have had no issues in the initial query.. ( for the past 1 year or so ). I can share a reproducer if that will help, regards, Veena. -- Sent from:

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi , It happened a couple of times on Friday ( 15th ) . Today I started a dummy client with a continuous query against the same client multiple times against the same cluster - and I am not able to reproduce it. This cache contains 58 records , and I see all the 58 records being recorded in the

Re: 2.8.1 : Continuous Query Initial query not returning any result sometimes

No . Its a SQL query. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

The reproducer code works fine on my home mac ( I dont see the 100s of logs) - so not sure if the issue is because of a. Change in OS - at home I use mac and office it is windows/linux. b. Change in the network ( between my home and office ) Any thoughts on how I can debug further ? -- Sent

2.8.1 : Continuous Query Initial query not returning any result sometimes

Hi Team, Our env : Servers : 3 Cache Configuration : REPLICATED In one of our clients, the continuous query - Initial query did not return any result during client start whereas it was expected to return a single row. This happened for about 3-4 times over a period of 2 hours. It did return the

Regarding Connection timed out observed during client startup

Hello, We see this behaviour in our client startup : Client 1 - Client1.txt Server003 log - SERVER3.TXT 1. The client join the cluster around

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Ilya, Please find the video recording of the issue I face. https://drive.google.com/file/d/1fDqxmgjiL3o_eenHoUosdiYlMMBJ4xVj/view?usp=sharing regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Client stuck on startup

Let me debug this a bit more. Also I will try and capture another set of thread dumps when this occurs again. This issue occurs on my windows machine sometimes - doesnt happen all the time. I have not seen this on my linux env. yet. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Client stuck on startup

I dont think the server dumps were taken after the client disconnected . They were taken when the client was in the stuck state. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Kindly confirm the below : a. Are you on :2.8.1 b. Is this cod uncommented : ignite.active(true); addPersistentCacheConfiguration( ignite); c. using both server and client on the reproducer? I get this on all env. ( even in our linux env. ) -- Sent from:

Re: Client stuck on startup

Hello, Thread dump from the server nodes has been provided in the original post, regards, Veena -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Client stuck on startup

a. If you see the thread dump, it shows these locked synchronizers Locked ownable synchronizers: - <0x0006da73f540> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) - <0x0006da73f690> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

Re: Client stuck on startup

Okay, thanks Ilya . After it gets this issue, the app doesnt startup till I restart my server nodes. Is there anyway I can ensure clean shutdown when I face issues like this ? It looks like some ignite state is not cleaned up . regards, Veena. -- Sent from:

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

This issue is also observed if two different clients exist on the same box. Steps to reproduce : 1. Both the clients are not running 2. Start the client1 3. Stop the client 1 and start client 2 . 4. The huge set of logs are visible on client 2 logs. regards, Veena. -- Sent from:

Explicit Communication / Discovery port configuration on the client side needed ?

Hi , 1. If we deploy more than one client on same machine - should we explicitly configure communication and discovery port for the client i.e. should we do the below : 2. The localPortRange for communicationport and discovery port is 100 . Why is this

Re: Client stuck on startup

>>Try to use some realistic value such as 64. I think it hadnt worked earlier - I will try again. client-log.txt Please find the client log file attached. I am seeing 'invoking shutdown hook..' as an INFO in the startup

Re: Client stuck on startup

This client is a sync which syncs around 1 million records from our old db to ignite . When I start the application, it runs the initial sync and I need a higher striped pool. I think the client sees starvation in striped thread pool when I give a small thread pool. ( I dont have the logs for

Client stuck on startup

HI , One of the clients on my windows box sometimes gets stuck up on startup . I see this in the thread dump of the client. a. Not sure what those locked synchronizers are "main" #1 prio=5 os_prio=0 tid=0x02c9c800 nid=0x4404 waiting on condition [0x02c8e000]

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Ilya, Did you get a chance to look in to this ..? regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Ilya, Please find the reproducer project attached. Steps to reproduce : 1. Run the server.java 2. Run the ListenerClient.java. Wait till it starts fully. 3. Stop and start the client again ( within the failuredetectiontimeout of 10 secs. ) You will see these logs on the console. Another

Re: Regarding Partition Map exchange Triggers

Hi Ilya, thank you ! regards, Veena -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Regarding Partition Map exchange Triggers

>>Looking at your stack traces it seems that the cache you accessed in the SQL query was stopped right before the new client node is joined. >>All topology events are processed one-by-one, so the initial blocking time was caused by cache stop PME rather than client node join. What is the

Re: Regarding Partition Map exchange Triggers

HI Pavel, Thank you for the reply. >>> *for the end user , is this invoked when we do ignite.getOrCreate( xx ) and ignite.cache(xx )* >>Yes. getOrCreateCache would create a cache if doesnt exist . I would guess this would have the effect of starting the cache if doesnt exist . And I think

Regarding Partition Map exchange Triggers

Hi , I can see the triggers for PME initiation here : https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood Triggers Events which causes exchange Topology events: Node Join (EVT_NODE_JOINED) - new node discovered and joined topology (exchange is done

Re: Unable to free disk space after keys are removed in ignite 2.7.0

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

Re: Unable to free disk space after keys are removed in ignite 2.7.0

Hi Ilya, I have a question related to this : >>Then, WAL will usually only grow and db/ will grow too, they will not shrink from the deletion of data from caches. Dropping a cache will free space. >>This is tolerable because modern server instances are usually single-purpose. You expect an

Regarding Partition Map exchange Triggers

Hi , I can see the triggers for PME initiation here : https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood Triggers Events which causes exchange Topology events: Node Join (EVT_NODE_JOINED) - new node discovered and joined topology (exchange is done

Regarding partition map exchange triggers

Hi , I can see the triggers for PME initiation here : https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood Triggers Events which causes exchange Topology events: Node Join (EVT_NODE_JOINED) - new node discovered and joined topology (exchange is

Regarding partition map exchange triggers

Hi , I can see the triggers for PME initiation here : https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood Triggers Events which causes exchange Topology events: Node Join (EVT_NODE_JOINED) - new node discovered and joined topology (exchange is

Regarding long running transaction

Hi , I see this in my transaction log : 2020-12-10T07:32:59,525 WARN o.a.i.i.diagnostic [grid-timeout-worker-#1035%config-sync-GREEN-igniteclient-SINGLE%]: First 10 long running transactions [total=1] 2020-12-10T07:32:59,525 WARN o.a.i.i.diagnostic

Re: IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Thank you for the suggestions. I will try the timeout settings. It looks like the server has connected to the client on the new client id using the discovery SPI but it is trying to send the cache update to the old client id using the communication SPI. What impact does the IgniteAsyncCallback

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

Hi Ilya, This is easy to reproduce. Have a server node and a client node in a cluster. Stop and start the client immediately so that the start happens within the failure detection timeout ( 10 sec typically ). You will see these messages in the client log as it is starting up the second time.

Re: IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Hi Ilya, The node communication issue is because one of the node is being restarted - and not due to network failure . The original issue is as below : Our setup :Servers - 3 node clusterReader clients : wait for an update on an entry of a cache ( around 20 ofthem )Writer Client : 1If one of the

Re: IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Hi Ilya, The node communication issue is because one of the node is being restarted - and not due to network failure . The original issue is as below : Our setup : Servers - 3 node cluster Reader clients : wait for an update on an entry of a cache ( around 20 of them ) Writer Client : 1 If

Re: Continuous query not transactional ?

Hi Ilya, That is what I assume too, could someone from the developers community help confirm/comment on this ? regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Continuous query not transactional ?

Hi , This is in continuation of the below statement on this post : http://apache-ignite-users.70518.x6.nabble.com/Lag-before-records-are-visible-after-transaction-commit-tp33787p33861.html >>Continuous Query itself is not transactional and it looks like it can't be used for this at the moment.

Re: Lag before records are visible after transaction commit

Hi , >>Continuous Query itself is not transactional and it looks like it can't be used for this at the moment. So, it gets notification before other entries were committed. Does this mean we could get dirty reads as updates in continuous query ? i.e. for eg if the code is as below: 1. Start

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Thanks Ilya, >>I don't think so. Node can reconnect to a *different* cluster, or it may be disconnected for a while and return to the same cluster. For client node, segmented/disconnected difference is not relevant. Neither it is for server node, in fact. In that case, we will have the same

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Thanks Ilya, >>I don't think so. Node can reconnect to a *different* cluster, or it may be disconnected for a while and return to the same cluster. For client node, segmented/disconnected difference is not relevant. Neither it is for server node, in fact. In that case, we will have the same

Re: IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Hi Team, Kindly awaiting a reply on this one, regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi Team, In terms of the client, do we need to have the below 2 EVENT handlers? : 1. EVT_NODE_SEGMENTED - to restart the node and deploy and continuous queries if needed. 2. EVT_CLIENT_NODE_RECONNECTED - to just deploy the continuous queries ( no restart of ignite needed, since the node is

IgniteSpiOperationTimeoutException: Operation timed out [timeoutStrategy= ExponentialBackoffTimeoutStrategy

Hi , Our setup : Servers - 3 node cluster Reader clients : wait for an update on an entry of a cache ( around 20 of them ) Writer Client : 1 If one of the reader client restarts while the writer is writing into the entry of the cache , the server attempts to send the update to the failed

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi Anton, Thank you for the reply . >>I can confirm that there is no SEGMENTED event thrown on 2.8.1. I guess you meant that there is no SEGMENTED event thrown in 2.8.1 client when the servers are brought down and started again. Because SEGMENTED event could be thrown in 2.8.1 in other

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi Anton, Thank you for the reply . >>I can confirm that there is no SEGMENTED event thrown on 2.8.1. I guess you meant that there is no SEGMENTED event thrown in 2.8.1 client when the servers are brought down and started again. Because SEGMENTED event could be thrown in 2.8.1 in other

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi , Kindly awaiting a reply on this , regards, Veena -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite thread pool configuration

Thanks Denis, regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite thread pool configuration

Thanks Denis, I am thinking of setting the below thread pools as this on both client and server since we dont use data streamer, IGFS or Peer Class loading: Also our thick clients dont connect using REST . So thinking of adding the below configuration on our thick

Re: Ignite thread pool configuration

I noticed that the DataStreamer thread pool size seems to be around 32 in my local machine. In our cluster setup we dont stream data from any external db . We use native persistence. Do you think it makes sense to reduce this pool size for both server and client configuraiton. I am not sure if

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

I rechecked this. My cluster setup is : servers : 3 client : 1 Bring down all nodes in the cluster for about 2 mins ( failuredetectiontimeout is 10 seconds ). The client receives EVT_NODE_RECONNECTED and does not receive EVT_NODE_SEGMENTED. -- Sent from:

Re: 2.8.1 : MutableEntry.getValue().toBuilder throws NullPointerException

I have observed it on a subset of caches . We do not have assertions enabled. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Webinar: Apache Ignite Management & Monitoring

Hi , I am trying to configure cluster in my machine with the control center agent to understand it. The servers are started using java so I tried to add the maven dependency or add the library as a external dependency to the project as mentioned in these slides

2.8.1 : MutableEntry.getValue().toBuilder throws NullPointerException

Hello, In some rare scenarios , we get this exception when we update records . java.lang.NullPointerException: null at org.apache.ignite.internal.binary.builder.BinaryBuilderReader.(BinaryBuilderReader.java:72) ~[ignite-core-2.8.1.jar:2.8.1] at

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi Team, Kindly awaiting a reply on this, regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : INFO org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi [] - Accepted incoming communication connection

HI Anton, The setup I am working on is as below : server nodes : 3 client : 1 I get these logs when I start the client node within 10 secs of stopping it. There is no clue on the server nodes as to why these logs are printed. It looks as if the client node that was killed, is trying to join

Re: 2.8.1 : Server cluster node startup issue

Thanks Alex, Will try and see if I can create a reproducer. >>If Ignite hasn't fully started, it will wait( U.awaitQuiet(startLatch); ) until it has, before returning the instance. Does the Ignition.start wait for the storage spi to return from record, to start ? since the storage spi is waiting

Re: 2.8.1 : Server cluster node startup issue

Hi Alex, 1. How is the storage spi record method getting invoked on this node if the ignite has not even fully started on this node ? Which ignite instance is it using to invoke the record method ? I have enabled only these events :

2.8.1 : Server cluster node startup issue

Hello, Our set up : Server nodes : 3 Writer application : 1 A event storage spi that writes the cache_put events that have been generated due to a dbeaver update into a ignite cache. We restarted one of the servers yesterday during regular business hours and noticed that the server was not

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

HI , Raised a Documentation Improvement jira : IGNITE-13356 Documentation Change needed: PluginProvider loading changed from 2.8.1 regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

Hi Ilya, I have used the new style. It will also mean that this document is no longer the best way to load the plugin provider: https://apacheignite.readme.io/docs/plugins And this might need a documentation update. regards, Veena. -- Sent from:

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hi Anton, There are a few thoughts on this : 1. I found this issue after I upgraded from 2.7.6 to 2.8.1 ( No timeout values etc has been changed in our application ). So for the same scenario and the same application configuration a. in 2.7.6 , the client receives a evt_node_segmented b. in

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

Okay. If I set pluginconfiguration using setPluginConfiguration, how do I get it in the plugins ? getPluginConfigurations is deprecated in 2.8.1. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

HI Anton, Checked again -In 2.8.1 it receives the EVT_NODE_RECONNECTED with a new node id . It receives Eventtype 17 ( EVT_NODE_RECONNECTED ) and not Eventtype 14 ( EVT_NODE_SEGMENTED ) . Also it connects with a new node id. Please find the log with relevant parts highlighted. 2020-07-31

2.8.1 : EVT_NODE_RECONNECTED, EVT_NODE_SEGMENTED on the client side

Hello, When do EVT_NODE_SEGMENTED event get generated on the client side in 2.8.1 ? I noticed that in 2.7.6 , when all the servers are restarted and the client reconnects again with a new node id - it used to receive a EVT_NODE_SEGMENTED . In 2.8.1 it receives EVT_NODE_RECONNECTED. Kindly

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

Okay. >> The recommended way is to use the service provider as detailed here: How do we pass configuration for the provider in this approach. regards, Veena. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: 2.8.1 - Loading Plugin Provider - Conflicting documentation

Thanks Alex, There seems to be two conflicting documentation on loading the plugin provider : 1. The first way as shown in this documentation https://apacheignite.readme.io/docs/plugins : uses the Java Service Loader to load the plugin provider . It loads the plugin configurations through the

2.8.1 : Ignite Security : Cache_Put event generated from a remote_client user action has subject uuid of Node that executes the request

Hi Team, 1. I noticed that this issue ( https://issues.apache.org/jira/browse/IGNITE-12781) is not resolved in 2.8.1. Could you guide how can we get audit information if a cache record modification is done on dbeaver and the cache_put event contains the node id instead of the remote_client

Re: 2.8.1 - Loading Plugin Provider

Hi Alex, Thanks for the reply, 1. I noticed that the ml plugin uses getPluginConfigurations which seems to have been deprecated.. https://github.com/apache/ignite/blob/master/modules/ml/src/main/java/org/apache/ignite/ml/util/plugin/MLPluginProvider.java Would that mean that the preferred way

2.8.1 - Loading Plugin Provider

Hi , I saw that 'SetPluginConfiguration' in IgniteConfiguration has been deprecated in 2.8.1: ( IgniteConfiguration javadoc : https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html ) *IgniteConfiguration

Re: Event for an update that should have been filtered is received in Local Listener of Continuous Query when a 1000 row insert is triggered

Hello, Looks like this issue is not related to load, but related to remote filter not getting redeployed when a server node is restarted on version 2.7.6. Related discussion at http://apache-ignite-users.70518.x6.nabble.com/Remote-Filter-Execution-td33274.html regards, Veena. -- Sent

Re: Remote Filter Execution

I can also confirm that both these issues happen consistently on 2.7.6. All the nodes are in baseline when both these issues happen. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Remote Filter Execution

Hi Ilya, I can confirm that both issues do not occur in 2.8.1. ( The remote filter evaluate executes only on 2 nodes as expected ..) Also the remote filter gets deployed whenever there is a server restart. The other thing for me to check is if we can use 2.8.1 ( We had issues on 2.8.0 jdbc thin

Re: Remote Filter Execution

HI Ilya, Did you use the reproducer project ? The CACHE configuration is PARTITIONED with ONE BACKUP. So should the remote filter evaluate method run on all the 3 nodes ? I would expect the evaluate method to run only 2 nodes I have not tried 2.8.1 yet. Will try and let you know. regards,

  1   2   >