[jira] [Resolved] (IGNITE-15110) Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
[
https://issues.apache.org/jira/browse/IGNITE-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-15110.
Resolution: Duplicate
> Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
> --
>
> Key: IGNITE-15110
> URL: https://issues.apache.org/jira/browse/IGNITE-15110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Function CHAR_LENGTH returns an incorrect results for unicode symbols. E.g
> for below query returns 2 instead of 1
> {code:sql}
> SELECT char_length('閭'){code}
> see src/test/sql/function/string/test_char_length.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Description: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h2. Possible approaches h3. Remote validation The entering node sends some metadata (e.g. its version) to a random remote node, which validates the metadata and issues the permit for the node to join. *Pros:* * ??? *Cons:* * Harder to maintain backwards compatibility: old nodes need to predict what information a new node might send. h3. Local validation The entering node collects some metadata from a random remote node and decides whether it is able to join the cluster or not. *Pros:* * Easier to maintain backwards-compatibility: a new node knows if older nodes are compatible with it. * Modular validation architecture: each plugin can independently register its requirements. *Cons:* * Possible security issues: a malicious node can enter the cluster more easily. However, this may be mitigated by signing the handshake messages. was: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h2. Possible approaches h3. Remote validation The entering node sends some metadata (e.g. its version) to a random remote node, which validates the metadata and issues the permit for the node to join. *Pros:* * Easier to maintain backwards-compatibility (useful for the rolling upgrade feature). *Cons:* * What if a remote node is also older than other nodes? It might be possible that a chain of increasingly older nodes might break the cluster invariants. h3. Local validation The entering node collects some metadata from a random remote node and decides whether it is able to join the cluster or not. *Pros:* * ??? *Cons:* * Difficult to maintain backwards-compatibility: an old node should be able to predict what information might be sent by the newer remote nodes. * Possible security issues: a malicious node can enter the cluster more easily than when using the remote validation. However, this may be mitigated by signing the handshake messages. > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node enters the cluster, its configuration needs to be validated in > order to maintain cluster-wide invariants and to prohibit a non-compatible or > malicious node from entering the topology. > h2. Possible approaches > h3. Remote validation > The entering node sends some metadata (e.g. its version) to a random remote > node, which validates the metadata and issues the permit for the node to join. > *Pros:* > * ??? > *Cons:* > * Harder to maintain backwards compatibility: old nodes need to predict what > information a new node might send. > h3. Local validation > The entering node collects some metadata from a random remote node and > decides whether it is able to join the cluster or not. > *Pros:* > * Easier to maintain backwards-compatibility: a new node knows if older > nodes are compatible with it. > * Modular validation architecture: each plugin can independently register > its requirements. > *Cons:* > * Possible security issues: a malicious node can enter the cluster more > easily. However, this may be mitigated by signing the handshake messages. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov resolved IGNITE-12749.
-
Resolution: Duplicate
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[
https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379298#comment-17379298
]
Ignite TC Bot commented on IGNITE-15105:
{panel:title=Branch: [pull/9247/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9247/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6083132]]
* {color:#013220}IgnitePdsTestSuite4:
ToStringDumpHelperTest.toStringSharedPageLockTrackerTest - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6083159buildTypeId=IgniteTests24Java8_RunAll]
> Reduce number of messages for "Blocked system-critical thread" errors
> -
>
> Key: IGNITE-15105
> URL: https://issues.apache.org/jira/browse/IGNITE-15105
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.12
>
>
> Now, we're printing a lot of messages for these errors, each of them has
> thousands of lines, because it prints locks and/or threads. It overwrites
> everything else in logs and makes troubleshooting impossible.
> This behavior was analyzed on 2.8.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Ignite Flags: (was: Docs Required,Release Notes Required) > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node enters the cluster, its configuration needs to be validated in > order to maintain cluster-wide invariants and to prohibit a non-compatible or > malicious node from entering the topology. > h2. Possible approaches > h3. Remote validation > The entering node sends some metadata (e.g. its version) to a random remote > node, which validates the metadata and issues the permit for the node to join. > *Pros:* > * Easier to maintain backwards-compatibility (useful for the rolling upgrade > feature). > *Cons:* > * What if a remote node is also older than other nodes? It might be possible > that a chain of increasingly older nodes might break the cluster invariants. > h3. Local validation > The entering node collects some metadata from a random remote node and > decides whether it is able to join the cluster or not. > *Pros:* > * ??? > *Cons:* > * Difficult to maintain backwards-compatibility: an old node should be able > to predict what information might be sent by the newer remote nodes. > * Possible security issues: a malicious node can enter the cluster more > easily than when using the remote validation. However, this may be mitigated > by signing the handshake messages. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Ignite Flags: (was: Docs Required,Release Notes Required) > IP Finder API > - > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Anton Kalashnikov >Priority: Major > Labels: ignite-3 > > Create a service interface that provides the initial set of addresses of > cluster members to a joining node. This service should provide an abstraction > over multiple possible configuration mechanisms, like manual static > configuration, Kubernetes service discovery, cloud environment, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15115) Static IP Finder
[ https://issues.apache.org/jira/browse/IGNITE-15115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15115: - Labels: ignite-3 (was: ) > Static IP Finder > > > Key: IGNITE-15115 > URL: https://issues.apache.org/jira/browse/IGNITE-15115 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > Create an IP Finder implementation that returns a predefined list of > addresses (e.g. provided by the bootstrap configuration). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15115) Static IP Finder
Aleksandr Polovtcev created IGNITE-15115: Summary: Static IP Finder Key: IGNITE-15115 URL: https://issues.apache.org/jira/browse/IGNITE-15115 Project: Ignite Issue Type: Task Components: networking Reporter: Aleksandr Polovtcev Create an IP Finder implementation that returns a predefined list of addresses (e.g. provided by the bootstrap configuration). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Description: Create a service interface that provides the initial set of addresses of cluster members to a joining node. This service should provide an abstraction over multiple possible configuration mechanisms, like manual static configuration, Kubernetes service discovery, cloud environment, etc. (was: IP finder service is needed on a network level to allow nodes to find existing clusters and avoid excessive manual configuration. In some cases like cloud environments manual configuration of all cluster's nodes is impractical. Special implementation of IP Finder solves this problem. In this task we need to design IP Finder API suitable for different use-cases and develop a simplistic static implementation.) > IP Finder API > - > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Anton Kalashnikov >Priority: Major > Labels: ignite-3 > > Create a service interface that provides the initial set of addresses of > cluster members to a joining node. This service should provide an abstraction > over multiple possible configuration mechanisms, like manual static > configuration, Kubernetes service discovery, cloud environment, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Summary: IP Finder API (was: IP Finder API and first implementation to locate and join existing cluster) > IP Finder API > - > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Anton Kalashnikov >Priority: Major > Labels: ignite-3 > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Description: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h2. Possible approaches h3. Remote validation The entering node sends some metadata (e.g. its version) to a random remote node, which validates the metadata and issues the permit for the node to join. *Pros:* * Easier to maintain backwards-compatibility (useful for the rolling upgrade feature). *Cons:* * What if a remote node is also older than other nodes? It might be possible that a chain of increasingly older nodes might break the cluster invariants. h3. Local validation The entering node collects some metadata from a random remote node and decides whether it is able to join the cluster or not. *Pros:* * ??? *Cons:* * Difficult to maintain backwards-compatibility: an old node should be able to predict what information might be sent by the newer remote nodes. * Possible security issues: a malicious node can enter the cluster more easily than when using the remote validation. However, this may be mitigated by signing the handshake messages. was: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h3. Possible approaches > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node enters the cluster, its configuration needs to be validated in > order to maintain cluster-wide invariants and to prohibit a non-compatible or > malicious node from entering the topology. > h2. Possible approaches > h3. Remote validation > The entering node sends some metadata (e.g. its version) to a random remote > node, which validates the metadata and issues the permit for the node to join. > *Pros:* > * Easier to maintain backwards-compatibility (useful for the rolling upgrade > feature). > *Cons:* > * What if a remote node is also older than other nodes? It might be possible > that a chain of increasingly older nodes might break the cluster invariants. > h3. Local validation > The entering node collects some metadata from a random remote node and > decides whether it is able to join the cluster or not. > *Pros:* > * ??? > *Cons:* > * Difficult to maintain backwards-compatibility: an old node should be able > to predict what information might be sent by the newer remote nodes. > * Possible security issues: a malicious node can enter the cluster more > easily than when using the remote validation. However, this may be mitigated > by signing the handshake messages. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskSecurityContextTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication.
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication.
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestCertificateSecurityProcessor#secCtxs values to determine client subject id
after authentication.
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/**
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Description: When a node enters the cluster, its configuration needs to be validated in order to maintain cluster-wide invariants and to prohibit a non-compatible or malicious node from entering the topology. h3. Possible approaches > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node enters the cluster, its configuration needs to be validated in > order to maintain cluster-wide invariants and to prohibit a non-compatible or > malicious node from entering the topology. > h3. Possible approaches > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Implement a validation protocol for the nodes entering the topology
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Summary: Implement a validation protocol for the nodes entering the topology (was: Provide validation protocol for newly joining nodes.) > Implement a validation protocol for the nodes entering the topology > --- > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define a mechanism for exchanging discovery metadata
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Description: When a node joins a cluster it needs to send and receive some discovery metadata, for example: # A node might need to provide some credentials and/or some of its configuration values in order to be validated against the state of the cluster. # A node might need to obtain some information about the cluster when accepted into the topology, e.g. addresses of the nodes that host the metastorage. We should develop a mechanism for both sending and receiving some data before a node is accepted into the topology. was: When a node joins a cluster it needs to send and receive some discovery metadata, for example: # A node might need to provide some credentials and/or some of its configuration values in order to be validated against the state of the cluster. # A node might need to obtain some information about the cluster when accepted into the topology, e.g. addresses of the nodes that host the metastorage. > Define a mechanism for exchanging discovery metadata > > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node joins a cluster it needs to send and receive some discovery > metadata, for example: > # A node might need to provide some credentials and/or some of its > configuration values in order to be validated against the state of the > cluster. > # A node might need to obtain some information about the cluster when > accepted into the topology, e.g. addresses of the nodes that host the > metastorage. > We should develop a mechanism for both sending and receiving some data before > a node is accepted into the topology. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Component/s: networking > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Provide validation protocol for newly joining nodes.
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Component/s: networking > Provide validation protocol for newly joining nodes. > > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define a mechanism for exchanging discovery metadata
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Component/s: networking > Define a mechanism for exchanging discovery metadata > > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node joins a cluster it needs to send and receive some discovery > metadata, for example: > # A node might need to provide some credentials and/or some of its > configuration values in order to be validated against the state of the > cluster. > # A node might need to obtain some information about the cluster when > accepted into the topology, e.g. addresses of the nodes that host the > metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define a mechanism for exchanging discovery metadata
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Description: When a node joins a cluster it needs to send and receive some discovery metadata, for example: # A node might need to provide some credentials and/or some of its configuration values in order to be validated against the state of the cluster. # A node might need to obtain some information about the cluster when accepted into the topology, e.g. addresses of the nodes that host the metastorage. > Define a mechanism for exchanging discovery metadata > > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > When a node joins a cluster it needs to send and receive some discovery > metadata, for example: > # A node might need to provide some credentials and/or some of its > configuration values in order to be validated against the state of the > cluster. > # A node might need to obtain some information about the cluster when > accepted into the topology, e.g. addresses of the nodes that host the > metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Labels: ignite-3 (was: iep-66 ignite-3) > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Anton Kalashnikov >Priority: Major > Labels: ignite-3 > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define a mechanism for exchanging discovery metadata
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Summary: Define a mechanism for exchanging discovery metadata (was: Define mechanism for collecting and exchanging discovery data when joining a node) > Define a mechanism for exchanging discovery metadata > > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15114) Design and implement the process of a node joining a cluster
[ https://issues.apache.org/jira/browse/IGNITE-15114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15114: - Description: The target of this epic is to design and implement a protocol for a node to join a cluster and exchange some information before being either allowed or prohibited from entering the topology. > Design and implement the process of a node joining a cluster > > > Key: IGNITE-15114 > URL: https://issues.apache.org/jira/browse/IGNITE-15114 > Project: Ignite > Issue Type: Epic >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > The target of this epic is to design and implement a protocol for a node to > join a cluster and exchange some information before being either allowed or > prohibited from entering the topology. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14703) Add merge-sort reducer for cache queries.
[
https://issues.apache.org/jira/browse/IGNITE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379256#comment-17379256
]
Ignite TC Bot commented on IGNITE-14703:
{panel:title=Branch: [pull/9081/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9081/head] Base: [master] : New Tests
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=6083240]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=7] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=8] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=1] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=2] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=5] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=6] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=3] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryLimitTest.testResultOrderedByScore[nodesCnt=4] -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryPagesTest.testTextQueryHighLimitedMultiplePages -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryPagesTest.testTextQueryMultiplePagesNoLimit -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
GridCacheFullTextQueryPagesTest.testTextQueryLimitedMultiplePages -
PASSED{color}
... and 0 new tests
{color:#8b}Cache 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6083216]]
* {color:#013220}IgniteBinaryCacheTestSuite:
DataStorageConfigurationValidationTest.testSetWalSegmentSizeShouldBeOkWhenSizeBetween512KbAnd2Gb
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
DataStorageConfigurationValidationTest.testWalSegmentSizeOverflow -
PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
DataStorageConfigurationValidationTest.testSetWalSegmentSizeShouldThrowExceptionWhenSizeLessThen512Kb
- PASSED{color}
* {color:#013220}IgniteBinaryCacheTestSuite:
DataStorageConfigurationValidationTest.testSetWalSegmentsCountShouldThrowExceptionThenLessThan2
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6083261buildTypeId=IgniteTests24Java8_RunAll]
> Add merge-sort reducer for cache queries.
> -
>
> Key: IGNITE-14703
> URL: https://issues.apache.org/jira/browse/IGNITE-14703
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71
> Time Spent: 13h 50m
> Remaining Estimate: 0h
>
> MergeSort reducer is required for Index queries that should provide a sorted
> result for user.
>
> Note that text queries does not return sorted result, as lucene invoked
> without sort param. So this ticket is only for querying Btree indexes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Fix Version/s: (was: 3.0.0-alpha3) > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14092: - Parent: (was: IGNITE-14081) Issue Type: Task (was: Sub-task) > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14871) Provide validation protocol for newly joining nodes.
[ https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14871: - Parent: (was: IGNITE-14209) Issue Type: Task (was: Sub-task) > Provide validation protocol for newly joining nodes. > > > Key: IGNITE-14871 > URL: https://issues.apache.org/jira/browse/IGNITE-14871 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14870) Define mechanism for collecting and exchanging discovery data when joining a node
[ https://issues.apache.org/jira/browse/IGNITE-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14870: - Parent: (was: IGNITE-14209) Issue Type: Task (was: Sub-task) > Define mechanism for collecting and exchanging discovery data when joining a > node > - > > Key: IGNITE-14870 > URL: https://issues.apache.org/jira/browse/IGNITE-14870 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15114) Design and implement the process of a node joining a cluster
Aleksandr Polovtcev created IGNITE-15114: Summary: Design and implement the process of a node joining a cluster Key: IGNITE-15114 URL: https://issues.apache.org/jira/browse/IGNITE-15114 Project: Ignite Issue Type: Epic Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15113) CPP: Thin Client Compute
Alexandr Shapkin created IGNITE-15113: - Summary: CPP: Thin Client Compute Key: IGNITE-15113 URL: https://issues.apache.org/jira/browse/IGNITE-15113 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Alexandr Shapkin Add Compute to C++Thin Client. See IGNITE-12853. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379223#comment-17379223
]
Ivan Daschinsky edited comment on IGNITE-12749 at 7/12/21, 3:26 PM:
[~ilyak] +1. It seems that original ticket was created almost a year ago and I
suppose that [~antkr] already fixed it by recreating map.
was (Author: ivandasch):
[~ilyak] +1. I suppose that original ticket was created almost a year ago, I
suppose that [~antkr] already fixed it by recreating map.
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379223#comment-17379223
]
Ivan Daschinsky commented on IGNITE-12749:
--
[~ilyak] +1. I suppose that original ticket was created almost a year ago, I
suppose that [~antkr] already fixed it by recreating map.
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestCertificateSecurityProcessor#secCtxs values to determine client subject id
after authentication.
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
>
[jira] [Created] (IGNITE-15112) Calcite bug. Function TRUNCATE fails for NULL argument
Yury Gerzhedovich created IGNITE-15112:
--
Summary: Calcite bug. Function TRUNCATE fails for NULL argument
Key: IGNITE-15112
URL: https://issues.apache.org/jira/browse/IGNITE-15112
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
Function INITCAP fails for NULL argument
see src/test/sql/function/numeric/test_truncate.test_ignore
{code:sql}
SELECT truncate(null)
{code}
{code:java}
java.lang.RuntimeException: while resolving method 'valueOf[void]' in class
class java.lang.Voidjava.lang.RuntimeException: while resolving method
'valueOf[void]' in class class java.lang.Void
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318) at
org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:448) at
org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:460) at
org.apache.calcite.linq4j.tree.Expressions.box(Expressions.java:1424) at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:305)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:176)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:1963)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:1910)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:991)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:79)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:886)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:79)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77) at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:205)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:198)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:763)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:179)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:300)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:263){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15111) Calcite bug. Function INITCAP fails for NULL argument
Yury Gerzhedovich created IGNITE-15111:
--
Summary: Calcite bug. Function INITCAP fails for NULL argument
Key: IGNITE-15111
URL: https://issues.apache.org/jira/browse/IGNITE-15111
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
Function INITCAP fails for NULL argument
see src/test/sql/function/string/test_initcap.test_ignore
{code:sql}
SELECT initcap(null)
{code}
{code:java}
ava.lang.RuntimeException: while resolving method 'valueOf[class
java.lang.String]' in class class java.lang.Void
at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:318)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:448)
at org.apache.calcite.linq4j.tree.Expressions.call(Expressions.java:460)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:251)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ConverterUtils.convert(ConverterUtils.java:176)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:1963)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:1910)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:991)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:79)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:886)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:79)
at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:205)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:198)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:763)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:179)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:300)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:263)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15110) Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
[
https://issues.apache.org/jira/browse/IGNITE-15110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379195#comment-17379195
]
Aleksey Plekhanov commented on IGNITE-15110:
[~jooger] we already have a ticket for this: IGNITE-14677
> Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
> --
>
> Key: IGNITE-15110
> URL: https://issues.apache.org/jira/browse/IGNITE-15110
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Function CHAR_LENGTH returns an incorrect results for unicode symbols. E.g
> for below query returns 2 instead of 1
> {code:sql}
> SELECT char_length('閭'){code}
> see src/test/sql/function/string/test_char_length.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379190#comment-17379190
]
Mike W commented on IGNITE-12850:
-
Just encountered this issue in production, upvoting
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates base line topology history with gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> –
> tested on 2.7.6, but it seems that ignite 2.8.0 would suffer from the same
> issue - by looking at the code
> --
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15110) Calcite bug. Function CHAR_LENGTH works incorrect with UNICODE
Yury Gerzhedovich created IGNITE-15110:
--
Summary: Calcite bug. Function CHAR_LENGTH works incorrect with
UNICODE
Key: IGNITE-15110
URL: https://issues.apache.org/jira/browse/IGNITE-15110
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
Function CHAR_LENGTH returns an incorrect results for unicode symbols. E.g for
below query returns 2 instead of 1
{code:sql}
SELECT char_length('閭'){code}
see src/test/sql/function/string/test_char_length.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379185#comment-17379185
]
Ilya Kasnacheev commented on IGNITE-12749:
--
I don't think we need to define clear() for map, it should be recreated
Why is this still a problem [~antkr]?
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379171#comment-17379171
]
Ignite TC Bot commented on IGNITE-12749:
{panel:title=Branch: [pull/9246/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9246/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6082559]]
* {color:#013220}IgniteBasicTestSuite:
GridConcurrentLinkedHashMapSelfTest.testClearMapWithQueuePolicies -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6082316buildTypeId=IgniteTests24Java8_RunAll]
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15109) Calcite engine. TIMESTAMPDIFF for MICROSECOND unit doesn't work
Yury Gerzhedovich created IGNITE-15109:
--
Summary: Calcite engine. TIMESTAMPDIFF for MICROSECOND unit
doesn't work
Key: IGNITE-15109
URL: https://issues.apache.org/jira/browse/IGNITE-15109
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
The function TIMESTAMPDIFF for MICROSECOND unit return incorrect results for
many cases. As the example below returns 0.
{code:sql}
SELECT TIMESTAMPDIFF(MICROSECOND, TIMESTAMP '2022-02-01 10:30:28.000',
TIMESTAMP '2022-02-01 10:30:28.128'){code}
see src/test/sql/function/timestamp/test_timestampdiff.test_ignore
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14728) Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed property
[ https://issues.apache.org/jira/browse/IGNITE-14728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Rakhmankulov updated IGNITE-14728: - Description: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *history.rebalance.threshold* instead of a system property. The next algorithm will be used: # On node start *history.rebalance.threshold* property will be checked. # If there is no value, then the old system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. # If a system property is not defined then the default value from java will be written to DMS (*500*). # On property check print to log value and source of value. Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. Dev list discussion [http://apache-ignite-developers.2346864.n4.nabble.com/Change-IGNITE-PDS-WAL-REBALANCE-THRESHOLD-from-System-property-to-Configuraton-tp52560.html] was: We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that determines a count of entries of partition starting from which cluster will try applying historical rebalance for that partition. But the system property is not convenient to use and is hidden from most part of users. I propose the creation of a new DMS property *wal.rebalance.threshold* instead of a system property. The next algorithm will be used: # On node start *wal.rebalance.threshold* property will be checked. # If there is no value, then the old system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. # If a system property is not defined then the default value from java will be written to DMS (*500*). # On property check print to log value and source of value. Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. Dev list discussion http://apache-ignite-developers.2346864.n4.nabble.com/Change-IGNITE-PDS-WAL-REBALANCE-THRESHOLD-from-System-property-to-Configuraton-tp52560.html > Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Distributed > property > -- > > Key: IGNITE-14728 > URL: https://issues.apache.org/jira/browse/IGNITE-14728 > Project: Ignite > Issue Type: Improvement >Reporter: Eduard Rakhmankulov >Assignee: Eduard Rakhmankulov >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > We have a system property named "IGNITE_PDS_WAL_REBALANCE_THRESHOLD", that > determines a count of entries of partition starting from which cluster will > try applying historical rebalance for that partition. > But the system property is not convenient to use and is hidden from most part > of users. > I propose the creation of a new DMS property *history.rebalance.threshold* > instead of a system property. > The next algorithm will be used: > # On node start *history.rebalance.threshold* property will be checked. > # If there is no value, then the old system property > *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* value will be written to DMS. > # If a system property is not defined then the default value from java will > be written to DMS (*500*). > # On property check print to log value and source of value. > Mark the system property *IGNITE_PDS_WAL_REBALANCE_THRESHOLD* as deprecated. > Dev list discussion > [http://apache-ignite-developers.2346864.n4.nabble.com/Change-IGNITE-PDS-WAL-REBALANCE-THRESHOLD-from-System-property-to-Configuraton-tp52560.html] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Description:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpEventListener, ConnectionEventListener,
TopologyEventListener
from pyignite import Client
client = Client(event_listeners=[OpEventListener, ConnectionEventListener,
TopologyEventListener])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client more observable
was:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client more observable
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpEventListener, ConnectionEventListener,
> TopologyEventListener
> from pyignite import Client
> client = Client(event_listeners=[OpEventListener, ConnectionEventListener,
> TopologyEventListener])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15072) Make documentation java code snippets compilable
[ https://issues.apache.org/jira/browse/IGNITE-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379158#comment-17379158 ] Nikita Safonov commented on IGNITE-15072: - OK, no problem! > Make documentation java code snippets compilable > > > Key: IGNITE-15072 > URL: https://issues.apache.org/jira/browse/IGNITE-15072 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksey Plekhanov >Priority: Major > > The whole purpose of having code snippets in separate java files is to ensure > they work (at least compile). But currently, we have a lot of compilation > errors introduced in the 2.10 and 2.11 Ignite versions (it was compilable in > 2.9). > We should fix compilation errors in documentation code snippets and add > checks to Travis or TC to maintain it compilable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Description:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client more observable
was:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15065) Add an explicit method to register binary type based on class
[
https://issues.apache.org/jira/browse/IGNITE-15065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379148#comment-17379148
]
Ignite TC Bot commented on IGNITE-15065:
{panel:title=Branch: [pull/9233/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9233/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Binary Objects{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6079849]]
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryMetadataRegisterClassTest.test - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6079946buildTypeId=IgniteTests24Java8_RunAll]
> Add an explicit method to register binary type based on class
> -
>
> Key: IGNITE-15065
> URL: https://issues.apache.org/jira/browse/IGNITE-15065
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *My proposal is:*
> - add new method to IgniteBinary interface
> {{public BinaryType registerClass(Class cls) throws
> BinaryObjectException;}}
> - the implementation is simple: use {{BinaryContext#registerClass}} to
> register user class and return registered metadata.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12747) Calcite integration. Correlated queries support.
[ https://issues.apache.org/jira/browse/IGNITE-12747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379147#comment-17379147 ] Konstantin Orlov commented on IGNITE-12747: --- [~zstan], LGTM > Calcite integration. Correlated queries support. > > > Key: IGNITE-12747 > URL: https://issues.apache.org/jira/browse/IGNITE-12747 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Stanilovsky Evgeny >Priority: Critical > Labels: calcite2-required, calcite3-required > Time Spent: 4h > Remaining Estimate: 0h > > Rewrite correlated subqueries. > Useful links: > [https://zhuanlan.zhihu.com/p/60380557] > [https://zhuanlan.zhihu.com/p/62338250] > [https://zhuanlan.zhihu.com/p/66227661] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15108) Integrate with actual data layer in Ignite 3.0
Konstantin Orlov created IGNITE-15108: - Summary: Integrate with actual data layer in Ignite 3.0 Key: IGNITE-15108 URL: https://issues.apache.org/jira/browse/IGNITE-15108 Project: Ignite Issue Type: Sub-task Reporter: Konstantin Orlov Need to implement TableScan and probably IndexScan nodes that read a real data from storage as well as rest accompanying code to convert data storage rows to calcite's rows and wise versa. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15107) Integrate DDL handler into Ignite 3.0
Konstantin Orlov created IGNITE-15107: - Summary: Integrate DDL handler into Ignite 3.0 Key: IGNITE-15107 URL: https://issues.apache.org/jira/browse/IGNITE-15107 Project: Ignite Issue Type: Sub-task Components: sql Reporter: Konstantin Orlov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14836) Integrate execution of SELECT queries into Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-14836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-14836: -- Summary: Integrate execution of SELECT queries into Ignite 3.0 (was: Integrate all moved part of Caclite engine in Ignite 3.0) > Integrate execution of SELECT queries into Ignite 3.0 > - > > Key: IGNITE-14836 > URL: https://issues.apache.org/jira/browse/IGNITE-14836 > Project: Ignite > Issue Type: Sub-task >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[ https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15105: - Fix Version/s: (was: 2.11) 2.12 > Reduce number of messages for "Blocked system-critical thread" errors > - > > Key: IGNITE-15105 > URL: https://issues.apache.org/jira/browse/IGNITE-15105 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > > Now, we're printing a lot of messages for these errors, each of them has > thousands of lines, because it prints locks and/or threads. It overwrites > everything else in logs and makes troubleshooting impossible. > This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15079) SharedPageLockTracker.structureNameToId map is populated but never cleaned - 1.3G retained heap
[ https://issues.apache.org/jira/browse/IGNITE-15079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-15079: - Fix Version/s: (was: 2.11) 2.12 > SharedPageLockTracker.structureNameToId map is populated but never cleaned - > 1.3G retained heap > --- > > Key: IGNITE-15079 > URL: https://issues.apache.org/jira/browse/IGNITE-15079 > Project: Ignite > Issue Type: Task >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Attachments: structureNameById.png > > > I can see SharedPageLockTracker.structureNameToId.put() being called, but > never remove() or clear(). > Naturally, this leads to memory leak. During 36d uptime, an 1.3G of total > retained heap (keys, values and cells) were reached. This is unacceptable, it > should have either TTL or max size to avoid using 1% of heap (20% in this > case). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15106) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-15106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kseniya Romanova updated IGNITE-15106: -- Reviewer: Mauricio Stekl > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-15106 > URL: https://issues.apache.org/jira/browse/IGNITE-15106 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Priority: Trivial > > Please add an event to [https://ignite.apache.org/events.html] > > Apache Ignite 3.0.0 Alpha 2 Build Community Gathering > Virtual Apache Ignite Meetup, Valentin Kulichenko > June 20 > This gathering is organized to summarize feedback, share ideas, and overview > the following stages of Ignite 3.0 development. > During this session, we will: > ‒ Give an update on the Ignite 3 development - what has been completed so > far, and the next steps planned. > ‒ Discuss the latest Ignite 3 milestone: the Alpha 2 release. > ‒ Run a live demo: create an Ignite 3 Alpha 2 cluster and demonstrate the new > APIs usage by running code examples. > Learn > more=https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/279417063/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15106) [Ignite Website] Update for events schedule
Kseniya Romanova created IGNITE-15106: - Summary: [Ignite Website] Update for events schedule Key: IGNITE-15106 URL: https://issues.apache.org/jira/browse/IGNITE-15106 Project: Ignite Issue Type: Task Components: website Reporter: Kseniya Romanova Please add an event to [https://ignite.apache.org/events.html] Apache Ignite 3.0.0 Alpha 2 Build Community Gathering Virtual Apache Ignite Meetup, Valentin Kulichenko June 20 This gathering is organized to summarize feedback, share ideas, and overview the following stages of Ignite 3.0 development. During this session, we will: ‒ Give an update on the Ignite 3 development - what has been completed so far, and the next steps planned. ‒ Discuss the latest Ignite 3 milestone: the Alpha 2 release. ‒ Run a live demo: create an Ignite 3 Alpha 2 cluster and demonstrate the new APIs usage by running code examples. Learn more=https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/279417063/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14092: - Description: IP finder service is needed on a network level to allow nodes to find existing clusters and avoid excessive manual configuration. In some cases like cloud environments manual configuration of all cluster's nodes is impractical. Special implementation of IP Finder solves this problem. In this task we need to design IP Finder API suitable for different use-cases and develop a simplistic static implementation. was:IP finder working on a network level is needed to automate node join process to existing cluster: instead of configuring each cluster node manually > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > > IP finder service is needed on a network level to allow nodes to find > existing clusters and avoid excessive manual configuration. > In some cases like cloud environments manual configuration of all cluster's > nodes is impractical. Special implementation of IP Finder solves this problem. > In this task we need to design IP Finder API suitable for different use-cases > and develop a simplistic static implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15072) Make documentation java code snippets compilable
[ https://issues.apache.org/jira/browse/IGNITE-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379111#comment-17379111 ] Aleksey Plekhanov commented on IGNITE-15072: [~nsafonov], I can take it later (in 2-3 weeks). But let's keep it unassigned for a while, perhaps someone else would like to work on this ticket. > Make documentation java code snippets compilable > > > Key: IGNITE-15072 > URL: https://issues.apache.org/jira/browse/IGNITE-15072 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksey Plekhanov >Priority: Major > > The whole purpose of having code snippets in separate java files is to ensure > they work (at least compile). But currently, we have a lot of compilation > errors introduced in the 2.10 and 2.11 Ignite versions (it was compilable in > 2.9). > We should fix compilation errors in documentation code snippets and add > checks to Travis or TC to maintain it compilable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) Simplistic IP Finder to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14092: - Description: IP finder working on a network level is needed to automate node join process to existing cluster: instead of configuring each cluster node manually > Simplistic IP Finder to locate and join existing cluster > > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > > IP finder working on a network level is needed to automate node join process > to existing cluster: instead of configuring each cluster node manually -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) IP Finder API and first implementation to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14092: - Summary: IP Finder API and first implementation to locate and join existing cluster (was: Simplistic IP Finder to locate and join existing cluster) > IP Finder API and first implementation to locate and join existing cluster > -- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > > IP finder working on a network level is needed to automate node join process > to existing cluster: instead of configuring each cluster node manually -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) Simplistic IP Finder to locate and join existing cluster
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14092: - Summary: Simplistic IP Finder to locate and join existing cluster (was: Design network address resolver) > Simplistic IP Finder to locate and join existing cluster > > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14092) Design network address resolver
[ https://issues.apache.org/jira/browse/IGNITE-14092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14092: - Description: (was: It needs to design network address resolver/ip finder/discovery which would help to choose the right ip/port for connection. Perhaps we don't need such a service at all but it should be explicitly agreed.) > Design network address resolver > --- > > Key: IGNITE-14092 > URL: https://issues.apache.org/jira/browse/IGNITE-14092 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
Aleksandr Polovtcev created IGNITE-15105: Summary: Reduce number of messages for "Blocked system-critical thread" errors Key: IGNITE-15105 URL: https://issues.apache.org/jira/browse/IGNITE-15105 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev Fix For: 2.11 Now, we're printing a lot of messages for these errors, each of them has thousands of lines, because it prints locks and/or threads. It overwrites everything else in logs and makes troubleshooting impossible. This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-13668:
-
Assignee: Vladimir Ermakov
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha3
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Let's extend native support for Numeric types.
> * Number( n ) is an {{n}}-bytes two-complement integer signed value encoded
> in the varlong style
> (so that Number(4) can be mapped to integer and Number(8) can be mapped to
> long during (de)serialization).
> * Larger numbers can be represented as {{BigInteger}}.
> * The Number( n ) is a varlen type, so it will take two additional bytes in
> the varlen table, so types smaller than Number(4) are better represented by
> {{byte}} and {{short}} and {{int}} types as their fixlen encoding takes
> exactly 1, 2, 4 bytes respectively.
> * Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15072) Make documentation java code snippets compilable
[ https://issues.apache.org/jira/browse/IGNITE-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379103#comment-17379103 ] Nikita Safonov commented on IGNITE-15072: - [~alex_pl] could you please take this ticket or ask someone who's capable of fixing this? I'm not sure that I can settle it right. Thank you! > Make documentation java code snippets compilable > > > Key: IGNITE-15072 > URL: https://issues.apache.org/jira/browse/IGNITE-15072 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksey Plekhanov >Priority: Major > > The whole purpose of having code snippets in separate java files is to ensure > they work (at least compile). But currently, we have a lot of compilation > errors introduced in the 2.10 and 2.11 Ignite versions (it was compilable in > 2.9). > We should fix compilation errors in documentation code snippets and add > checks to Travis or TC to maintain it compilable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15103:
-
Description:
Currently, there is no logging at all, should be added using {{logging}} module
Also, optional handler to {{stderr}} should be added if env variable is set,
[i.e.|https://github.com/aio-libs/aioredis-py/blob/bb0dcebed350a5f764dc84c5b6bcb44a3bf98c6b/aioredis/log.py]
{code:python}
logger = logging.getLogger("pyignite")
if os.environ.get("PYIGNITE_DEBUG"):
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler(stream=sys.stderr)
handler.setFormatter(
logging.Formatter("%(asctime)s %(name)s %(levelname)s %(message)s")
)
logger.addHandler(handler)
os.environ["PYIGNITE_DEBUG"] = ""
{code}
was:Currently, there is no logging at all, should be added using {{logging}}
module
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
> Also, optional handler to {{stderr}} should be added if env variable is set,
> [i.e.|https://github.com/aio-libs/aioredis-py/blob/bb0dcebed350a5f764dc84c5b6bcb44a3bf98c6b/aioredis/log.py]
> {code:python}
> logger = logging.getLogger("pyignite")
> if os.environ.get("PYIGNITE_DEBUG"):
> logger.setLevel(logging.DEBUG)
> handler = logging.StreamHandler(stream=sys.stderr)
> handler.setFormatter(
> logging.Formatter("%(asctime)s %(name)s %(levelname)s %(message)s")
> )
> logger.addHandler(handler)
> os.environ["PYIGNITE_DEBUG"] = ""
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15104) Introduce a higher level messaging abstraction
Aleksandr Polovtcev created IGNITE-15104:
Summary: Introduce a higher level messaging abstraction
Key: IGNITE-15104
URL: https://issues.apache.org/jira/browse/IGNITE-15104
Project: Ignite
Issue Type: Task
Components: networking
Affects Versions: 3.0.0-alpha3
Reporter: Aleksandr Polovtcev
Assignee: Sergey Chugunov
Current network messaging interface has two groups of methods: methods, that
accept a {{NetworkAddress}} as the destination address, and methods, that
accept a {{ClusterNode}} as the destination address. First group is mostly
useful for low-level interactions (e.g. in JRaft), while the second group is
used by more high-level API consumers. This makes the whole interface less
consistent and more difficult to use, for example, message listeners only
provide the {{NetworkAddress}} of the sender, which is inconvenient for
high-level components.
It is proposed to split this interface into two (actual naming is not final and
can be changed during further discussions):
# {{NetworkMessageService}} - for low-level interactions. It should accept a
{{NetworkAddress}} as the recipient address and must be decoupled from the
{{TopologyService}}.
# {{ClusterMessageService}} - for high-level interactions. It should accept a
{{ClusterNode}} as the recipient address and can be implemented as a
composition of the {{NetworkMessageService}} and {{TopologyService}} .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Labels: python thin (was: )
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-15103:
Assignee: Ivan Daschinsky
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15103:
-
Labels: python thin (was: )
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15103) Add logging to pyignite client
Ivan Daschinsky created IGNITE-15103:
Summary: Add logging to pyignite client
Key: IGNITE-15103
URL: https://issues.apache.org/jira/browse/IGNITE-15103
Project: Ignite
Issue Type: Improvement
Components: python, thin client
Reporter: Ivan Daschinsky
Currently, there is no logging at all, should be added using {{logging}} module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Description:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
was:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Description:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to:
# *Connection events* connect or disconnect to specific ignite server,
connection errors
# *Topology events* when partition awareness is enabled, log new topology
versions
# *Operations events* start,success or failure with request_id, server
(address, port and uuid), operation_id, error string if presents
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
was:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to connection events (connect or disconnect to
specific ignite server, connection errors), topology changes (when partition
awareness is enabled, log new topology versions), operations logging
(start,success or failure with request_id, server (address, port and uuid),
operation_id, error string if presents)
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15102) Implement monitoring of various pyignite's events
Ivan Daschinsky created IGNITE-15102:
Summary: Implement monitoring of various pyignite's events
Key: IGNITE-15102
URL: https://issues.apache.org/jira/browse/IGNITE-15102
Project: Ignite
Issue Type: Improvement
Components: python, thin client
Reporter: Ivan Daschinsky
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger]
with client.connect(...):
..
{code}
I suggests to add listeners to connection events (connect or disconnect to
specific ignite server, connection errors), topology changes (when partition
awareness is enabled, log new topology versions), operations logging
(start,success or failure with request_id, server (address, port and uuid),
operation_id, error string if presents)
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Description:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
with client.connect(...):
..
{code}
I suggests to add listeners to connection events (connect or disconnect to
specific ignite server, connection errors), topology changes (when partition
awareness is enabled, log new topology versions), operations logging
(start,success or failure with request_id, server (address, port and uuid),
operation_id, error string if presents)
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
was:
I suggest to add monitoring capabilities to {{pyignite}} similar to
[pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
Suggested api:
{code:python}
from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
from pyignite import Client
client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger]
with client.connect(...):
..
{code}
I suggests to add listeners to connection events (connect or disconnect to
specific ignite server, connection errors), topology changes (when partition
awareness is enabled, log new topology versions), operations logging
(start,success or failure with request_id, server (address, port and uuid),
operation_id, error string if presents)
This approach can implement custom metrics, tracing and other useful
client-side stuff in order to make client's more observable
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to connection events (connect or disconnect to
> specific ignite server, connection errors), topology changes (when partition
> awareness is enabled, log new topology versions), operations logging
> (start,success or failure with request_id, server (address, port and uuid),
> operation_id, error string if presents)
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-15102:
Assignee: Ivan Daschinsky
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymnogo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpLogger, ConnectionLogger, TopologyLogger
> from pyignite import Client
> client = Client(event_listeners=[OpLogger, ConnectionLogger, TopologyLogger]
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to connection events (connect or disconnect to
> specific ignite server, connection errors), topology changes (when partition
> awareness is enabled, log new topology versions), operations logging
> (start,success or failure with request_id, server (address, port and uuid),
> operation_id, error string if presents)
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client's more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15086) Design a public tx API
[ https://issues.apache.org/jira/browse/IGNITE-15086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15086: --- Description: Design a public tx API. (was: Design a public tx API. Goals: * Asynchronous * Not attached to any thread) > Design a public tx API > -- > > Key: IGNITE-15086 > URL: https://issues.apache.org/jira/browse/IGNITE-15086 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > > Design a public tx API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378993#comment-17378993 ] Alexey Scherbakov commented on IGNITE-15057: [~agoncharuk] [~agura] Waiting for a review. > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > More specifically, suppose a transaction Ti tries to wait for Tj => lock > order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than > Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] > => Ti is aborted. > Aborted transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Description: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. More specifically, suppose a transaction Ti tries to wait for Tj => lock order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] => Ti is aborted. Aborted transactions must be restarted preserving it's timestamp. was: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions must be restarted preserving it's timestamp. > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > More specifically, suppose a transaction Ti tries to wait for Tj => lock > order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than > Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] > => Ti is aborted. > Aborted transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Description: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions must be restarted preserving it's timestamp. was: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions are restarted preserving it's timestamp. > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > Otherwise, newer transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15019) ITNodeTest.testFollowerStartStopFollowing is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-15019:
Assignee: Mirza Aliev
> ITNodeTest.testFollowerStartStopFollowing is flaky
> --
>
> Key: IGNITE-15019
> URL: https://issues.apache.org/jira/browse/IGNITE-15019
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {code:java}
> [ERROR]
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing
> Time elapsed: 1.557 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <2> but was: <3>
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2686)
> {code}
> This is all I have from logs. Must be a race somewhere
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
