[jira] [Created] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
Alexand Polyakov created IGNITE-13175:
-
Summary: NPE due to race on cache stop and transaction commit.
Key: IGNITE-13175
URL: https://issues.apache.org/jira/browse/IGNITE-13175
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexand Polyakov
If don't stop load and execute stop cache, sometimes throw NullPointerException
and nodes failed
{code}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
at
org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
transaction use cache context race with stopCache
{code:java}
at
org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
{code}
there is a reproducer who adds CountDownLatch await to IgniteTxEntry#unmarshal
which is countDown in GridCacheContext#cleanup
https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13164) Thin client: Fix nodeIds format for execute compute tasks request
[ https://issues.apache.org/jira/browse/IGNITE-13164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13164: --- Affects Version/s: 2.9 > Thin client: Fix nodeIds format for execute compute tasks request > -- > > Key: IGNITE-13164 > URL: https://issues.apache.org/jira/browse/IGNITE-13164 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, each node id in thin client execute compute task request is > written using 17 bytes (1 byte for type id and 16 bytes for UUID raw data). > Since we don't need information about type id and node id can't be null we > can write only UUID raw data as now implemented for service invoke request. > Compute functionality is not released yet, so format can be changed without > compatibility issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11662) Wrong classloader is used to unmarshal joining node data
[
https://issues.apache.org/jira/browse/IGNITE-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142367#comment-17142367
]
Richard Bryan commented on IGNITE-11662:
Fix looks good, and is necessary for clustering in Karaf. Please merge to
master.
> Wrong classloader is used to unmarshal joining node data
>
>
> Key: IGNITE-11662
> URL: https://issues.apache.org/jira/browse/IGNITE-11662
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a cluster coordinator node is running in Karaf container it cannot
> accept joining requests from other nodes. Problem lies in unability to
> unmarshal joining node data in
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode()
> This line
> {code:java}
> joiningNodeState = marsh.unmarshal((byte[]) discoData.joiningNodeData(),
> Thread.currentThread().getContextClassLoader());{code}
> fails with
> {noformat}
> Error on unmarshalling discovery data from node
> 10.0.2.15,127.0.0.1,172.17.0.1:47501: Failed to find class with given class
> loader for unmarshalling (make sure same versions of all classes are
> available on all nodes or enable peer-class-loading)
> [clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@5c0369c4,
> cls=org.apache.ignite.internal.processors.cluster.DiscoveryDataClusterState];
> node is not allowed to join{noformat}
> Apparently problem is wrong classloader returned by
> {code:java}
> Thread.currentThread().getContextClassLoader()){code}
> which is not the one created in IgniteAbstractOsgiContextActivator.start().
> *Proposed fix:*
> use proper way of obtaining classloader:
> {code:java}
> U.resolveClassLoader(ctx.config()){code}
> Like in other places. i.e. in GridClusterStateProcessor.collectGridNodeData().
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11351) Basic "Starting Ignite inside an OSGi container" doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142366#comment-17142366 ] Richard Bryan commented on IGNITE-11351: Fix looks good, and is necessary for clustering in Karaf. Please merge to master. > Basic "Starting Ignite inside an OSGi container" doesn't work > - > > Key: IGNITE-11351 > URL: https://issues.apache.org/jira/browse/IGNITE-11351 > Project: Ignite > Issue Type: Bug > Components: osgi >Affects Versions: 2.7 > Environment: Apache Felix, JDK 1.8 >Reporter: Xander Uiterlinden >Priority: Major > Attachments: ignite-osgi-patch.diff > > > When running the example from > [https://apacheignite.readme.io/v1.5/docs/osgi-starting-inside-a-container] > you're getting the following error. > Failed to start Ignite via OSGi Activator [errMsg=Failed to find empty > constructor for class: > o.a.i.i.processors.platform.websession.PlatformDotNetSessionLockResult]class > Looking at the codebase this class does indeed not have an empty constructor. > When adding that, you'll be running into the next issue which is a > classloader issue. Ignite needs to be started with the correct context > classloader for it to start successfully. > Please find the attached patch that resolves both problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-11351) Basic "Starting Ignite inside an OSGi container" doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Bryan updated IGNITE-11351: --- Comment: was deleted (was: Fix looks good, and is necessary for clustering in Karaf. Please merge to master.) > Basic "Starting Ignite inside an OSGi container" doesn't work > - > > Key: IGNITE-11351 > URL: https://issues.apache.org/jira/browse/IGNITE-11351 > Project: Ignite > Issue Type: Bug > Components: osgi >Affects Versions: 2.7 > Environment: Apache Felix, JDK 1.8 >Reporter: Xander Uiterlinden >Priority: Major > Attachments: ignite-osgi-patch.diff > > > When running the example from > [https://apacheignite.readme.io/v1.5/docs/osgi-starting-inside-a-container] > you're getting the following error. > Failed to start Ignite via OSGi Activator [errMsg=Failed to find empty > constructor for class: > o.a.i.i.processors.platform.websession.PlatformDotNetSessionLockResult]class > Looking at the codebase this class does indeed not have an empty constructor. > When adding that, you'll be running into the next issue which is a > classloader issue. Ignite needs to be started with the correct context > classloader for it to start successfully. > Please find the attached patch that resolves both problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13155) Snapshot creation throws NPE on an in-memory cluster
[
https://issues.apache.org/jira/browse/IGNITE-13155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13155:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Snapshot creation throws NPE on an in-memory cluster
>
>
> Key: IGNITE-13155
> URL: https://issues.apache.org/jira/browse/IGNITE-13155
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> Snapshot creation throws NPE on an in-memory cluster.
> {code}
> Error stack trace:
> class org.apache.ignite.internal.client.GridClientException: Failed to handle
> request: [req=EXE,
> taskName=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask,
> params=[VisorTaskArgument [debug=false]], err=Failed to reduce job results
> due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null], trace=class
> org.apache.ignite.IgniteCheckedException: Failed to reduce job results due to
> undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7566)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:172)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:325)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:104)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:179)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.compute.ComputeUserUndeclaredException:
> Failed to reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.visor.snapshot.VisorSnapshotCreateTask@4d45b97f,
> err=class org.apache.ignite.IgniteException: null]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1184)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:974)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processDelayedResponses(GridTaskWorker.java:711)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:542)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:830)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:555)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:535)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
> ... 8 more
> Caused by: class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1086)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
> at
[jira] [Assigned] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Núñez reassigned IGNITE-13005:
-
Assignee: Manuel Núñez
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Assignee: Manuel Núñez
>Priority: Major
> Labels: spring-data
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements.
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin,
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(Class project
[jira] [Updated] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Núñez updated IGNITE-13005:
--
Description:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements.
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) into SQL queries, declared using
{{@Param("myParam")}}
* Supports advanced parameter binding and SpEL expressions into SQL queries:
** *Template variables*:
*** {{#entityName}} - the simple class name of the domain entity
** *Method parameter expressions*: Parameters are exposed for indexed access
({{[0]}} is the first query method's param) or via the name declared using
{{@Param}}. The actual SpEL expression binding is triggered by {{?#}}. Example:
{{?#\{[0]\}} or {{?#\{#myParamName\}}}
** *Advanced SpEL expressions*: While advanced parameter binding is a very
useful feature, the real power of SpEL stems from the fact, that the
expressions can refer to framework abstractions or other application components
through SpEL EvaluationContext extension model.
* Supports SpEL expressions into Text queries ({{TextQuery}}).
Some examples:
{code:java}
// Spring Data Repositories using different ignite instances on same JVM
@RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
public interface FlightRouteRepository extends IgniteRepository {
...
}
@RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
public interface PoiRepository extends IgniteRepository {
...
}
{code}
{code:java}
// named parameter
@Query(value = "SELECT * from #{#entityName} where email = :email")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// indexed parameters
@Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city =
?#{[1]}")
List searchUsersByCity(@Param("country") String country, @Param("city")
String city, Pageable pageable);
{code}
{code:java}
// ordered method parameters
@Query(value = "SELECT * from #{#entityName} where email = ?")
User searchUserByEmail(String email);
{code}
{code:java}
// Advanced SpEL expressions
@Query(value = "SELECT * from #{#entityName} where uuidCity =
?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
List searchUsersByCity(@Param("city") String city, Pageable pageable);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "email: #{#email}")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "#{#textToSearch}")
List searchUsersByText(@Param("textToSearch") String text, Pageable
pageable);
{code}
{code:java}
// textQuery - evaluated SpEL indexed parameter
@Query(textQuery = true, value = "#{[0]}")
List searchUsersByText(String textToSearch, Pageable pageable);
{code}
{code:java}
// Static Projection
@Query(value =
"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e USE
INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
+ "._key=e"
+ ".merchant WHERE e.origin = :origin and e.disabled =
:disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
List searchMerchantsByOrigin(@Param("origin") String origin,
@Param("disabled") boolean disabled);
{code}
{code:java}
// Dynamic Projection
@Query(value =
"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e USE
INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
+ "._key=e"
+ ".merchant WHERE e.origin = :origin and e.disabled =
:disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
List searchMerchantsByOrigin(Class projection, @Param("origin")
String origin, @Param("disabled") boolean disabled);
{code}
was:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements. Is there any ignite developer who can do the pull-request
process?. Thanks community!!
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) into SQL queries, declared using
{{@Param("myParam")}}
* Supports advanced parameter bi
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142300#comment-17142300 ] Igor Sapego commented on IGNITE-13078: -- [~ivandasch] looks good to me. > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Attachments: ignite-13078-dynamic-odbc.patch, > ignite-13078-static-odbc.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build processes for > windows and Linux, lack of building support on Mac OS X (a quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest migrating to the CMake build system. It is very popular among > open source projects, and in The Apache Software Foundation too. Notable > users: Apache Mesos, Apache Zookeeper (C client offers CMake as an > alternative to autoconf and the only option on Windows), Apache Kafka > (librdkafka - C/C++ client), Apache Thrift. Popular column-oriented database > ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142292#comment-17142292
]
Manuel Núñez commented on IGNITE-13005:
---
Done https://github.com/apache/ignite/pull/7953.
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Priority: Major
> Labels: spring-data
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements. Is there any ignite developer who can do the
> pull-request process?. Thanks community!!
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin,
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :orig
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142294#comment-17142294 ] Igor Sapego commented on IGNITE-13078: -- Created separate ticket for Windows support: IGNITE-13174 > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Attachments: ignite-13078-dynamic-odbc.patch, > ignite-13078-static-odbc.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build processes for > windows and Linux, lack of building support on Mac OS X (a quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest migrating to the CMake build system. It is very popular among > open source projects, and in The Apache Software Foundation too. Notable > users: Apache Mesos, Apache Zookeeper (C client offers CMake as an > alternative to autoconf and the only option on Windows), Apache Kafka > (librdkafka - C/C++ client), Apache Thrift. Popular column-oriented database > ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13174) C++: Add Windows support to CMake build system
Igor Sapego created IGNITE-13174: Summary: C++: Add Windows support to CMake build system Key: IGNITE-13174 URL: https://issues.apache.org/jira/browse/IGNITE-13174 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.8.1 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.9 Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[ https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12111: - Release Note: Added Cluster ID and tag properties to identify the cluster > Cluster ID and tag: properties to identify the cluster > -- > > Key: IGNITE-12111 > URL: https://issues.apache.org/jira/browse/IGNITE-12111 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > To improve cluster management capabilities two new properties of the cluster > are introduced: > # A unique cluster ID (may be either a random UUID or random IgniteUUID). > Generated upon cluster start and saved to the distributed metastorage. > Immutable. Persistent clusters must persist the value. In-memory clusters > should keep the generated ID in memory and regenerate it upon restart. > # Human-readable cluster tag. Generated by default to some random (but still > meaningful) string, may be changed by user. Again survives restart in > persistent clusters and is regenerated in in-memory clusters on every restart. > These properties are exposed to standard APIs: > # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user; > # JMX bean and control utility APIs to view ID and tag and change tag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[ https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142261#comment-17142261 ] Ilya Kasnacheev commented on IGNITE-12111: -- Thank you for contribution, I have merged it to master. Please create a ticket to document this feature. > Cluster ID and tag: properties to identify the cluster > -- > > Key: IGNITE-12111 > URL: https://issues.apache.org/jira/browse/IGNITE-12111 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > To improve cluster management capabilities two new properties of the cluster > are introduced: > # A unique cluster ID (may be either a random UUID or random IgniteUUID). > Generated upon cluster start and saved to the distributed metastorage. > Immutable. Persistent clusters must persist the value. In-memory clusters > should keep the generated ID in memory and regenerate it upon restart. > # Human-readable cluster tag. Generated by default to some random (but still > meaningful) string, may be changed by user. Again survives restart in > persistent clusters and is regenerated in in-memory clusters on every restart. > These properties are exposed to standard APIs: > # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user; > # JMX bean and control utility APIs to view ID and tag and change tag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13066) Test framework must print which tests for quite mode
[
https://issues.apache.org/jira/browse/IGNITE-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142240#comment-17142240
]
Maxim Muzafarov commented on IGNITE-13066:
--
[~ilyak]
Hello, can we proceed with this change?
> Test framework must print which tests for quite mode
>
>
> Key: IGNITE-13066
> URL: https://issues.apache.org/jira/browse/IGNITE-13066
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For most of the TeamCity test suites logger is turned off for performance
> reasons (log size can be more than a thousand MB). In case of exceptions
> happened it's hard to identify which of running tests fail.
> It is necessary to log which tests are started regardless of the logger
> configured or not.
> Example:
> {code:java}
> info(">>> Starting test: " + testDescription() + " <<<"); {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13173) Add additional attributes to system views
Dmitry Frolov created IGNITE-13173: -- Summary: Add additional attributes to system views Key: IGNITE-13173 URL: https://issues.apache.org/jira/browse/IGNITE-13173 Project: Ignite Issue Type: Wish Affects Versions: 2.8.1, 2.8 Reporter: Dmitry Frolov This is a proposal to enrich system views with additional attributes of the cache entries: offHeapEntriesCount offHeapBackupEntriesCount offHeapPrimaryEntriesCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13173) Add additional attributes to system views
[ https://issues.apache.org/jira/browse/IGNITE-13173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Frolov updated IGNITE-13173: --- Priority: Major (was: Trivial) > Add additional attributes to system views > - > > Key: IGNITE-13173 > URL: https://issues.apache.org/jira/browse/IGNITE-13173 > Project: Ignite > Issue Type: Wish >Affects Versions: 2.8, 2.8.1 >Reporter: Dmitry Frolov >Priority: Major > Labels: IEP-35 > > This is a proposal to enrich system views with additional attributes of the > cache entries: > offHeapEntriesCount > offHeapBackupEntriesCount > offHeapPrimaryEntriesCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12995) Transactions hang up if node fails
[ https://issues.apache.org/jira/browse/IGNITE-12995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142093#comment-17142093 ] Stepachev Maksim commented on IGNITE-12995: --- [https://github.com/apache/ignite/pull/7952/files] > Transactions hang up if node fails > -- > > Key: IGNITE-12995 > URL: https://issues.apache.org/jira/browse/IGNITE-12995 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > > Now if node fails and some transaction that requires this node is in progress > it hangs up and is rolled back after timeout. Although we already know that > it cannot be committed. We should rollback active transactions on node fail. > Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142037#comment-17142037
]
Ilya Kasnacheev commented on IGNITE-13005:
--
Please create a pull-request. [~mnusan]
> Spring Data 2 - "JPA style" and working with multiple Ignite instances on
> same JVM
> --
>
> Key: IGNITE-13005
> URL: https://issues.apache.org/jira/browse/IGNITE-13005
> Project: Ignite
> Issue Type: Improvement
> Components: spring
>Affects Versions: 2.7.6, 2.8.1
>Reporter: Manuel Núñez
>Priority: Major
> Labels: spring-data
>
> I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some
> interesting improvements. Is there any ignite developer who can do the
> pull-request process?. Thanks community!!
> Code is 100% compatible with previous versions.
> [https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
> * Supports multiple ignite instances on same JVM (@RepositoryConfig).
> * Supports query tuning parameters in {{@Query}} annotation
> * Supports projections
> * Supports {{Page}} and {{Stream}} responses
> * Supports Sql Fields Query resultset transformation into the domain entity
> * Supports named parameters ({{:myParam}}) into SQL queries, declared using
> {{@Param("myParam")}}
> * Supports advanced parameter binding and SpEL expressions into SQL queries:
> ** *Template variables*:
> *** {{#entityName}} - the simple class name of the domain entity
> ** *Method parameter expressions*: Parameters are exposed for indexed access
> ({{[0]}} is the first query method's param) or via the name declared using
> {{@Param}}. The actual SpEL expression binding is triggered by {{?#}}.
> Example: {{?#\{[0]\}} or {{?#\{#myParamName\}}}
> ** *Advanced SpEL expressions*: While advanced parameter binding is a very
> useful feature, the real power of SpEL stems from the fact, that the
> expressions can refer to framework abstractions or other application
> components through SpEL EvaluationContext extension model.
> * Supports SpEL expressions into Text queries ({{TextQuery}}).
> Some examples:
> {code:java}
> // Spring Data Repositories using different ignite instances on same JVM
> @RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
> public interface FlightRouteRepository extends IgniteRepository String> {
> ...
> }
> @RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
> public interface PoiRepository extends IgniteRepository {
> ...
> }
> {code}
> {code:java}
> // named parameter
> @Query(value = "SELECT * from #{#entityName} where email = :email")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // indexed parameters
> @Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city
> = ?#{[1]}")
> List searchUsersByCity(@Param("country") String country, @Param("city")
> String city, Pageable pageable);
> {code}
> {code:java}
> // ordered method parameters
> @Query(value = "SELECT * from #{#entityName} where email = ?")
> User searchUserByEmail(String email);
> {code}
> {code:java}
> // Advanced SpEL expressions
> @Query(value = "SELECT * from #{#entityName} where uuidCity =
> ?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
> List searchUsersByCity(@Param("city") String city, Pageable pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "email: #{#email}")
> User searchUserByEmail(@Param("email") String email);
> {code}
> {code:java}
> // textQuery - evaluated SpEL named parameter
> @Query(textQuery = true, value = "#{#textToSearch}")
> List searchUsersByText(@Param("textToSearch") String text, Pageable
> pageable);
> {code}
> {code:java}
> // textQuery - evaluated SpEL indexed parameter
> @Query(textQuery = true, value = "#{[0]}")
> List searchUsersByText(String textToSearch, Pageable pageable);
> {code}
> {code:java}
> // Static Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
> List searchMerchantsByOrigin(@Param("origin") String origin,
> @Param("disabled") boolean disabled);
> {code}
> {code:java}
> // Dynamic Projection
> @Query(value =
>"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e
> USE INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
>+ "._key=e"
>+ ".merchant WHERE e.origin = :origin and e.disabled =
> :disabled GROUP BY m.id, m.name,
[jira] [Updated] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13071: Labels: read-only-mode (was: ) > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11889) Add security permissions cluster state change operations
[ https://issues.apache.org/jira/browse/IGNITE-11889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11889: Labels: read-only-mode (was: ) > Add security permissions cluster state change operations > > > Key: IGNITE-11889 > URL: https://issues.apache.org/jira/browse/IGNITE-11889 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Sergey Antonov >Priority: Major > Labels: read-only-mode > > We should add security permissions for cluster state change operations: > * Cluster activation/deactivation. > * Set/change baseline topology. > * Enable/disable read-only mode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11863) .NET: Add cluster read-only mode API (status, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-11863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11863: Labels: .NET read-only-mode (was: .NET) > .NET: Add cluster read-only mode API (status, run-time change) > -- > > Key: IGNITE-11863 > URL: https://issues.apache.org/jira/browse/IGNITE-11863 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Sergey Antonov >Priority: Major > Labels: .NET, read-only-mode > > We would introduce at IGNITE-11256 new methods in IgniteCluster. > We need their support in .Net side. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12136) Test ClusterReadOnlyModeTest is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-12136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12136: Labels: read-only-mode (was: ) > Test ClusterReadOnlyModeTest is flaky. > -- > > Key: IGNITE-12136 > URL: https://issues.apache.org/jira/browse/IGNITE-12136 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4535823271211432266&tab=testDetails&branch_IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
[
https://issues.apache.org/jira/browse/IGNITE-13076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13076:
Labels: read-only-mode (was: )
> Cluster read-only mode doesn't affect LOCAL caches
> --
>
> Key: IGNITE-13076
> URL: https://issues.apache.org/jira/browse/IGNITE-13076
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
>
> You can make data modification operations with LOCAL cache even if cluster in
> a {{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Labels: read-only-mode (was: )
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
> We introduced new compute requests for getting/change cluster state from the
> client node as internal classes of GridClusterStateProcessor. We should move
> them to separate public classes for maintainability purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13138) Add REST tests for the new cluster state change API
[ https://issues.apache.org/jira/browse/IGNITE-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13138: Labels: read-only-mode test (was: test) > Add REST tests for the new cluster state change API > --- > > Key: IGNITE-13138 > URL: https://issues.apache.org/jira/browse/IGNITE-13138 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode, test > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > I didn't find tests for a new REST commands introduced in an IGNITE-12225. It > must be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11866) Add ability to activate cluster in read-only mode
[ https://issues.apache.org/jira/browse/IGNITE-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11866: Ignite Flags: (was: Docs Required) > Add ability to activate cluster in read-only mode > - > > Key: IGNITE-11866 > URL: https://issues.apache.org/jira/browse/IGNITE-11866 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > > After IGNITE-11256 we have cluster read-only mode. We should have ability to > activate cluster and enable read-only mode like atomic operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11256: Labels: important read-only-mode (was: important) > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Sergey Antonov >Priority: Major > Labels: important, read-only-mode > Fix For: 2.9 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Labels: read-only-mode (was: )
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[ https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142004#comment-17142004 ] Ilya Kasnacheev commented on IGNITE-12111: -- LGTM now! > Cluster ID and tag: properties to identify the cluster > -- > > Key: IGNITE-12111 > URL: https://issues.apache.org/jira/browse/IGNITE-12111 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > To improve cluster management capabilities two new properties of the cluster > are introduced: > # A unique cluster ID (may be either a random UUID or random IgniteUUID). > Generated upon cluster start and saved to the distributed metastorage. > Immutable. Persistent clusters must persist the value. In-memory clusters > should keep the generated ID in memory and regenerate it upon restart. > # Human-readable cluster tag. Generated by default to some random (but still > meaningful) string, may be changed by user. Again survives restart in > persistent clusters and is regenerated in in-memory clusters on every restart. > These properties are exposed to standard APIs: > # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user; > # JMX bean and control utility APIs to view ID and tag and change tag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Núñez updated IGNITE-13005:
--
Description:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements. Is there any ignite developer who can do the pull-request
process?. Thanks community!!
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) into SQL queries, declared using
{{@Param("myParam")}}
* Supports advanced parameter binding and SpEL expressions into SQL queries:
** *Template variables*:
*** {{#entityName}} - the simple class name of the domain entity
** *Method parameter expressions*: Parameters are exposed for indexed access
({{[0]}} is the first query method's param) or via the name declared using
{{@Param}}. The actual SpEL expression binding is triggered by {{?#}}. Example:
{{?#\{[0]\}} or {{?#\{#myParamName\}}}
** *Advanced SpEL expressions*: While advanced parameter binding is a very
useful feature, the real power of SpEL stems from the fact, that the
expressions can refer to framework abstractions or other application components
through SpEL EvaluationContext extension model.
* Supports SpEL expressions into Text queries ({{TextQuery}}).
Some examples:
{code:java}
// Spring Data Repositories using different ignite instances on same JVM
@RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
public interface FlightRouteRepository extends IgniteRepository {
...
}
@RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
public interface PoiRepository extends IgniteRepository {
...
}
{code}
{code:java}
// named parameter
@Query(value = "SELECT * from #{#entityName} where email = :email")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// indexed parameters
@Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city =
?#{[1]}")
List searchUsersByCity(@Param("country") String country, @Param("city")
String city, Pageable pageable);
{code}
{code:java}
// ordered method parameters
@Query(value = "SELECT * from #{#entityName} where email = ?")
User searchUserByEmail(String email);
{code}
{code:java}
// Advanced SpEL expressions
@Query(value = "SELECT * from #{#entityName} where uuidCity =
?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
List searchUsersByCity(@Param("city") String city, Pageable pageable);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "email: #{#email}")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "#{#textToSearch}")
List searchUsersByText(@Param("textToSearch") String text, Pageable
pageable);
{code}
{code:java}
// textQuery - evaluated SpEL indexed parameter
@Query(textQuery = true, value = "#{[0]}")
List searchUsersByText(String textToSearch, Pageable pageable);
{code}
{code:java}
// Static Projection
@Query(value =
"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e USE
INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
+ "._key=e"
+ ".merchant WHERE e.origin = :origin and e.disabled =
:disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
List searchMerchantsByOrigin(@Param("origin") String origin,
@Param("disabled") boolean disabled);
{code}
{code:java}
// Dynamic Projection
@Query(value =
"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e USE
INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
+ "._key=e"
+ ".merchant WHERE e.origin = :origin and e.disabled =
:disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
List searchMerchantsByOrigin(Class projection, @Param("origin")
String origin, @Param("disabled") boolean disabled);
{code}
was:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements. Is there any ignite developer who can do the pull-request
process?. Thanks community!!
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) i
[jira] [Commented] (IGNITE-13170) Java thin client: Transactions functionality withLabel is broken
[
https://issues.apache.org/jira/browse/IGNITE-13170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141971#comment-17141971
]
Ivan Daschinskiy commented on IGNITE-13170:
---
[~alex_pl] Looks good to me, but because one test is a little bit rewrited, may
be it is good idea to restart suite metioned test belongs to
> Java thin client: Transactions functionality withLabel is broken
>
>
> Key: IGNITE-13170
> URL: https://issues.apache.org/jira/browse/IGNITE-13170
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer
> {code:java}
> @Test
> public void testTransactions1() throws Exception {
> try (Ignite ignite = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(getClientConfiguration()))
> {
> ClientCache cache = client.createCache(new
> ClientCacheConfiguration()
> .setName("cache")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> cache.put(1, "value1");
> try (ClientTransaction tx =
> client.transactions().withLabel("asdasda").txStart()) {
> cache.put(1, "value2");
> }
> assertEquals("value1", cache.get(1));
> }
> }
> {code}
> Root cause: a new instance of transactions facade is created when
> {{withLabel}} modificator is used. Transactions are registered in
> {{threadLocTxUid}} map of this instance, but when any cache operation is
> performed transaction is looked only at root {{threadLocTxUid}} map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13164) Thin client: Fix nodeIds format for execute compute tasks request
[
https://issues.apache.org/jira/browse/IGNITE-13164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141968#comment-17141968
]
Ignite TC Bot commented on IGNITE-13164:
{panel:title=Branch: [pull/7944/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5401887&buildTypeId=IgniteTests24Java8_RunAll]
> Thin client: Fix nodeIds format for execute compute tasks request
> --
>
> Key: IGNITE-13164
> URL: https://issues.apache.org/jira/browse/IGNITE-13164
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, each node id in thin client execute compute task request is
> written using 17 bytes (1 byte for type id and 16 bytes for UUID raw data).
> Since we don't need information about type id and node id can't be null we
> can write only UUID raw data as now implemented for service invoke request.
> Compute functionality is not released yet, so format can be changed without
> compatibility issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13012:
--
Attachment: (was: IGNITE-13012-patch.patch)
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13012:
--
Attachment: IGNITE-13012-patch.patch
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13012:
--
Attachment: IGNITE-13012-patch.patch
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Fix failure detection timeout. Simplify node ping routine.
[
https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13012:
--
Attachment: (was: IGNITE-13012-patch.patch)
> Fix failure detection timeout. Simplify node ping routine.
> --
>
> Key: IGNITE-13012
> URL: https://issues.apache.org/jira/browse/IGNITE-13012
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: IGNITE-13012-patch.patch
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Connection failure may not be detected within
> IgniteConfiguration.failureDetectionTimeout. Actual worst delay is:
> ServerImpl.CON_CHECK_INTERVAL + IgniteConfiguration.failureDetectionTimeout.
> Node ping routine is duplicated.
> We should fix:
> 1. Failure detection timeout should take in account last sent message.
> Current ping is bound to own time:
> {code:java}ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent{code}
> This is weird because any discovery message check connection.
> 2. Make connection check interval depend on failure detection timeout (FTD).
> Current value is a constant:
> {code:java}static int ServerImpls.CON_CHECK_INTERVAL = 500{code}
> 3. Remove additional, quickened connection checking. Once we do fix 1, this
> will become even more useless.
> Despite TCP discovery has a period of connection checking, it may send ping
> before this period exhausts. This premature ping relies also on the time of
> any received message for some reason.
> 4. Do not worry user with “Node seems disconnected” when everything is OK.
> Once we do fix 1 and 3, this will become even more useless.
> Node may log on INFO: “Local node seems to be disconnected from topology …”
> whereas it is not actually disconnected at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13031) .NET: SqlFieldsQuery as ContinuousQuery.InitialQuery
[ https://issues.apache.org/jira/browse/IGNITE-13031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13031: Release Note: .NET: Allow SqlFieldsQuery as ContinuousQuery.InitialQuery > .NET: SqlFieldsQuery as ContinuousQuery.InitialQuery > > > Key: IGNITE-13031 > URL: https://issues.apache.org/jira/browse/IGNITE-13031 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > SqlQuery has been deprecated in favor of SqlFieldsQuery, but ContinuousQuery > in Ignite.NET does not allow SqlFieldsQuery as InitialQuery. > Java API allows that, so we have to derive SqlFieldsQuery from QueryBase and > make it work. > The problem will arise when SqlFieldsQuery does not return _key & _val - see > how Java handles this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[ https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141923#comment-17141923 ] Sergey Chugunov commented on IGNITE-12111: -- [~ilyak], I addressed your comments in pull request and got green visa from bot - could you please take another look at my change? > Cluster ID and tag: properties to identify the cluster > -- > > Key: IGNITE-12111 > URL: https://issues.apache.org/jira/browse/IGNITE-12111 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > To improve cluster management capabilities two new properties of the cluster > are introduced: > # A unique cluster ID (may be either a random UUID or random IgniteUUID). > Generated upon cluster start and saved to the distributed metastorage. > Immutable. Persistent clusters must persist the value. In-memory clusters > should keep the generated ID in memory and regenerate it upon restart. > # Human-readable cluster tag. Generated by default to some random (but still > meaningful) string, may be changed by user. Again survives restart in > persistent clusters and is regenerated in in-memory clusters on every restart. > These properties are exposed to standard APIs: > # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user; > # JMX bean and control utility APIs to view ID and tag and change tag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13164) Thin client: Fix nodeIds format for execute compute tasks request
[
https://issues.apache.org/jira/browse/IGNITE-13164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141915#comment-17141915
]
Ignite TC Bot commented on IGNITE-13164:
{panel:title=Branch: [pull/7944/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5403017]]
* IgniteSpiTestSuite: GridTcpCommunicationSpiSslSelfTest.testSendToOneNode -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5401887&buildTypeId=IgniteTests24Java8_RunAll]
> Thin client: Fix nodeIds format for execute compute tasks request
> --
>
> Key: IGNITE-13164
> URL: https://issues.apache.org/jira/browse/IGNITE-13164
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, each node id in thin client execute compute task request is
> written using 17 bytes (1 byte for type id and 16 bytes for UUID raw data).
> Since we don't need information about type id and node id can't be null we
> can write only UUID raw data as now implemented for service invoke request.
> Compute functionality is not released yet, so format can be changed without
> compatibility issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13170) Java thin client: Transactions functionality withLabel is broken
[
https://issues.apache.org/jira/browse/IGNITE-13170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141914#comment-17141914
]
Ignite TC Bot commented on IGNITE-13170:
{panel:title=Branch: [pull/7951/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5409249&buildTypeId=IgniteTests24Java8_RunAll]
> Java thin client: Transactions functionality withLabel is broken
>
>
> Key: IGNITE-13170
> URL: https://issues.apache.org/jira/browse/IGNITE-13170
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer
> {code:java}
> @Test
> public void testTransactions1() throws Exception {
> try (Ignite ignite = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(getClientConfiguration()))
> {
> ClientCache cache = client.createCache(new
> ClientCacheConfiguration()
> .setName("cache")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> cache.put(1, "value1");
> try (ClientTransaction tx =
> client.transactions().withLabel("asdasda").txStart()) {
> cache.put(1, "value2");
> }
> assertEquals("value1", cache.get(1));
> }
> }
> {code}
> Root cause: a new instance of transactions facade is created when
> {{withLabel}} modificator is used. Transactions are registered in
> {{threadLocTxUid}} map of this instance, but when any cache operation is
> performed transaction is looked only at root {{threadLocTxUid}} map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13166) Flaky H2RowCachePageEvictionTest and IgniteCacheQueryH2IndexingLeakTest tests
[
https://issues.apache.org/jira/browse/IGNITE-13166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141910#comment-17141910
]
Ignite TC Bot commented on IGNITE-13166:
{panel:title=Branch: [pull/7947/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5402505&buildTypeId=IgniteTests24Java8_RunAll]
> Flaky H2RowCachePageEvictionTest and IgniteCacheQueryH2IndexingLeakTest tests
> --
>
> Key: IGNITE-13166
> URL: https://issues.apache.org/jira/browse/IGNITE-13166
> Project: Ignite
> Issue Type: Task
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have several tests on TC which considered flaky. Need to
> investigate and fix them.
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4422957309644246466&tab=testDetails]
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8791646325227962211&tab=testDetails]
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7378154946319099847&tab=testDetails]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141909#comment-17141909
]
Vyacheslav Koptilin commented on IGNITE-12986:
--
Hello [~alapin],
I have resolved all your comments. Please take a look at PR.
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12986:
-
Reviewer: Alexander Lapin
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141908#comment-17141908
]
Ignite TC Bot commented on IGNITE-12986:
{panel:title=Branch: [pull/7849/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5408452&buildTypeId=IgniteTests24Java8_RunAll]
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141889#comment-17141889 ] Manuel Núñez edited comment on IGNITE-13169 at 6/22/20, 10:26 AM: -- Please, take a look at IGNITE-13005. Supports different mechanism (Ignite instance name, Ignite configuration name and Ignite configuration file) to discover Ignite Instances. Also supports working with multiple Ignite Instances on same JVM. was (Author: mnusan): Please, take a look at IGNITE-13005. > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13005) Spring Data 2 - "JPA style" and working with multiple Ignite instances on same JVM
[
https://issues.apache.org/jira/browse/IGNITE-13005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Núñez updated IGNITE-13005:
--
Description:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements. Is there any ignite developer who can do the pull-request
process?. Thanks community!!
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) into SQL queries, declared using
{{@Param("myParam")}}
* Supports advanced parameter binding and SpEL expressions into SQL queries:
** *Template variables*:
*** {{#entityName}} - the simple class name of the domain entity
** *Method parameter expressions*: Parameters are exposed for indexed access
({{[0]}} is the first query method's param) or via the name declared using
{{@Param}}. The actual SpEL expression binding is triggered by {{?#}}. Example:
{{?#\{[0]\}} or {{?#\{#myParamName\}}}
** *Advanced SpEL expressions*: While advanced parameter binding is a very
useful feature, the real power of SpEL stems from the fact, that the
expressions can refer to framework abstractions or other application components
through SpEL EvaluationContext extension model.
* Supports SpEL expressions into Text queries ({{TextQuery}}).
Some examples:
{code:java}
// Spring Data Repositories using different ignite instances on same JVM
@RepositoryConfig(igniteInstance = "FLIGHTS_BBDD", cacheName = "ROUTES")
public interface FlightRouteRepository extends IgniteRepository {
...
}
@RepositoryConfig(igniteInstance = "GEO_BBDD", cacheName = "POIS")
public interface PoiRepository extends IgniteRepository {
...
}
{code}
{code:java}
// named parameter
@Query(value = "SELECT * from #{#entityName} where email = :email")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// indexed parameters
@Query(value = "SELECT * from #{#entityName} where country = ?#{[0] and city =
?#{[1]}")
List searchUsersByCity(@Param("country") String country, @Param("city")
String city, Pageable pageable);
{code}
{code:java}
// ordered method parameters
@Query(value = "SELECT * from #{#entityName} where email = ?")
User searchUserByEmail(String email);
{code}
{code:java}
// Advanced SpEL expressions
@Query(value = "SELECT * from #{#entityName} where uuidCity =
?#{mySpELFunctionsBean.cityNameToUUID(#city)}")
List searchUsersByCity(@Param("city") String city, Pageable pageable);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "email: #{#email}")
User searchUserByEmail(@Param("email") String email);
{code}
{code:java}
// textQuery - evaluated SpEL named parameter
@Query(textQuery = true, value = "#{#textToSearch}")
List searchUsersByText(@Param("textToSearch") String text, Pageable
pageable);
{code}
{code:java}
// textQuery - evaluated SpEL indexed parameter
@Query(textQuery = true, value = "#{[0]}")
List searchUsersByText(String textToSearch, Pageable pageable);
{code}
{code:java}
// Projection
@Query(value =
"SELECT DISTINCT m.id, m.name, m.logos FROM #{#entityName} e USE
INDEX (ORIGIN_IDX) INNER JOIN \"flightMerchants\".Merchant m ON m"
+ "._key=e"
+ ".merchant WHERE e.origin = :origin and e.disabled =
:disabled GROUP BY m.id, m.name, m.logos ORDER BY m.name")
List searchMerchantsByOrigin(Class projection, @Param("origin")
String origin, @Param("disabled") boolean disabled);
{code}
was:
I have it working for Spring Data 2 (2.7.6, 2.8.1) module with some interesting
improvements, but by now I don't have enough time to give it the attention it
requires, full unit/integration tests..., sorry a lot. ¿maybe any of you have
the time?. Thanks community!!
Code is 100% compatible with previous versions.
[https://github.com/hawkore/ignite-hk/tree/master/modules/spring-data-2.0]
* Supports multiple ignite instances on same JVM (@RepositoryConfig).
* Supports query tuning parameters in {{@Query}} annotation
* Supports projections
* Supports {{Page}} and {{Stream}} responses
* Supports Sql Fields Query resultset transformation into the domain entity
* Supports named parameters ({{:myParam}}) into SQL queries, declared using
{{@Param("myParam")}}
* Supports advanced parameter binding and SpEL expressions into SQL queries:
** *Template variables*:
*** {{#entityName}} - the simple class name of the domain entity
** *Method parameter expressions*: Parameters are exposed for indexed access
({{[0]}} is the first query method's param) or via the name declared using
{{@Param}}
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141889#comment-17141889 ] Manuel Núñez commented on IGNITE-13169: --- Please, take a look at IGNITE-13005. > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13151) Checkpointer code refactoring: extracting classes from GridCacheDatabaseSharedManager
[
https://issues.apache.org/jira/browse/IGNITE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141870#comment-17141870
]
Ignite TC Bot commented on IGNITE-13151:
{panel:title=Branch: [pull/7937/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5400343&buildTypeId=IgniteTests24Java8_RunAll]
> Checkpointer code refactoring: extracting classes from
> GridCacheDatabaseSharedManager
> -
>
> Key: IGNITE-13151
> URL: https://issues.apache.org/jira/browse/IGNITE-13151
> Project: Ignite
> Issue Type: Sub-task
> Components: persistence
>Reporter: Sergey Chugunov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Checkpointer is at the center of Ignite persistence subsystem and more people
> from the community understand it the better means it is more stable and more
> efficient.
> However for now checkpointer code sits inside of
> GridCacheDatabaseSharedManager class and is entangled with this higher-level
> and more general component.
> To take a step forward to more modular checkpointer we need to do two things:
> # Move checkpointer code outside database manager to a separate class.
> (That's what this ticket is about.)
> # Create a well-defined API of checkpointer that will allow us to create new
> implementations of checkpointer in the future. An example of this is new
> checkpointer implementation needed for defragmentation feature purposes.
> (Should be done in a separate ticket)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13078) С++: Add CMake build support
[ https://issues.apache.org/jira/browse/IGNITE-13078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141855#comment-17141855 ] Peter Ivanov commented on IGNITE-13078: --- Added to aitc-lin01_01 for tests. Check that build works at that agent. If OK — will install on other agents. > С++: Add CMake build support > > > Key: IGNITE-13078 > URL: https://issues.apache.org/jira/browse/IGNITE-13078 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.9 > > Attachments: ignite-13078-dynamic-odbc.patch, > ignite-13078-static-odbc.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, it is hard to build Ignite.C++. Different build processes for > windows and Linux, lack of building support on Mac OS X (a quite popular OS > among developers), absolutely not IDE support, except windows and only Visual > Studio is supported. > I’d suggest migrating to the CMake build system. It is very popular among > open source projects, and in The Apache Software Foundation too. Notable > users: Apache Mesos, Apache Zookeeper (C client offers CMake as an > alternative to autoconf and the only option on Windows), Apache Kafka > (librdkafka - C/C++ client), Apache Thrift. Popular column-oriented database > ClickHouse also uses CMake. > CMake is widely supported in many IDE’s on various platforms, notably Visual > Studio, CLion, Xcode, QtCreator, KDevelop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10708) SQL implement system view for partition states
[ https://issues.apache.org/jira/browse/IGNITE-10708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141835#comment-17141835 ] Aleksey Plekhanov commented on IGNITE-10708: [~nizhikov], thanks for the review! > SQL implement system view for partition states > -- > > Key: IGNITE-10708 > URL: https://issues.apache.org/jira/browse/IGNITE-10708 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-13 > Fix For: 2.9 > > Time Spent: 50m > Remaining Estimate: 0h > > Implement SQL system view to partition states in the cluster for each cache > group and each node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141833#comment-17141833 ] Semyon Danilov commented on IGNITE-13169: - Hello [~slava.koptilin], description provided! > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-13169: Description: At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or IgniteConfiguration instance bean) with specific name. There are couple of problems with that behavior: 1) We have a SpringBoot autoconfiguration module which creates bean with different name, so Ignite Spring Data won't work out of the box 2) That is, actually, not a Spring-way to do things: Spring prefers injecting by class, qualifiers like name and order should be used only when necessay I propose changing behavior to "getting bean by class and not by name" This won't require any user code changes, because we only remove restrictions on Ignite instance bean name was: At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or IgniteConfiguration instance bean) with specific name. There are couple of problems with that behavior: 1) We have a SpringBoot autoconfiguration module which creates bean with different name, so Ignite Spring Data won't work out of the box 2) That is, actually, not a Spring-way to do things: Spring prefers injecting by class, qualifiers like name and order should be used only when necessay I propose changing behavior to "getting bean by class and not by name" > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-13169: Description: At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or IgniteConfiguration instance bean) with specific name. There are couple of problems with that behavior: 1) We have a SpringBoot autoconfiguration module which creates bean with different name, so Ignite Spring Data won't work out of the box 2) That is, actually, not a Spring-way to do things: Spring prefers injecting by class, qualifiers like name and order should be used only when necessay I propose changing behavior to "getting bean by class and not by name" was:At the moment Repository Factory Bean > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers injecting > by class, qualifiers like name and order should be used only when necessay > I propose changing behavior to "getting bean by class and not by name" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-13169: Description: At the moment Repository Factory Bean > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > At the moment Repository Factory Bean -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13167) Cache Store fails to close connection: writeBehind + TRANSACTIONAL + readThrough
[ https://issues.apache.org/jira/browse/IGNITE-13167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-13167: Assignee: Vyacheslav Koptilin > Cache Store fails to close connection: writeBehind + TRANSACTIONAL + > readThrough > > > Key: IGNITE-13167 > URL: https://issues.apache.org/jira/browse/IGNITE-13167 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Ilya Kasnacheev >Assignee: Vyacheslav Koptilin >Priority: Critical > > Please see referenced mailing list thread. > If there is an ongoing transactional (cache is transactional, put uses an > implicit transaction, tx != null) then > org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter#loadFromStore > will not call sessionEnd() - see sessionEnd0() method. > If write behind is also enabled, then cache store is not invoked during the > operation and connection will never be closed. > So, a combination of TRANSACTIONAL cache, implicit transaction, loadFromCache > and write behind will leak a connection every time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12111) Cluster ID and tag: properties to identify the cluster
[
https://issues.apache.org/jira/browse/IGNITE-12111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141782#comment-17141782
]
Ignite TC Bot commented on IGNITE-12111:
{panel:title=Branch: [pull/7922/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5379952&buildTypeId=IgniteTests24Java8_RunAll]
> Cluster ID and tag: properties to identify the cluster
> --
>
> Key: IGNITE-12111
> URL: https://issues.apache.org/jira/browse/IGNITE-12111
> Project: Ignite
> Issue Type: New Feature
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> To improve cluster management capabilities two new properties of the cluster
> are introduced:
> # A unique cluster ID (may be either a random UUID or random IgniteUUID).
> Generated upon cluster start and saved to the distributed metastorage.
> Immutable. Persistent clusters must persist the value. In-memory clusters
> should keep the generated ID in memory and regenerate it upon restart.
> # Human-readable cluster tag. Generated by default to some random (but still
> meaningful) string, may be changed by user. Again survives restart in
> persistent clusters and is regenerated in in-memory clusters on every restart.
> These properties are exposed to standard APIs:
> # EVT_CLUSTER_TAG_CHANGED event generated when tag is changed by user;
> # JMX bean and control utility APIs to view ID and tag and change tag.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13172) Module ignite-scalar compilation error on JDK 11+
Aleksey Plekhanov created IGNITE-13172:
--
Summary: Module ignite-scalar compilation error on JDK 11+
Key: IGNITE-13172
URL: https://issues.apache.org/jira/browse/IGNITE-13172
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Module ignite-scalar can't be compiled by maven on JDK 11+.
There is an error on scala-maven-plugin:3.3.2:compile phase:
{noformat}
[ERROR] error: java.lang.NoClassDefFoundError: javax/tools/ToolProvider
[INFO] at
scala.reflect.io.JavaToolsPlatformArchive.iterator(ZipArchive.scala:301)
[INFO] at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
[INFO] at scala.reflect.io.AbstractFile.foreach(AbstractFile.scala:92)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11393) Create IgniteLinkTaglet.toString() implementation for Java9+
[ https://issues.apache.org/jira/browse/IGNITE-11393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141763#comment-17141763 ] Aleksey Plekhanov commented on IGNITE-11393: [~amashenkov], thanks for your comments. I will return to this ticket in a week. > Create IgniteLinkTaglet.toString() implementation for Java9+ > > > Key: IGNITE-11393 > URL: https://issues.apache.org/jira/browse/IGNITE-11393 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Aleksey Plekhanov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > New implementation was added according to the new Java API for Javadoc. > But the main method kept empty, need to implement toString() to process > IgniteLink annotation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13170) Java thin client: Transactions functionality withLabel is broken
[
https://issues.apache.org/jira/browse/IGNITE-13170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13170:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Java thin client: Transactions functionality withLabel is broken
>
>
> Key: IGNITE-13170
> URL: https://issues.apache.org/jira/browse/IGNITE-13170
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer
> {code:java}
> @Test
> public void testTransactions1() throws Exception {
> try (Ignite ignite = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(getClientConfiguration()))
> {
> ClientCache cache = client.createCache(new
> ClientCacheConfiguration()
> .setName("cache")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> cache.put(1, "value1");
> try (ClientTransaction tx =
> client.transactions().withLabel("asdasda").txStart()) {
> cache.put(1, "value2");
> }
> assertEquals("value1", cache.get(1));
> }
> }
> {code}
> Root cause: a new instance of transactions facade is created when
> {{withLabel}} modificator is used. Transactions are registered in
> {{threadLocTxUid}} map of this instance, but when any cache operation is
> performed transaction is looked only at root {{threadLocTxUid}} map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13170) Java thin client: Transactions functionality withLabel is broken
[
https://issues.apache.org/jira/browse/IGNITE-13170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13170:
---
Component/s: thin client
> Java thin client: Transactions functionality withLabel is broken
>
>
> Key: IGNITE-13170
> URL: https://issues.apache.org/jira/browse/IGNITE-13170
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer
> {code:java}
> @Test
> public void testTransactions1() throws Exception {
> try (Ignite ignite = Ignition.start(Config.getServerConfiguration());
> IgniteClient client = Ignition.startClient(getClientConfiguration()))
> {
> ClientCache cache = client.createCache(new
> ClientCacheConfiguration()
> .setName("cache")
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL));
> cache.put(1, "value1");
> try (ClientTransaction tx =
> client.transactions().withLabel("asdasda").txStart()) {
> cache.put(1, "value2");
> }
> assertEquals("value1", cache.get(1));
> }
> }
> {code}
> Root cause: a new instance of transactions facade is created when
> {{withLabel}} modificator is used. Transactions are registered in
> {{threadLocTxUid}} map of this instance, but when any cache operation is
> performed transaction is looked only at root {{threadLocTxUid}} map.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
