[jira] [Created] (IGNITE-13128) IgniteLock throws NullPointerException when removed before use
Pavel Tupitsyn created IGNITE-13128:
---
Summary: IgniteLock throws NullPointerException when removed
before use
Key: IGNITE-13128
URL: https://issues.apache.org/jira/browse/IGNITE-13128
Project: Ignite
Issue Type: Bug
Components: data structures
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Fix For: 2.9
Reproducer:
{code:java}
public void testClosedLockThrowsIgniteException() {
final String lockName = "testRemovedLockThrowsIgniteException";
Ignite srv = ignite(0);
IgniteLock lock1 = srv.reentrantLock(lockName, false, false, true);
IgniteLock lock2 = srv.reentrantLock(lockName, false, false, true);
lock1.close();
lock2.lock();
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]
Hi folks, The timelines proposed by Alex Plekhanov sounds reasonable to me. I'd like only to hear inputs of @Ivan Rakov , who is about to finish with the tracing support, and @Ivan Bessonov , who is fixing a serious limitation for K8 deployments [1]. Most likely, both features will be ready by the code freeze date (July 10), but the guys should know it better. [1] http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html - Denis On Wed, Jun 3, 2020 at 4:45 AM Alex Plehanov wrote: > Hello Igniters, > > AI 2.8.1 is finally released and as we discussed here [1] its time to start > the discussion about 2.9 release. > > I want to propose myself to be the release manager of the 2.9 release. > > What about release time, I agree with Maxim that we should deliver features > as frequently as possible. If some feature doesn't fit into release dates > we should better include it into the next release and schedule the next > release earlier then postpone the current release. > > I propose the following dates for 2.9 release: > > Scope Freeze: June 26, 2020 > Code Freeze: July 10, 2020 > Voting Date: July 31, 2020 > Release Date: August 7, 2019 > > WDYT? > > [1] : > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575 >
Re: Continuous Queries with several remote filter on the same cache
Hi Roman, Every continuous query is a unique entity that is processed by servers independently. With your example, the server node will execute all 20 filters for every cache insert/update operation. The server will notify through local listeners only those clients whose remote filters returned 'true'. - Denis On Thu, Jun 4, 2020 at 8:44 PM wrote: > Hi Community, > > I ask this question here because I haven't found the answer in the > documentation. > > Could you please clarify how Continuous Queries work? What the behavior of > Continuous Queries if we have several clients with different Remote Filters > on the same cache? For example, if we have: one server node with cache and > we have up to 20 client nodes each of them will execute Continuous Query on > the same cache but with different Remote Filters. Will each client get the > data according to its remote filter? Or it is supposed to have only one > Remote Filter for all clients and every client should filter data in its > local event listener? > I would be grateful if you send some link which describes the behavior of > Continuous Queries more thoroughly. > Best regards, > Roman >
Re: Question: network issues of single node.
Finally, I got your question. Back in 2017-2018, there was a Discovery SPI's stabilization activity. The networking component could fail in various hard-to-reproduce scenarios affecting cluster availability and consistency. That ticket reminds me of those notorious issues that would fire once a week or month under specific configuration settings. So, I would not touch the code that fixes the issue unless @Alexey Goncharuk or @Sergey Chugunov confirms that it's safe to do. Also, there should be a test for this scenario. - Denis On Fri, Jun 5, 2020 at 12:28 AM Vladimir Steshin wrote: > Denis, > > I have no nodes that I'm unable to interconnect. This case is simulated > in IgniteDiscoveryMassiveNodeFailTest.testMassiveFailSelfKill() > Introduced in [1]. > > I’m asking if it is real or supposed problem. Where it was met? Which > network configuration/issues could be? > > > [1] https://issues.apache.org/jira/browse/IGNITE-7163 > > 05.06.2020 1:01, Denis Magda пишет: > > Vladimir, > > > > I'm suggesting to share the log files from the nodes that are unable to > > interconnect so that the community can check them for potential issues. > > Instead of sharing the logs from all the 5 nodes, try to start a > two-nodes > > cluster with the nodes that fail to discover each other and attach the > logs > > from those. > > > > - > > Denis > > > > > > On Thu, Jun 4, 2020 at 1:57 PM Vladimir Steshin > wrote: > > > >> Denis, hi. > >> > >> Sorry, I didn’t catch your idea. Are you saying this can happen > and > >> suggest experiment? I’m not descripting a probable case. It is already > >> done in [1]. I’m asking is it real, where it was met. > >> > >> > >> 04.06.2020 23:33, Denis Magda пишет: > >>> Vladimir, > >>> > >>> Please do the following experiment. Start a 2-nodes cluster booting > node > >> 3 > >>> and, for instance, node 5. Those won't be able to interconnect > according > >> to > >>> your description. Attach the log files from both nodes for analysis. > This > >>> should be a networking issue. > >>> > >>> - > >>> Denis > >>> > >>> > >>> On Thu, Jun 4, 2020 at 1:24 PM Vladimir Steshin > >> wrote: > Hi, Igniters. > > > I wanted to ask how one node may not be able to connect to > another > whereas rest of the cluster can. This got covered in [1]. In short: > node > 3 can't connect to nodes 4 and 5 but can to 1. At the same time, node > 2 > can connect to 4. Questions: > > 1) Is it real case? Where this problem came from? > > 2) If node 3 can’t connect to 4 and 5, does it mean node 2 can’t > connect > to 4 (and 5) too? > > Sergey, Dmitry maybe you bring light (I see you in [1])? I'm > participating in [2] and found this backward connection checking. > Answering would help us a lot. > > Thanks! > > [1] > https://issues.apache.org/jira/browse/IGNITE-7163< > https://issues.apache.org/jira/browse/IGNITE-7163> > > [2] > > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-45%3A+Crash+Recovery+Speed-Up > < > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-45%3A+Crash+Recovery+Speed-Up >
