[jira] [Created] (IGNITE-4335) Implement cluster ACTIVE/INACTIVE state
Alexey Goncharuk created IGNITE-4335: Summary: Implement cluster ACTIVE/INACTIVE state Key: IGNITE-4335 URL: https://issues.apache.org/jira/browse/IGNITE-4335 Project: Ignite Issue Type: New Feature Components: general Reporter: Alexey Goncharuk Fix For: 2.0 I think it might be beneficial in some cases to start cluster in some form of inactive state. In this case we can skip start of many managers and processors (basically, start only discovery + communication), which should speed up the cluster start process. Once all nodes are started, an API call or a shell command can activate the cluster and start all managers in one pass. This should significantly reduce traffic, affinity calculations, etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3477) Rework offheap storage
[ https://issues.apache.org/jira/browse/IGNITE-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-3477: - Assignee: (was: Alexey Goncharuk) > Rework offheap storage > -- > > Key: IGNITE-3477 > URL: https://issues.apache.org/jira/browse/IGNITE-3477 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Alexey Goncharuk > Labels: important > Fix For: 2.0 > > > Current (Ignite 1.x) implementation of cache storage relies on a tiered > approach where cache entry can be located in one of the three storage areas: > on-heap, off-heap memory and swap. It leads to the following disadvantages: > * Entry constantly moves from one storage area to another which leads to a > complex code (for example, swap/unswap listeners for queries and rebalancing) > * It is not possible to set per-cache memory limit > * Off-heap indexes require on-heap row cache. If this cache is small, > performance becomes very poor > * Continuous put/remove operations with OFFHEAP_TIERED mode lead to > uncontrollable memory fragmentation > We can reapproach the cache storage and base it on a concept of page memory. > We will allocate several memory pools of pages of fixed size and assign each > cache to one of the memory pools. All storage data structures should operate > on memory pages, the main storage will be always off-heap with an optional > on-heap cache. > This gives us the following benefits: > * Flexible and precise per-cache memory limit > * Transparent swap: we can allocate page memory over a memory-mapped file > and OS will take care of swapping > * Getting rid of on-heap cache for off-heap SQL indexes > * Ability to take a cluster-wide data snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4336) Manual rebalance can't be requested twice
Dmitriy Setrakyan created IGNITE-4336: - Summary: Manual rebalance can't be requested twice Key: IGNITE-4336 URL: https://issues.apache.org/jira/browse/IGNITE-4336 Project: Ignite Issue Type: Bug Components: cache Reporter: Dmitriy Setrakyan Fix For: 2.0 Manual rebalancing with ignite.rebalance().get() immediately returns on second try without requesting rebalancing. How to reproduce: Use branch ignite-gg-rebalance-test revision:c4f192e276ff4d0dad39611a60a39c21594c7320 Run 3 Ignite nodes with the params: 1) 200 0 1073741824 c:/data/db 2) 200 0 1073741824 c:/data/db 3) 200 0 1073741824 c:/data/db 10 1024 Wait until data is loaded in 3-rd node. Rebalance is requested on first try and immediately returns on second. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4336) Manual rebalance can't be requested twice
[ https://issues.apache.org/jira/browse/IGNITE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-4336: -- Description: Manual rebalancing with ignite.rebalance().get() immediately returns on second try without requesting rebalancing. How to reproduce: Run 3 Ignite nodes with the params: 1) 200 0 1073741824 c:/data/db 2) 200 0 1073741824 c:/data/db 3) 200 0 1073741824 c:/data/db 10 1024 Wait until data is loaded in 3-rd node. Rebalance is requested on first try and immediately returns on second. was: Manual rebalancing with ignite.rebalance().get() immediately returns on second try without requesting rebalancing. How to reproduce: Use branch ignite-gg-rebalance-test revision:c4f192e276ff4d0dad39611a60a39c21594c7320 Run 3 Ignite nodes with the params: 1) 200 0 1073741824 c:/data/db 2) 200 0 1073741824 c:/data/db 3) 200 0 1073741824 c:/data/db 10 1024 Wait until data is loaded in 3-rd node. Rebalance is requested on first try and immediately returns on second. > Manual rebalance can't be requested twice > - > > Key: IGNITE-4336 > URL: https://issues.apache.org/jira/browse/IGNITE-4336 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Setrakyan > Fix For: 2.0 > > > Manual rebalancing with ignite.rebalance().get() immediately returns on > second try without requesting rebalancing. > How to reproduce: > Run 3 Ignite nodes with the params: > 1) 200 0 1073741824 c:/data/db > 2) 200 0 1073741824 c:/data/db > 3) 200 0 1073741824 c:/data/db 10 1024 > Wait until data is loaded in 3-rd node. > Rebalance is requested on first try and immediately returns on second. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4336) Manual rebalance can't be requested twice
[ https://issues.apache.org/jira/browse/IGNITE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-4336: -- Description: Manual rebalancing with ignite.rebalance().get() immediately returns on second try without requesting rebalancing. The reason is that the future that was created for the first rebalance, is reused for the consecutive attempts. We must have a new future for every rebalance attempt. was: Manual rebalancing with ignite.rebalance().get() immediately returns on second try without requesting rebalancing. How to reproduce: Run 3 Ignite nodes with the params: 1) 200 0 1073741824 c:/data/db 2) 200 0 1073741824 c:/data/db 3) 200 0 1073741824 c:/data/db 10 1024 Wait until data is loaded in 3-rd node. Rebalance is requested on first try and immediately returns on second. > Manual rebalance can't be requested twice > - > > Key: IGNITE-4336 > URL: https://issues.apache.org/jira/browse/IGNITE-4336 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Setrakyan > Fix For: 2.0 > > > Manual rebalancing with ignite.rebalance().get() immediately returns on > second try without requesting rebalancing. The reason is that the future that > was created for the first rebalance, is reused for the consecutive attempts. > We must have a new future for every rebalance attempt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4336) Manual rebalance can't be requested twice
[ https://issues.apache.org/jira/browse/IGNITE-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-4336: -- Assignee: Ilya Lantukh > Manual rebalance can't be requested twice > - > > Key: IGNITE-4336 > URL: https://issues.apache.org/jira/browse/IGNITE-4336 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Dmitriy Setrakyan >Assignee: Ilya Lantukh > Fix For: 2.0 > > > Manual rebalancing with ignite.rebalance().get() immediately returns on > second try without requesting rebalancing. The reason is that the future that > was created for the first rebalance, is reused for the consecutive attempts. > We must have a new future for every rebalance attempt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins
Alexey Goncharuk created IGNITE-4337:
Summary: Introduce persistence interface to allow build reliable
persistence plugins
Key: IGNITE-4337
URL: https://issues.apache.org/jira/browse/IGNITE-4337
Project: Ignite
Issue Type: Sub-task
Components: general
Reporter: Alexey Goncharuk
Fix For: 2.0
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgniteWriteAheadLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if WAL will perform fair syncs on fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When WAL manager is started, it will skip
logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(WALPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return WALPointer that may be passed to {@link #fsync(WALPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public WALPointer log(WALRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(WALPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional WAL pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteException If failed to start iteration.
* @throws StorageException If IO error occurred while reading WAL entries.
*/
public WALIterator replay(WALPointer start) throws IgniteCheckedException,
StorageException;
/**
* Gives a hint to WAL manager to clear entries logged before the given
pointer. Some entries before the
* the given pointer will be kept because there is a configurable WAL
history size. Those entries may be used
* for partial partition rebalancing.
*
* @param ptr Pointer for which it is safe to clear the log.
* @return Number of deleted WAL segments.
*/
public int truncate(WALPointer ptr);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins
[
https://issues.apache.org/jira/browse/IGNITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-4337:
-
Description:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgnitePersistenceLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if WAL will perform fair syncs on fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When WAL manager is started, it will skip
logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(WALPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return WALPointer that may be passed to {@link #fsync(WALPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public WALPointer log(WALRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(WALPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional WAL pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteException If failed to start iteration.
* @throws StorageException If IO error occurred while reading WAL entries.
*/
public WALIterator replay(WALPointer start) throws IgniteCheckedException,
StorageException;
/**
* Gives a hint to WAL manager to clear entries logged before the given
pointer. Some entries before the
* the given pointer will be kept because there is a configurable WAL
history size. Those entries may be used
* for partial partition rebalancing.
*
* @param ptr Pointer for which it is safe to clear the log.
* @return Number of deleted WAL segments.
*/
public int truncate(WALPointer ptr);
}
{code}
was:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgniteWriteAheadLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if WAL will perform fair syncs on fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When WAL manager is started, it will skip
logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(WALPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return WALPointer that may be passed to {@link #fsync(WALPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public WALPointer log(WALRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(WALPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional WAL pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteException If failed to start iteration.
[jira] [Updated] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins
[
https://issues.apache.org/jira/browse/IGNITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-4337:
-
Description:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgnitePersistenceLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if persistence manager will perform fair syncs on
fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When persistence manager is started, it
will skip logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(LogPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return LogPointer that may be passed to {@link #fsync(LogPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public LogPointer log(LogRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(LogPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional log pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteException If failed to start iteration.
* @throws StorageException If IO error occurred while reading WAL entries.
*/
public LogIterator replay(LogPointer start) throws IgniteCheckedException,
StorageException;
/**
* Gives a hint to persistence manager to clear entries logged before the
given pointer. Some entries before the
* the given pointer will be kept because there is a configurable log
history size. Those entries may be used
* for partial partition rebalancing.
*
* @param ptr Pointer for which it is safe to clear the log.
* @return Number of deleted log segments.
*/
public int truncate(LogPointer ptr);
}
{code}
was:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgnitePersistenceLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if WAL will perform fair syncs on fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When WAL manager is started, it will skip
logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(WALPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return WALPointer that may be passed to {@link #fsync(WALPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public WALPointer log(WALRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(WALPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional WAL pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteExceptio
[jira] [Updated] (IGNITE-4337) Introduce persistence interface to allow build reliable persistence plugins
[
https://issues.apache.org/jira/browse/IGNITE-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-4337:
-
Description:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgnitePersistenceLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if persistence manager will perform fair syncs on
fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When persistence manager is started, it
will skip logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(LogPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return LogPointer that may be passed to {@link #fsync(LogPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public LogPointer log(LogRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(LogPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional log pointer from which to start iteration.
* @return Records iterator.
* @throws IgniteException If failed to start iteration.
* @throws StorageException If IO error occurred while reading log entries.
*/
public LogIterator replay(LogPointer start) throws IgniteCheckedException,
StorageException;
/**
* Gives a hint to persistence manager to clear entries logged before the
given pointer. Some entries before the
* the given pointer will be kept because there is a configurable log
history size. Those entries may be used
* for partial partition rebalancing.
*
* @param ptr Pointer for which it is safe to clear the log.
* @return Number of deleted log segments.
*/
public int truncate(LogPointer ptr);
}
{code}
was:
If page memory interface is introduced, it may be possible to build a
persistence layer around this architecture. I think we should add some form of
persistence logging to allow us build a crash-resistant system in future.
Something like
{code}
public interface IgnitePersistenceLogManager extends GridCacheSharedManager {
/**
* @return {@code true} If we have to always write full pages.
*/
public boolean isAlwaysWriteFullPages();
/**
* @return {@code true} if persistence manager will perform fair syncs on
fsync call.
*/
public boolean isFullSync();
/**
* Resumes logging after start. When persistence manager is started, it
will skip logging any updates until this
* method is called to avoid logging changes induced by the state restore
procedure.
*/
public void resumeLogging(LogPointer lastWrittenPtr) throws
IgniteCheckedException;
/**
* Appends the given log entry to the write-ahead log.
*
* @param entry entry to log.
* @return LogPointer that may be passed to {@link #fsync(LogPointer)}
method to make sure the record is
* written to the log.
* @throws IgniteCheckedException If failed to construct log entry.
* @throws StorageException If IO error occurred while writing log entry.
*/
public LogPointer log(LogRecord entry) throws IgniteCheckedException,
StorageException;
/**
* Makes sure that all log entries written to the log up until the
specified pointer are actually persisted to
* the underlying storage.
*
* @param ptr Optional pointer to sync. If {@code null}, will sync up to
the latest record.
* @throws IgniteCheckedException If
* @throws StorageException
*/
public void fsync(LogPointer ptr) throws IgniteCheckedException,
StorageException;
/**
* Invoke this method to iterate over the written log entries.
*
* @param start Optional log pointer from which to start iteration.
* @return Records iterator.
[jira] [Assigned] (IGNITE-4321) Cassandra modules
[
https://issues.apache.org/jira/browse/IGNITE-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov reassigned IGNITE-4321:
Assignee: Alexey Kuznetsov
> Cassandra modules
> -
>
> Key: IGNITE-4321
> URL: https://issues.apache.org/jira/browse/IGNITE-4321
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> Binary fabric edition now has following modules:
> {noformat}
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:13 964 README.txt
>1 файлов964 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-serializers
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1353 231 asm-5.0.3.jar
> 25.11.2016 22:1312 181
> ignite-cassandra-serializers-1.8.0-QASK2502.jar
> 25.11.2016 22:13 285 211 kryo-3.0.3.jar
> 25.11.2016 22:13 licenses
> 25.11.2016 22:13 5 711 minlog-1.3.0.jar
> 25.11.2016 22:1341 755 objenesis-2.1.jar
> 25.11.2016 22:13 1 345 README.txt
> 25.11.2016 22:1320 738 reflectasm-1.10.1.jar
>7 файлов420 172 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-serializers\licenses
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1311 358 apache-2.0.txt
> 25.11.2016 22:13 1 857 ignite-cassandra-serializers-licenses.txt
>2 файлов 13 215 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-store
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:13 990 392 cassandra-driver-core-3.0.0.jar
> 25.11.2016 22:13 232 019 commons-beanutils-1.8.3.jar
> 25.11.2016 22:13 2 308 517 guava-19.0.jar
> 25.11.2016 22:1391 897 ignite-cassandra-store-1.8.0-QASK2502.jar
> 25.11.2016 22:13 licenses
> 25.11.2016 22:1385 448 metrics-core-3.0.2.jar
> 25.11.2016 22:13 196 881 netty-buffer-4.0.33.Final.jar
> 25.11.2016 22:13 145 779 netty-codec-4.0.33.Final.jar
> 25.11.2016 22:13 441 447 netty-common-4.0.33.Final.jar
> 25.11.2016 22:13 272 139 netty-handler-4.0.33.Final.jar
> 25.11.2016 22:13 349 164 netty-transport-4.0.33.Final.jar
> 25.11.2016 22:13 1 228 README.txt
> 11 файлов 5 114 911 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-store\licenses
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1311 358 apache-2.0.txt
> 25.11.2016 22:13 294 ignite-cassandra-store-licenses.txt
>2 файлов 11 652 байт
> {noformat}
> I suppose that {{ignite-cassandra}} directory must be removed and rest of
> Cassandra modules should be joined into one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-4334) DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to replicated cache
[
https://issues.apache.org/jira/browse/IGNITE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko reassigned IGNITE-4334:
---
Assignee: Alexander Paschenko
> DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to
> replicated cache
> -
>
> Key: IGNITE-4334
> URL: https://issues.apache.org/jira/browse/IGNITE-4334
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> INSERT INTO SELECT FROM statement fails if executed on a replicated cache and
> used partitioned cache as data source:
> {code:title=test.java|borderStyle=solid}
> public static void main(String[] args) throws Exception {
> Ignition.setClientMode(true);
> final Long PRELOAD_NUM = 1_000L;
> List cacheNames = Arrays.asList(
> "tx-part-full-sync",
> "tx-repl-full-sync",
> );
> String srcCache = null;
> try (Ignite ig = Ignition.start("examples/config/ext-sql.xml")) {
> for (String cacheName : cacheNames) {
> //ig.cache(cacheName).query(new SqlFieldsQuery("delete from
> AllTypes"));
> if (srcCache == null) {
> // data preloading here
>// .
> srcCache = cacheName;
> }
> else {
> ig.cache(cacheName).query(new SqlFieldsQuery("insert into
> AllTypes (_key, _val) select _key, _val from \"" + srcCache + "\".AllTypes"));
> }
> System.out.println("The cache size " + cacheName + ": " +
> ig.cache(cacheName).sizeLong());
> }
> }
> {code}
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=tx-repl-full-sync, pCache=tx-part-full-sync]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:700)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:282)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:155)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4334) DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to replicated cache
[
https://issues.apache.org/jira/browse/IGNITE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708038#comment-15708038
]
Alexander Paschenko commented on IGNITE-4334:
-
Problem is cross cache subquery. Won't fix as we don't support such SELECTs
either - please try this and see for yourself that it fails:
{code:java}
ig.cache("tx-repl-full-sync").query(new SqlFieldsQuery("select _key, _val from
\"tx-part-full-sync\".AllTypes")).getAll();
{code}
> DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to
> replicated cache
> -
>
> Key: IGNITE-4334
> URL: https://issues.apache.org/jira/browse/IGNITE-4334
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> INSERT INTO SELECT FROM statement fails if executed on a replicated cache and
> used partitioned cache as data source:
> {code:title=test.java|borderStyle=solid}
> public static void main(String[] args) throws Exception {
> Ignition.setClientMode(true);
> final Long PRELOAD_NUM = 1_000L;
> List cacheNames = Arrays.asList(
> "tx-part-full-sync",
> "tx-repl-full-sync",
> );
> String srcCache = null;
> try (Ignite ig = Ignition.start("examples/config/ext-sql.xml")) {
> for (String cacheName : cacheNames) {
> //ig.cache(cacheName).query(new SqlFieldsQuery("delete from
> AllTypes"));
> if (srcCache == null) {
> // data preloading here
>// .
> srcCache = cacheName;
> }
> else {
> ig.cache(cacheName).query(new SqlFieldsQuery("insert into
> AllTypes (_key, _val) select _key, _val from \"" + srcCache + "\".AllTypes"));
> }
> System.out.println("The cache size " + cacheName + ": " +
> ig.cache(cacheName).sizeLong());
> }
> }
> {code}
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=tx-repl-full-sync, pCache=tx-part-full-sync]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:700)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:282)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:155)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-4334) DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to replicated cache
[
https://issues.apache.org/jira/browse/IGNITE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko resolved IGNITE-4334.
-
Resolution: Won't Fix
> DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to
> replicated cache
> -
>
> Key: IGNITE-4334
> URL: https://issues.apache.org/jira/browse/IGNITE-4334
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> INSERT INTO SELECT FROM statement fails if executed on a replicated cache and
> used partitioned cache as data source:
> {code:title=test.java|borderStyle=solid}
> public static void main(String[] args) throws Exception {
> Ignition.setClientMode(true);
> final Long PRELOAD_NUM = 1_000L;
> List cacheNames = Arrays.asList(
> "tx-part-full-sync",
> "tx-repl-full-sync",
> );
> String srcCache = null;
> try (Ignite ig = Ignition.start("examples/config/ext-sql.xml")) {
> for (String cacheName : cacheNames) {
> //ig.cache(cacheName).query(new SqlFieldsQuery("delete from
> AllTypes"));
> if (srcCache == null) {
> // data preloading here
>// .
> srcCache = cacheName;
> }
> else {
> ig.cache(cacheName).query(new SqlFieldsQuery("insert into
> AllTypes (_key, _val) select _key, _val from \"" + srcCache + "\".AllTypes"));
> }
> System.out.println("The cache size " + cacheName + ": " +
> ig.cache(cacheName).sizeLong());
> }
> }
> {code}
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=tx-repl-full-sync, pCache=tx-part-full-sync]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:700)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:282)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:155)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
Alexander Paschenko created IGNITE-4338: --- Summary: Cross-schema SQL SELECT on partitioned cache fails for no good reason Key: IGNITE-4338 URL: https://issues.apache.org/jira/browse/IGNITE-4338 Project: Ignite Issue Type: Bug Components: SQL Affects Versions: 1.8 Reporter: Alexander Paschenko Fix For: 2.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3292) Yardstick: add logging of preloading progress
[ https://issues.apache.org/jira/browse/IGNITE-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708099#comment-15708099 ] Sergey Kozlov commented on IGNITE-3292: --- More useful to introduce an option that will force to print out number of entries for all non-system caches. It will help to detect deadlocks/slowdown during data preloading. > Yardstick: add logging of preloading progress > - > > Key: IGNITE-3292 > URL: https://issues.apache.org/jira/browse/IGNITE-3292 > Project: Ignite > Issue Type: Wish > Components: yardstick >Reporter: Ksenia Rybakova > Fix For: 1.9 > > > Please, add logging of preloading progress. This is really useful when we > load a lot of entries or they are large. > For instance: "Preloading: 200 of 1000 loaded". > Also adding an option that controls frequency of such output makes sense. For > instance, this might be a step (number of entries loaded) - if entries are > large, we set small step, if entries are integers, the step will be large. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4334) DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to replicated cache
[
https://issues.apache.org/jira/browse/IGNITE-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708104#comment-15708104
]
Alexander Paschenko commented on IGNITE-4334:
-
Created proper issue for this actual problem: IGNITE-4338
> DML: INSERT INTO SELECT FROM statement fails if copy from partitioned to
> replicated cache
> -
>
> Key: IGNITE-4334
> URL: https://issues.apache.org/jira/browse/IGNITE-4334
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Alexander Paschenko
> Fix For: 1.8
>
>
> INSERT INTO SELECT FROM statement fails if executed on a replicated cache and
> used partitioned cache as data source:
> {code:title=test.java|borderStyle=solid}
> public static void main(String[] args) throws Exception {
> Ignition.setClientMode(true);
> final Long PRELOAD_NUM = 1_000L;
> List cacheNames = Arrays.asList(
> "tx-part-full-sync",
> "tx-repl-full-sync",
> );
> String srcCache = null;
> try (Ignite ig = Ignition.start("examples/config/ext-sql.xml")) {
> for (String cacheName : cacheNames) {
> //ig.cache(cacheName).query(new SqlFieldsQuery("delete from
> AllTypes"));
> if (srcCache == null) {
> // data preloading here
>// .
> srcCache = cacheName;
> }
> else {
> ig.cache(cacheName).query(new SqlFieldsQuery("insert into
> AllTypes (_key, _val) select _key, _val from \"" + srcCache + "\".AllTypes"));
> }
> System.out.println("The cache size " + cacheName + ": " +
> ig.cache(cacheName).sizeLong());
> }
> }
> {code}
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=tx-repl-full-sync, pCache=tx-part-full-sync]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:700)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:282)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:155)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryTwoStep(IgniteH2Indexing.java:1266)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:812)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:1777)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryTwoStep(GridQueryProcessor.java:810)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:749)
> at
> org.apache.ignite.examples.datagrid.ExtSqlExample.main(ExtSqlExample.java:221)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708102#comment-15708102
]
Alexander Paschenko commented on IGNITE-4338:
-
Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following
operation fails:
{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
\"partitioned\".SomeType")).getAll();
{code}
Exception is as follows:
{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on
replicated cache should not contain JOINs with partitioned tables
[rCache=replicated, pCache=partitioned]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
...
{noformat}
The reason is that during query analysis
({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called
on) as participating in the query which is clearly not true in the above
example. Then we add to the query the schema it actually used (it's the cache
named *partitioned* in this case), and resulting two-step query looks as if its
SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we don't
support for now.
Will consult Sergi about what to do next. According to Vlad, this should not
affect the release in any way and thus won't be fixed in 1.8.
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4338:
Comment: was deleted
(was: Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following
operation fails:
{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
\"partitioned\".SomeType")).getAll();
{code}
Exception is as follows:
{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on
replicated cache should not contain JOINs with partitioned tables
[rCache=replicated, pCache=partitioned]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
...
{noformat}
The reason is that during query analysis
({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called
on) as participating in the query which is clearly not true in the above
example. Then we add to the query the schema it actually used (it's the cache
named *partitioned* in this case), and resulting two-step query looks as if its
SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we don't
support for now.
Will consult Sergi about what to do next. According to Vlad, this should not
affect the release in any way and thus won't be fixed in 1.8.)
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following
> operation fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
> \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=replicated, pCache=partitioned]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
> ...
> {noformat}
> The reason is that during query analysis
> ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
> we always deem leftmost cache (the one that the {{query}} method was called
> on) as participating in the query which is clearly not true in the above
> example. Then we add to the query the schema it actually used (it's the cache
> named *partitioned* in this case), and resulting two-step query looks as if
> its SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we
> don't support for now.
> Will consult Sergi about what to do next. According to Vlad, this should not
> affect the release in any way and thus won't be fixed in 1.8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4338:
Description:
Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following
operation fails:
{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
\"partitioned\".SomeType")).getAll();
{code}
Exception is as follows:
{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on
replicated cache should not contain JOINs with partitioned tables
[rCache=replicated, pCache=partitioned]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
...
{noformat}
The reason is that during query analysis
({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called
on) as participating in the query which is clearly not true in the above
example. Then we add to the query the schema it actually used (it's the cache
named *partitioned* in this case), and resulting two-step query looks as if its
SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we don't
support for now.
Will consult Sergi about what to do next. According to Vlad, this should not
affect the release in any way and thus won't be fixed in 1.8.
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following
> operation fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
> \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=replicated, pCache=partitioned]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
> ...
> {noformat}
> The reason is that during query analysis
> ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
> we always deem leftmost cache (the one that the {{query}} method was called
> on) as participating in the query which is clearly not true in the above
> example. Then we add to the query the schema it actually used (it's the cache
> named *partitioned* in this case), and resulting two-step query looks as if
> its SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we
> don't support for now.
> Will consult Sergi about what to do next. According to Vlad, this should not
> affect the release in any way and thus won't be fixed in 1.8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4338:
Description:
Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following
operation fails:
{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
\"partitioned\".SomeType")).getAll();
{code}
Exception is as follows:
{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on
replicated cache should not contain JOINs with partitioned tables
[rCache=replicated, pCache=partitioned]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
...
{noformat}
The reason is that during query analysis
({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called
on) as participating in the query which is clearly not true in the above
example. Then we add to the query the schema that it actually uses (it's the
cache named *partitioned* in this case), and resulting two-step query looks as
if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we
don't support for now.
Will consult Sergi about what to do next. According to Vlad, this should not
affect the release in any way and thus won't be fixed in 1.8.
was:
Inspired by IGNITE-4334.
Suppose we have two caches, one partitioned and one replicated. The following
operation fails:
{code:java}
ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
\"partitioned\".SomeType")).getAll();
{code}
Exception is as follows:
{noformat}
Exception in thread "main" javax.cache.CacheException: Queries running on
replicated cache should not contain JOINs with partitioned tables
[rCache=replicated, pCache=partitioned]
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
...
{noformat}
The reason is that during query analysis
({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
we always deem leftmost cache (the one that the {{query}} method was called
on) as participating in the query which is clearly not true in the above
example. Then we add to the query the schema it actually used (it's the cache
named *partitioned* in this case), and resulting two-step query looks as if its
SQL contained {{JOIN}} on *partitioned* and *replicated* caches which we don't
support for now.
Will consult Sergi about what to do next. According to Vlad, this should not
affect the release in any way and thus won't be fixed in 1.8.
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
> Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following
> operation fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
> \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=replicated, pCache=partitioned]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:
[jira] [Updated] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-4338:
Assignee: Sergi Vladykin (was: Alexander Paschenko)
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Sergi Vladykin
> Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following
> operation fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
> \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=replicated, pCache=partitioned]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
> ...
> {noformat}
> The reason is that during query analysis
> ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
> we always deem leftmost cache (the one that the {{query}} method was called
> on) as participating in the query which is clearly not true in the above
> example. Then we add to the query the schema that it actually uses (it's the
> cache named *partitioned* in this case), and resulting two-step query looks
> as if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches
> which we don't support for now.
> Will consult Sergi about what to do next. According to Vlad, this should not
> affect the release in any way and thus won't be fixed in 1.8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-4338) Cross-schema SQL SELECT on partitioned cache fails for no good reason
[
https://issues.apache.org/jira/browse/IGNITE-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko reassigned IGNITE-4338:
---
Assignee: Alexander Paschenko
> Cross-schema SQL SELECT on partitioned cache fails for no good reason
> -
>
> Key: IGNITE-4338
> URL: https://issues.apache.org/jira/browse/IGNITE-4338
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.0
>
>
> Inspired by IGNITE-4334.
> Suppose we have two caches, one partitioned and one replicated. The following
> operation fails:
> {code:java}
> ignite.cache("replicated").query(new SqlFieldsQuery("select _key, _val from
> \"partitioned\".SomeType")).getAll();
> {code}
> Exception is as follows:
> {noformat}
> Exception in thread "main" javax.cache.CacheException: Queries running on
> replicated cache should not contain JOINs with partitioned tables
> [rCache=replicated, pCache=partitioned]
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.stableDataNodes(GridReduceQueryExecutor.java:432)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:529)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$5.iterator(IgniteH2Indexing.java:1119)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:98)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:117)
> ...
> {noformat}
> The reason is that during query analysis
> ({{org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#queryTwoStep}})
> we always deem leftmost cache (the one that the {{query}} method was called
> on) as participating in the query which is clearly not true in the above
> example. Then we add to the query the schema that it actually uses (it's the
> cache named *partitioned* in this case), and resulting two-step query looks
> as if its SQL contained {{JOIN}} on *partitioned* and *replicated* caches
> which we don't support for now.
> Will consult Sergi about what to do next. According to Vlad, this should not
> affect the release in any way and thus won't be fixed in 1.8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-4321) Cassandra modules
[
https://issues.apache.org/jira/browse/IGNITE-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov resolved IGNITE-4321.
--
Resolution: Fixed
Assignee: Sergey Kozlov (was: Alexey Kuznetsov)
Sergey, I think Igor is right.
I made minor changes in ignite-cassandra-serializers/README.txt in order to
describe how ignite-cassandra-serializers module should be used.
> Cassandra modules
> -
>
> Key: IGNITE-4321
> URL: https://issues.apache.org/jira/browse/IGNITE-4321
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 1.8
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
> Fix For: 1.8
>
>
> Binary fabric edition now has following modules:
> {noformat}
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:13 964 README.txt
>1 файлов964 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-serializers
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1353 231 asm-5.0.3.jar
> 25.11.2016 22:1312 181
> ignite-cassandra-serializers-1.8.0-QASK2502.jar
> 25.11.2016 22:13 285 211 kryo-3.0.3.jar
> 25.11.2016 22:13 licenses
> 25.11.2016 22:13 5 711 minlog-1.3.0.jar
> 25.11.2016 22:1341 755 objenesis-2.1.jar
> 25.11.2016 22:13 1 345 README.txt
> 25.11.2016 22:1320 738 reflectasm-1.10.1.jar
>7 файлов420 172 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-serializers\licenses
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1311 358 apache-2.0.txt
> 25.11.2016 22:13 1 857 ignite-cassandra-serializers-licenses.txt
>2 файлов 13 215 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-store
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:13 990 392 cassandra-driver-core-3.0.0.jar
> 25.11.2016 22:13 232 019 commons-beanutils-1.8.3.jar
> 25.11.2016 22:13 2 308 517 guava-19.0.jar
> 25.11.2016 22:1391 897 ignite-cassandra-store-1.8.0-QASK2502.jar
> 25.11.2016 22:13 licenses
> 25.11.2016 22:1385 448 metrics-core-3.0.2.jar
> 25.11.2016 22:13 196 881 netty-buffer-4.0.33.Final.jar
> 25.11.2016 22:13 145 779 netty-codec-4.0.33.Final.jar
> 25.11.2016 22:13 441 447 netty-common-4.0.33.Final.jar
> 25.11.2016 22:13 272 139 netty-handler-4.0.33.Final.jar
> 25.11.2016 22:13 349 164 netty-transport-4.0.33.Final.jar
> 25.11.2016 22:13 1 228 README.txt
> 11 файлов 5 114 911 байт
> Содержимое папки
> C:\Work\apache-ignite-fabric-1.8.0-QASK2502-bin\libs\optional\ignite-cassandra-store\licenses
> 25.11.2016 22:13 .
> 25.11.2016 22:13 ..
> 25.11.2016 22:1311 358 apache-2.0.txt
> 25.11.2016 22:13 294 ignite-cassandra-store-licenses.txt
>2 файлов 11 652 байт
> {noformat}
> I suppose that {{ignite-cassandra}} directory must be removed and rest of
> Cassandra modules should be joined into one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4223) Joining node should fetch affinity for all caches using single message
[ https://issues.apache.org/jira/browse/IGNITE-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708171#comment-15708171 ] Konstantin Dudkov commented on IGNITE-4223: --- I've done some changes, please review (branch ignite-4223) TC tests: http://ci.ignite.apache.org/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1300%2Fhead > Joining node should fetch affinity for all caches using single message > -- > > Key: IGNITE-4223 > URL: https://issues.apache.org/jira/browse/IGNITE-4223 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Konstantin Dudkov > Fix For: 2.0 > > > Currently when new node joins cluster and 'late affinity assignment' mode is > enabled it requests caches affinity using message per cache (see > CacheAffinitySharedManager.fetchAffinityOnJoin). Actually in 'late affinity > assignment' mode coordinator has affinity information for all caches, so > single request can be sent to coordinator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-266) Move conflict resolution logic to separate processor.
[ https://issues.apache.org/jira/browse/IGNITE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-266. -- > Move conflict resolution logic to separate processor. > - > > Key: IGNITE-266 > URL: https://issues.apache.org/jira/browse/IGNITE-266 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: sprint-2 >Reporter: Vladimir Ozerov >Priority: Critical > > Currently conflict resolution logic is spread accross multiple classes. It is > necessary to abstract it out into a single processor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-266) Move conflict resolution logic to separate processor.
[ https://issues.apache.org/jira/browse/IGNITE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-266. Resolution: Won't Fix > Move conflict resolution logic to separate processor. > - > > Key: IGNITE-266 > URL: https://issues.apache.org/jira/browse/IGNITE-266 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: sprint-2 >Reporter: Vladimir Ozerov >Priority: Critical > > Currently conflict resolution logic is spread accross multiple classes. It is > necessary to abstract it out into a single processor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-4257) Web Console: Download project on Summary screen is broken under Safari browser
[ https://issues.apache.org/jira/browse/IGNITE-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-4257. Resolution: Fixed Added note with instruction for Safari users. Pavel, please test. > Web Console: Download project on Summary screen is broken under Safari browser > -- > > Key: IGNITE-4257 > URL: https://issues.apache.org/jira/browse/IGNITE-4257 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-978) Create timeout of IgniteCache.get()
[ https://issues.apache.org/jira/browse/IGNITE-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-978. Resolution: Won't Fix > Create timeout of IgniteCache.get() > --- > > Key: IGNITE-978 > URL: https://issues.apache.org/jira/browse/IGNITE-978 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: sprint-4 >Reporter: Vladimir Ozerov >Priority: Critical > > Migrated from GG private JIRA (GG-9492). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-385) Run Ignite with default Hadoop benchmarks.
[ https://issues.apache.org/jira/browse/IGNITE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-385: --- Priority: Minor (was: Critical) > Run Ignite with default Hadoop benchmarks. > -- > > Key: IGNITE-385 > URL: https://issues.apache.org/jira/browse/IGNITE-385 > Project: Ignite > Issue Type: Task > Components: hadoop >Affects Versions: sprint-1 >Reporter: Vladimir Ozerov >Priority: Minor > > They should be run before release after all public API changes are in place. > Also we must pay attention to shmem mode as there is information that there > were problems with it under load. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-979) Revisit timeout logic in Ignite.
[ https://issues.apache.org/jira/browse/IGNITE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-979. Resolution: Won't Fix > Revisit timeout logic in Ignite. > > > Key: IGNITE-979 > URL: https://issues.apache.org/jira/browse/IGNITE-979 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: sprint-4 >Reporter: Vladimir Ozerov >Priority: Critical > > Migrated from GG private JIRA (GG-9487). > "Also think of removing registration of events in timeout processor, but have > several threads scanning the corresponding futures collection and cancel > operations if necessary. > List to check: > - tasks > - cache ops (atomic and tx modes): > - get > - put > - query > - lock > - service deployment > - continuos queries > - message listeners deployment > - ?" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-978) Create timeout of IgniteCache.get()
[ https://issues.apache.org/jira/browse/IGNITE-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-978. -- > Create timeout of IgniteCache.get() > --- > > Key: IGNITE-978 > URL: https://issues.apache.org/jira/browse/IGNITE-978 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: sprint-4 >Reporter: Vladimir Ozerov >Priority: Critical > > Migrated from GG private JIRA (GG-9492). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-979) Revisit timeout logic in Ignite.
[ https://issues.apache.org/jira/browse/IGNITE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-979. -- > Revisit timeout logic in Ignite. > > > Key: IGNITE-979 > URL: https://issues.apache.org/jira/browse/IGNITE-979 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: sprint-4 >Reporter: Vladimir Ozerov >Priority: Critical > > Migrated from GG private JIRA (GG-9487). > "Also think of removing registration of events in timeout processor, but have > several threads scanning the corresponding futures collection and cancel > operations if necessary. > List to check: > - tasks > - cache ops (atomic and tx modes): > - get > - put > - query > - lock > - service deployment > - continuos queries > - message listeners deployment > - ?" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1430) Platforms: Incorrect behavior of write-behind store on node stop
[ https://issues.apache.org/jira/browse/IGNITE-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1430: Priority: Major (was: Blocker) > Platforms: Incorrect behavior of write-behind store on node stop > > > Key: IGNITE-1430 > URL: https://issues.apache.org/jira/browse/IGNITE-1430 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > > We destroy unmanaged native resources on node "stop" phase. But write-behind > store can still have som unflushed data at this point because cache processor > is not stoped yet. > To fix this we must add more callbacks to platform processor which are > invoked before any component is started and after any component is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1108) Additional lifecycle callbacks in PluginProvider interface.
[ https://issues.apache.org/jira/browse/IGNITE-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1108: Priority: Minor (was: Critical) > Additional lifecycle callbacks in PluginProvider interface. > --- > > Key: IGNITE-1108 > URL: https://issues.apache.org/jira/browse/IGNITE-1108 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Attachments: ignite-1108.patch > > > Currently plugins are started at the very end of start process, and they are > stopped before all other components. > This is a problem because sometimes we need to stop plugin AFTER all other > components. not BEFORE. E.g. consider a plugin which provides an environment > for custom cache store, and this store has "write-behind" enabled. In this > case we will stop plugin before write-behind store flushed all data what > leads to unexpected behavior. > It seems that we must provide more callbacks so that plugins could be > notified both before and after all other components are started/stopped. > Proposed design: > 1) Start: > - PluginProvider.onBeforeStart() - called from IgnitePluginProcessor.start(); > - PluginProvider.start() - already exists, unchanged; > - PluginProvider.onAfterStart() - just rename onIgniteStart() for consistency > with onBeforeStart(); > 2) Stop procedure is mirrored from start: onBeforeStop(), stop(), > onAfterStop(). > 3) Introduce PluginProviderAdapter where methods will be no-op. This way user > plugins will continue compile in case of further changes to PluginProvider > interfaces provided that method names are unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4309) IgniteLockExample hangs in multi-node mode.
[
https://issues.apache.org/jira/browse/IGNITE-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4309:
Priority: Major (was: Critical)
> IgniteLockExample hangs in multi-node mode.
> ---
>
> Key: IGNITE-4309
> URL: https://issues.apache.org/jira/browse/IGNITE-4309
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Start CacheExamplesMultiNodeSelfTest.testCacheLockExample.
> 2) Observe that example hangs and the following metrics printout appears form
> time to time:
> {code}
> ^-- Public thread pool [active=2, idle=0, qSize=0]
> {code}
> or
> {code}
> ^-- Public thread pool [active=3, idle=0, qSize=0]
> {code}
> Logs with thread dumps on TC:
> http://195.239.208.174/viewLog.html?buildId=368311&buildTypeId=IgniteTests_IgniteExamples&tab=buildLog#_focus=24510
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-521) Exception is not thrown on near node when TX is failed on primary node.
[ https://issues.apache.org/jira/browse/IGNITE-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-521: --- Priority: Major (was: Critical) > Exception is not thrown on near node when TX is failed on primary node. > --- > > Key: IGNITE-521 > URL: https://issues.apache.org/jira/browse/IGNITE-521 > Project: Ignite > Issue Type: Sub-task > Components: cache >Affects Versions: sprint-1 >Reporter: Vladimir Ozerov >Assignee: Alexey Goncharuk > > Test scenario: > 1) Start 2 nodes with TX PARTITIONED_ONLY cache and 0 backups. > 2) Start continuous query providing a filter which throws exceptions on each > call. > 3) Put primary key to cache through "getAndPut()" -> TX is rolled back, you > receive exception. > 4) Put near key to cache in the same way -> TX is rolled back, but NO > EXCEPTION! > 5) Set backups=1 => step 4 throws an exception as expected. > 6) Set mode to ATOMIC => step 4 throws an exception as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3682) GridFunc: move all inner anonymous classes to separate top-level classes.
[
https://issues.apache.org/jira/browse/IGNITE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3682:
Priority: Major (was: Critical)
> GridFunc: move all inner anonymous classes to separate top-level classes.
> -
>
> Key: IGNITE-3682
> URL: https://issues.apache.org/jira/browse/IGNITE-3682
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Labels: important
> Fix For: 2.0
>
>
> Otherwise almost any change to class {{GridFunc}} will lead to serialization
> issues because we have no control over inner class names.
> E.g. if removed single anonymous class, another anonymous class might change
> it's name from {{GridFunc$4}} to {{GridFunc$3}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1581) Synchronous cache operation can deadlock on async semaphore.
[
https://issues.apache.org/jira/browse/IGNITE-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1581:
Priority: Major (was: Critical)
> Synchronous cache operation can deadlock on async semaphore.
>
>
> Key: IGNITE-1581
> URL: https://issues.apache.org/jira/browse/IGNITE-1581
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Semen Boikov
>
> Problem can be reproduced as follows:
> 1) Set CacheConfiguration.setMaxConcurrentAsyncOperations() to a very small
> value, e.g. 3.
> 2) T1: Start PESSIMISTIC/REPEATABLE_READ tx and call Cache.get(1);
> 3) Start 3 other threads, initiate PESSIMISTIC/REPEATABLE_READ tx and call
> Cache.get(1) on them. They will stuck as expected.
> 4) T1: Call Cache.get(1) again. Instead of getting already locked value,
> thread is stuck on async semaphore acquire:
> {code}
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4329)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4203)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAllAsync(GridDhtColocatedCache.java:211)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync(GridCacheAdapter.java:4609)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4556)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1569)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1472) CPP: Support enums.
[ https://issues.apache.org/jira/browse/IGNITE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1472: Priority: Major (was: Critical) > CPP: Support enums. > --- > > Key: IGNITE-1472 > URL: https://issues.apache.org/jira/browse/IGNITE-1472 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp > > Needed to be able to interact with Java/.Net enums. Probably this can be done > with some extension structure which will provide type ID for the enum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1473) CPP: Add failed keys for CachePartialUpdateException.
[ https://issues.apache.org/jira/browse/IGNITE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1473: Priority: Minor (was: Critical) > CPP: Add failed keys for CachePartialUpdateException. > - > > Key: IGNITE-1473 > URL: https://issues.apache.org/jira/browse/IGNITE-1473 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: cpp > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2978) .NET: Optimize field set inside Java object factory.
[ https://issues.apache.org/jira/browse/IGNITE-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2978: Priority: Minor (was: Critical) > .NET: Optimize field set inside Java object factory. > > > Key: IGNITE-2978 > URL: https://issues.apache.org/jira/browse/IGNITE-2978 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Minor > Labels: performance > > Cache resolved fields. Need to be careful to avoid class leaks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3529) IGFS: Simplify meta and data cache configuration.
[
https://issues.apache.org/jira/browse/IGNITE-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3529:
Priority: Major (was: Critical)
> IGFS: Simplify meta and data cache configuration.
> -
>
> Key: IGNITE-3529
> URL: https://issues.apache.org/jira/browse/IGNITE-3529
> Project: Ignite
> Issue Type: Sub-task
> Components: IGFS
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> Currently IGFS configuration is rather complex because user have to manually
> do the following:
> 1) Configure meta cache
> 2) Configure data cache
> 3) Wire them up with IGFS through {{FileSystemConfiguration.*CacheName}}
> properties.
> Instead, I propose to do the following:
> 1) Add two properties directly to {{FileSystemConfiguration}}:
> - dataCacheConfiguration
> - metaCacheConfiguration
> 2) Names of these cache will be ignored and overwritten with cache name
> unique to concrete IGFS . E.g. *_data and *_meta, where * is IGFS name.
> 3) *THE MOST IMPORTANT THING* - provide sensible defaults.
> This way normally user will not bother about cache config at all. He will
> only need to add IGFS config bean and set it's name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2398) .NET: Change default mapper behavior.
[ https://issues.apache.org/jira/browse/IGNITE-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2398: Priority: Minor (was: Critical) > .NET: Change default mapper behavior. > - > > Key: IGNITE-2398 > URL: https://issues.apache.org/jira/browse/IGNITE-2398 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net, important > Fix For: 2.0 > > > We need to mirror changes implemented in IGNITE-2191: > 1) Default mapper must use full class name (i.e. with package) > 2) Provide additional mapper implementation which will use simple names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1469) CPP: Support decimals in marshaller.
[ https://issues.apache.org/jira/browse/IGNITE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1469: Priority: Major (was: Critical) > CPP: Support decimals in marshaller. > > > Key: IGNITE-1469 > URL: https://issues.apache.org/jira/browse/IGNITE-1469 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp > > We need to support decimals in CPP. > Counterparts: > Java -> BigDecimal > .Net -> decimal -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1446) CPP: Implement cache "keep-binary" semantics.
[ https://issues.apache.org/jira/browse/IGNITE-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1446: Priority: Major (was: Critical) > CPP: Implement cache "keep-binary" semantics. > - > > Key: IGNITE-1446 > URL: https://issues.apache.org/jira/browse/IGNITE-1446 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1418) .Net: Implement distributed count-down latch (event).
[ https://issues.apache.org/jira/browse/IGNITE-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1418: Priority: Minor (was: Critical) > .Net: Implement distributed count-down latch (event). > - > > Key: IGNITE-1418 > URL: https://issues.apache.org/jira/browse/IGNITE-1418 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1417) .Net: Implement distributed queue.
[ https://issues.apache.org/jira/browse/IGNITE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1417: Priority: Minor (was: Critical) > .Net: Implement distributed queue. > -- > > Key: IGNITE-1417 > URL: https://issues.apache.org/jira/browse/IGNITE-1417 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1461) CPP: Support circular references in marshaller.
[ https://issues.apache.org/jira/browse/IGNITE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1461: Priority: Minor (was: Critical) > CPP: Support circular references in marshaller. > --- > > Key: IGNITE-1461 > URL: https://issues.apache.org/jira/browse/IGNITE-1461 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: cpp > > When we face circular references in .Net or Java, we automatically resolve > them by means of "handles": all write/read objects are tracked on their way > to/from a stream. > It is not easy to support the same things in CPP in general case. We need to > define some conditions which portable type must met to enable circular > references support. At the very least such type must be a pointer so that we > can store it in some collection during (un(marshal process and refer to it > later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1448) CPP: Implement cache iterators.
[ https://issues.apache.org/jira/browse/IGNITE-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1448: Priority: Major (was: Critical) > CPP: Implement cache iterators. > --- > > Key: IGNITE-1448 > URL: https://issues.apache.org/jira/browse/IGNITE-1448 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3612) Remove IgniteAsyncSupport,
[
https://issues.apache.org/jira/browse/IGNITE-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3612:
Priority: Major (was: Critical)
> Remove IgniteAsyncSupport,
> --
>
> Key: IGNITE-3612
> URL: https://issues.apache.org/jira/browse/IGNITE-3612
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
> Fix For: 2.0
>
>
> We need to remove {{IgniteAsyncSupport}} as it is hard and error prone to
> use.
> Instead, we should all async methods must be implemented as another method in
> target interface with "Async" prefix. E.g.:
> {{Cache.get}}
> {{Cache.getAsync}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3571) CPP: Improve Cache API.
[ https://issues.apache.org/jira/browse/IGNITE-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3571: Priority: Major (was: Critical) > CPP: Improve Cache API. > --- > > Key: IGNITE-3571 > URL: https://issues.apache.org/jira/browse/IGNITE-3571 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov > Labels: cpp, roadmap > > This is umbrella ticket to manage ongoing C++ cache API efforts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3568) .NET: Start JVM externally
[ https://issues.apache.org/jira/browse/IGNITE-3568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3568: Priority: Minor (was: Critical) > .NET: Start JVM externally > -- > > Key: IGNITE-3568 > URL: https://issues.apache.org/jira/browse/IGNITE-3568 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Currently we start JVM inside .NET process. This is not good for several > reasons: > 1) Broken isolation - only one JVM can exist per process. This way it is > impossible to start two Ignite instances with different JVM options. > 2) JVM startup is expensive, cluster connection is expensive, and process > must host both Java and .NET heaps. Should we have external JVM to connect > to, we would allow for truly thin clients, when dozens thin processes will be > able to work with the same client. We already see growing demand for this > feature, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3556) IGFS: Support external changes to the secondary file system.
[ https://issues.apache.org/jira/browse/IGNITE-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3556: Priority: Minor (was: Critical) > IGFS: Support external changes to the secondary file system. > > > Key: IGNITE-3556 > URL: https://issues.apache.org/jira/browse/IGNITE-3556 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: roadmap > Fix For: 2.0 > > > Currently if secondary file system is changed from the outside, IGFS will > stop working. We need to support ability to survive external change. It means > that we must very carefully review every single file system operation and see > how it should behave in this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3574) CPP: Implement compute API
[ https://issues.apache.org/jira/browse/IGNITE-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3574: Priority: Major (was: Critical) > CPP: Implement compute API > -- > > Key: IGNITE-3574 > URL: https://issues.apache.org/jira/browse/IGNITE-3574 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.6 >Reporter: Vladimir Ozerov > Labels: cpp, roadmap > > Umbrella ticket to host all compute API tickets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3579) Message type should be short.
[
https://issues.apache.org/jira/browse/IGNITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3579:
Priority: Major (was: Critical)
> Message type should be short.
> -
>
> Key: IGNITE-3579
> URL: https://issues.apache.org/jira/browse/IGNITE-3579
> Project: Ignite
> Issue Type: Task
> Components: general
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
> Labels: important
> Fix For: 2.0
>
>
> Currently we encode internal messages with {{byte}}. It turns out that we
> almost exhausted possible IDs.
> We should change {{byte}} to {{short}} for message ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3377) IGFS: Refactor IgfsMetaManager to use the same code paths for both DUAL and PRIMARY modes.
[ https://issues.apache.org/jira/browse/IGNITE-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3377: Priority: Minor (was: Critical) > IGFS: Refactor IgfsMetaManager to use the same code paths for both DUAL and > PRIMARY modes. > -- > > Key: IGNITE-3377 > URL: https://issues.apache.org/jira/browse/IGNITE-3377 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.6 >Reporter: Vladimir Ozerov >Priority: Minor > > We already did that for create() and delete() operations. Let's continue and > do that for the rest: > - append > - mkdirs > - open > - rename > - update -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3084) Investigate how Ignite can support Spark DataFrame
[ https://issues.apache.org/jira/browse/IGNITE-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3084: Priority: Major (was: Critical) > Investigate how Ignite can support Spark DataFrame > -- > > Key: IGNITE-3084 > URL: https://issues.apache.org/jira/browse/IGNITE-3084 > Project: Ignite > Issue Type: Task > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko > Labels: bigdata > Fix For: 2.0 > > > We see increasing demand on nice DataFrame support for our Spark integration. > Need to investigate how could we do that. > Looks like we can investigate how MemSQL do that and take it as a starting > point. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3342) Hadoop: improve Java options documentation.
[
https://issues.apache.org/jira/browse/IGNITE-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3342:
Priority: Minor (was: Critical)
> Hadoop: improve Java options documentation.
> ---
>
> Key: IGNITE-3342
> URL: https://issues.apache.org/jira/browse/IGNITE-3342
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, hadoop
>Affects Versions: 1.6
>Reporter: Vladimir Ozerov
>Priority: Minor
>
> 1) Mentioned library path;
> 2) CMS garbage collector with class unloading options;
> 3) PermGetn/MetaSpace
> 4) Code cache
> Examples:
> *Java 8*
> {{-J-XX:MaxMetaspaceSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
> -J-XX:+CMSPermGenSweepingEnabled
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}
> *Java 7*
> {{-J-XX:MaxPermSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m
> -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
> -J-XX:+CMSPermGenSweepingEnabled
> -J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1342) Improve platform node attribute passing logic.
[ https://issues.apache.org/jira/browse/IGNITE-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1342: Priority: Minor (was: Critical) > Improve platform node attribute passing logic. > -- > > Key: IGNITE-1342 > URL: https://issues.apache.org/jira/browse/IGNITE-1342 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > > Currently we pass only those attributes, which are from "java.lang" package. > This is done to avoid marshalling errors. > We must let processor/context decide which attributes to write depending on > their abilities. At first glance we can simply convert to "strings" those > attributes which cannot be marshalled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1324) Optimize platform entry processor for local execution.
[ https://issues.apache.org/jira/browse/IGNITE-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1324: Priority: Minor (was: Critical) > Optimize platform entry processor for local execution. > -- > > Key: IGNITE-1324 > URL: https://issues.apache.org/jira/browse/IGNITE-1324 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: performance > > Currently entry processor is passed to Java as if it was remote, even for > local execution. As a result, local execution require additional > marshal-unmarshal cycle to execute it on native platform (that is, pointer > field is always 0)). > We need to optimize it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1360) Extend platform processor lifecycle.
[ https://issues.apache.org/jira/browse/IGNITE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1360: Priority: Minor (was: Critical) > Extend platform processor lifecycle. > > > Key: IGNITE-1360 > URL: https://issues.apache.org/jira/browse/IGNITE-1360 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > > Currently platform processor lifecycle is the same as for all other > processors wiht 4 callbacks: onStart, onKernalStart, onKernalStop, onStop. > This appears to be not enough for platforms. IN particular, it doesn't let us > flush all write-behind store data correctly and doesn't allow for normal > AFTER_NODE_STOP lifecycle callback. > Also it makes platfomr initialization more painful because some callbacks > might reach the platform when it is not initialized yet. > To mitigate this problem we should extend platform processor with two more > callbacks: "onBeforeStart" and "onAfterStop". Careful management of these > callbacks will let us get rid of all aforementioned problems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1440) CPP: Implement cache store.
[ https://issues.apache.org/jira/browse/IGNITE-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1440: Priority: Major (was: Critical) > CPP: Implement cache store. > --- > > Key: IGNITE-1440 > URL: https://issues.apache.org/jira/browse/IGNITE-1440 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp, roadmap > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform
[ https://issues.apache.org/jira/browse/IGNITE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1628: Priority: Minor (was: Critical) > .NET: Ensure that Ignite works on Mono platform > --- > > Key: IGNITE-1628 > URL: https://issues.apache.org/jira/browse/IGNITE-1628 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > *NOTE*: Targeted for 1.6, but could be moved even further in case of tight > release schedule. > *Goal* > As Microsoft is moving .Net towards open standards, Mono receives more an > more attention. > We need to ensure that our product works fine on this platform. This includes > both Windows, Linux and (possibly) Mac environments. > *Tasks* > - Ensure that Ignite works with Mono on Windows. This is the easiest task > because we only need to re-compile .Net part. > - Ensure that Ignite works with Mono on Linux. This will require alternate > build procedure because CPP recompilation will be required as well. > - Create relevant TC builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1429) .Net: Optimize stream receiver so that it is created only once on remote node.
[ https://issues.apache.org/jira/browse/IGNITE-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1429: Priority: Minor (was: Critical) > .Net: Optimize stream receiver so that it is created only once on remote node. > -- > > Key: IGNITE-1429 > URL: https://issues.apache.org/jira/browse/IGNITE-1429 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Looks like we can employ PhantomReference in Java for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1478) Service cannot be used on remote node immediately after deployment.
[ https://issues.apache.org/jira/browse/IGNITE-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1478: Priority: Minor (was: Critical) > Service cannot be used on remote node immediately after deployment. > --- > > Key: IGNITE-1478 > URL: https://issues.apache.org/jira/browse/IGNITE-1478 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > > Consider the following scenario: > 1) Two nodes: A and B. > 2) Node A deploys cluster-wide service through IgniteServices.deploy(); > 3) Once we exited deploy() method we are trying to get the service on the > node B in any way (invoke it, get proxy, get descriptor, whatever). > Step 3 might fail. This happens because > GridServiceProcessor.AssignmentListener is not notified synchronously when > service cache is update in transaction. > As a result, transacion ends, node A informs us about successful service > deployment, but it is still not usable on remote nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1442) CPP: Implement asynchronous cache operations.
[ https://issues.apache.org/jira/browse/IGNITE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1442: Priority: Major (was: Critical) > CPP: Implement asynchronous cache operations. > - > > Key: IGNITE-1442 > URL: https://issues.apache.org/jira/browse/IGNITE-1442 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp, roadmap > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1550) Optimize "direct" message serialization.
[ https://issues.apache.org/jira/browse/IGNITE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1550: Priority: Minor (was: Critical) > Optimize "direct" message serialization. > > > Key: IGNITE-1550 > URL: https://issues.apache.org/jira/browse/IGNITE-1550 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > > *Overview* > Ignite use "direct" serialization to speed up marshalling of internal classes > avoiding byte array copying. > This mechanism can be improved significantly on class-by-class basis reducing > message size by 10-30% in different cases. > *Implementation* > 1) Definte the list of possible optimizations. At the very least it includes: > - Var-length integer encoding; > - Special cases (constants, positive-only values, low amount of significant > bits, etc.); > - Efficient writes of "nulls"; > - Write groups of relates fields with boolean switch if they are either null > or not-null at the same time. > 2) Determine what to optimize. This can be done on class-by-class basis for > each of ~180 messages. Better approach will be to enable tracking of written > values inside DirectMessageWriter. Then we should run Ignite with differnet > payloads and identify fields which are good candidates for optimization. > 3) Implement each optimziation. > *Risks* > Backward compatibility will be broken. We must either inform users about it, > or support ability to use old non-optimized protocol version somehow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1415) .Net: Optimize handle registry.
[ https://issues.apache.org/jira/browse/IGNITE-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1415: Priority: Minor (was: Critical) > .Net: Optimize handle registry. > --- > > Key: IGNITE-1415 > URL: https://issues.apache.org/jira/browse/IGNITE-1415 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > The main problem with handle registry is CAS on a single shared variable. > This could result in a very bad performance under contention. > Several techniques can be applied here: > 1) Stripes. Assign some ID to a thread and then use it to pick correct stripe > for the thread. Be careful with false-sharing effects as stripes can be > located very close to each other. > 2) Cleanup with relaxed membars. When we are to remove the handle, no need > for full HB semantics. We are ok if subsequent calls to the same handle will > see not-killed object for a while. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1637) IGFS: Consistent properties propagation.
[ https://issues.apache.org/jira/browse/IGNITE-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1637: Priority: Minor (was: Critical) > IGFS: Consistent properties propagation. > > > Key: IGNITE-1637 > URL: https://issues.apache.org/jira/browse/IGNITE-1637 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Attachments: IGNITE_1637.patch > > > IGFS has methods accepting properties map. E.g., create, append, mkdirs. > How we should apply these properties? Two strategies are possible: > 1) Apply there properties only to leaf node, and set defaults to parent nodes. > 2) Apply there properties to all created nodes. > Lets take HDFS as a reference for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1470) CPP: Support string arrays in marshaller.
[ https://issues.apache.org/jira/browse/IGNITE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1470: Priority: Major (was: Critical) > CPP: Support string arrays in marshaller. > - > > Key: IGNITE-1470 > URL: https://issues.apache.org/jira/browse/IGNITE-1470 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp, roamap > > String arrays are written in a special way in Java/.Net. We need to support > them in CPP as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1441) CPP: Support filter in SCAN queries.
[ https://issues.apache.org/jira/browse/IGNITE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1441: Priority: Major (was: Critical) > CPP: Support filter in SCAN queries. > > > Key: IGNITE-1441 > URL: https://issues.apache.org/jira/browse/IGNITE-1441 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: cpp, roadmap > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1432) .Net: Fix InteropCacheEntryProcessor performance on remote nodes
[ https://issues.apache.org/jira/browse/IGNITE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1432: Priority: Minor (was: Critical) > .Net: Fix InteropCacheEntryProcessor performance on remote nodes > > > Key: IGNITE-1432 > URL: https://issues.apache.org/jira/browse/IGNITE-1432 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > Considerations: > 1) Invoke with single key is expected to be called only once, so no changes > is needed here - deploy and execute in a single JNI call. > 2) If there are several keys, there is a high chance (but still not 100% due > to partitioning) that processor will be called multiple times. > Proposed solution: > 1) Check amout of keys. > 2) If cnt == 1, no changes to current logic. > 3) If cnt > 1, first deploy (JNI call), then execute (JNI call). Processor > entry must be put into weak-map located somewhere inside the interop > processor. Interop processor must constantly listen for corresponding > reference queue and release .Net entries as soon as processor is weakly > reacheable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-4332) Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to remote operations
[ https://issues.apache.org/jira/browse/IGNITE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-4332: - Assignee: Semen Boikov (was: Eduard Shangareev) > Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to > remote operations > - > > Key: IGNITE-4332 > URL: https://issues.apache.org/jira/browse/IGNITE-4332 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Eduard Shangareev >Assignee: Semen Boikov > Fix For: 1.8 > > > Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to > remote operations. > We must avoid remote operations if it is possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.
[ https://issues.apache.org/jira/browse/IGNITE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1650: Priority: Minor (was: Critical) > Add ability to specify thread pool for IgniteFuture listen/chain methods. > - > > Key: IGNITE-1650 > URL: https://issues.apache.org/jira/browse/IGNITE-1650 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Chandresh Pancholi >Priority: Minor > Fix For: 2.0 > > > Closures passed to IgniteFuture listen() and chain() methods are executed > either in the same thread if future is completed, or in a completion thread > (usually this is a thread from one of Ignite pools). > This enforces restrictions on what user can do in closures. He cannot use > call operations, he cannot call any Ignite operations. Otherwise deadlocks or > starvation could occur. > To fix that we should allow user to pass optional thread pool where passed > closure should be executed. This already done in Java 8 CompletableFuture. We > should do almost the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1998) Platforms: create separate portable reader.
[ https://issues.apache.org/jira/browse/IGNITE-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-1998. - Resolution: Won't Fix > Platforms: create separate portable reader. > --- > > Key: IGNITE-1998 > URL: https://issues.apache.org/jira/browse/IGNITE-1998 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > > Base portable reader - BinaryReaderExImpl. It is designed for situation when > real deserialization is expected. > To the contrast, we never deserialize objects in platform's code. For this > reason it makes sense to create separate for efficient reader for platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2210) Cannot query annotated methods when BinaryMarshaller is set.
[ https://issues.apache.org/jira/browse/IGNITE-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2210: Priority: Major (was: Critical) > Cannot query annotated methods when BinaryMarshaller is set. > > > Key: IGNITE-2210 > URL: https://issues.apache.org/jira/browse/IGNITE-2210 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov > Fix For: 2.0 > > > Because it is impossible to call method from object in binary form. Several > solutions could be applied here: > 1) Throw exception when method annotation is found and BinaryMarshaller is > set. > 2) Or call this method and record it as a field to the object. > Sample test: > IgniteCacheAbstractFieldsQuerySelfTest.testMethodAnnotationWithoutGet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2122) .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods.
[ https://issues.apache.org/jira/browse/IGNITE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2122: Priority: Minor (was: Critical) > .NET: Add generic Read/WriteCollection and Read/WriteDictionary methods. > > > Key: IGNITE-2122 > URL: https://issues.apache.org/jira/browse/IGNITE-2122 > Project: Ignite > Issue Type: Task > Components: general, platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform
[ https://issues.apache.org/jira/browse/IGNITE-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1628: Priority: Major (was: Minor) > .NET: Ensure that Ignite works on Mono platform > --- > > Key: IGNITE-1628 > URL: https://issues.apache.org/jira/browse/IGNITE-1628 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov > Labels: .net > > *NOTE*: Targeted for 1.6, but could be moved even further in case of tight > release schedule. > *Goal* > As Microsoft is moving .Net towards open standards, Mono receives more an > more attention. > We need to ensure that our product works fine on this platform. This includes > both Windows, Linux and (possibly) Mac environments. > *Tasks* > - Ensure that Ignite works with Mono on Windows. This is the easiest task > because we only need to re-compile .Net part. > - Ensure that Ignite works with Mono on Linux. This will require alternate > build procedure because CPP recompilation will be required as well. > - Create relevant TC builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1654) .Net: Ensure consistent "keepPortable" behavior.
[ https://issues.apache.org/jira/browse/IGNITE-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1654: Priority: Minor (was: Critical) > .Net: Ensure consistent "keepPortable" behavior. > > > Key: IGNITE-1654 > URL: https://issues.apache.org/jira/browse/IGNITE-1654 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Minor > Labels: .net > > We need to ensure that "keep portable" concept is > a) Consistent; > b) Exists for all logical units where it is necessary. > Lets split "keep portable" behavior in two scenarios: > 1) Client mode. This is when client (caller) operates on portable objects. > Example: ICache.Get(...); > 2) Server mode. This is when some server side object (caller) operates on > portable objects. Example: a remote service which should not deserialize > passed arguments and operate on portables instead. > Looks like both cases can be handled using the same "keep portable" flag on > related logical unit. > Logical units affected: > 1) Compute - at the very least closures can be executed in this mode; > 2) Cache; > 3) Data streamer; > 4) Data structures: atomic stamped, atmoc reference; > 5) Cache events; > 6) Messages; > 7) Services. > Probably we should introduce a kind of "IKeepPortableEnabled" (or so) > interface, which will have a method "T WithKeepPortable()". This way users > will be able to easily understand that "keep portable" semantics is > applicable. > Lets split it into several children tickets if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.
[ https://issues.apache.org/jira/browse/IGNITE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-1650: Priority: Major (was: Minor) > Add ability to specify thread pool for IgniteFuture listen/chain methods. > - > > Key: IGNITE-1650 > URL: https://issues.apache.org/jira/browse/IGNITE-1650 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Chandresh Pancholi > Fix For: 2.0 > > > Closures passed to IgniteFuture listen() and chain() methods are executed > either in the same thread if future is completed, or in a completion thread > (usually this is a thread from one of Ignite pools). > This enforces restrictions on what user can do in closures. He cannot use > call operations, he cannot call any Ignite operations. Otherwise deadlocks or > starvation could occur. > To fix that we should allow user to pass optional thread pool where passed > closure should be executed. This already done in Java 8 CompletableFuture. We > should do almost the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2237) GridFutureAdapter: simplify and optimize.
[ https://issues.apache.org/jira/browse/IGNITE-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2237: Priority: Minor (was: Critical) > GridFutureAdapter: simplify and optimize. > - > > Key: IGNITE-2237 > URL: https://issues.apache.org/jira/browse/IGNITE-2237 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Yakov Zhdanov >Priority: Minor > Labels: performance > Fix For: 2.0 > > > The following ideas is to be evaluated: > 1) "startTime" and "endTime" fields have virtually no value. They are used > mostly for debug and tests. > 2) "ignoreInterrupts" flag can be encapsulated into state. > 3) "ArrayListener" concept looks overly complex. Looks like we do not need it > at all -> array can be used directly. > 4) Modern JDK futures do not use AQS anymore. Instead, they park/unpark > directly and store waiters in a kind of compact stack. Need to think about it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2933) Deprecate GridFunc class.
[ https://issues.apache.org/jira/browse/IGNITE-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2933: Priority: Major (was: Critical) > Deprecate GridFunc class. > - > > Key: IGNITE-2933 > URL: https://issues.apache.org/jira/browse/IGNITE-2933 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2977) .NET: Implement generic ability to invoke Java code from non-Java platforms.
[
https://issues.apache.org/jira/browse/IGNITE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2977:
Priority: Major (was: Critical)
> .NET: Implement generic ability to invoke Java code from non-Java platforms.
>
>
> Key: IGNITE-2977
> URL: https://issues.apache.org/jira/browse/IGNITE-2977
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
> Labels: .net, roadmap
>
> *Problem*
> Sometimes user could have mixed cluster when some nodes are running Java and
> some nodes running in platform mode. Obviously, in such deployments it is
> impossible to invoke non-Java code on Java nodes.
> It appears to be a serious limitation for users. For example, if cache nodes
> are Java-only, it is impossible to set remote filter from .NET.
> Known problematic places:
> - Remote filter in continuous query
> - Compute API
> - Scan Queries
> - Cache.invokes
> - "load cache" with non-null predicate
> - services
> - messaging remote listener
> - events remote query
> *Proposed solution*
> 1) Define two new types:
> {{JavaObject}} - encoded Java object; identified by a fully-qualified class
> name and a map of properties.
> {{JavaObjectFactory}} - factory object for more complex cases when some
> additional logic on Java side is required. Factory must support injections.
> 2) Implement corresponding wrappers in .NET and ensure they are unwrapped
> correctly.
> 3) Support individual features from the list above.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2886) IGFS: Implement INotify intergration.
[
https://issues.apache.org/jira/browse/IGNITE-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2886:
Priority: Minor (was: Critical)
> IGFS: Implement INotify intergration.
> -
>
> Key: IGNITE-2886
> URL: https://issues.apache.org/jira/browse/IGNITE-2886
> Project: Ignite
> Issue Type: Task
> Components: hadoop, IGFS
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Oddo
>Priority: Minor
>
> The idea is originally proposed by Michael Pearce on the dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/HDFS-iNotify-td8033.html
> Currently IGFS is unable to deal with changes performed on HDFS directly.
> That is, all file system operations must go through IGFS to maintain
> integrity of in-memory file system view.
> This appears to be a known issue with other Hadoop-based integrations. HDFS
> has relatively new interface {{INotify}} which allows callbacke to external
> sources when file system is updated. We need to evaluate possibility
> integrate IGFS with this module.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2779) BinaryMarshaller caches must be cleaned during client reconnect.
[
https://issues.apache.org/jira/browse/IGNITE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-2779:
Priority: Major (was: Critical)
> BinaryMarshaller caches must be cleaned during client reconnect.
>
>
> Key: IGNITE-2779
> URL: https://issues.apache.org/jira/browse/IGNITE-2779
> Project: Ignite
> Issue Type: Task
> Components: cache, general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
> Labels: community, important
> Fix For: 2.0
>
> Attachments: IgniteProblemTest.java
>
>
> The problem is originally reported by Vinay Sharma here:
> http://apache-ignite-users.70518.x6.nabble.com/changed-cache-configuration-and-restarted-server-nodes-Getting-exception-td3064.html#none
> *Root cause*:
> When client is reconnected to topology after full topology restart (i.e. all
> server nodes were down), it doesn't re-send binary metadata to topology. As a
> result, {{BinaryMarshaller}} exception occurs.
> *Steps to reproduce*
> Run attached code.
> *Proposed solution*
> Clean cached binary metadata during re-connect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-4223) Joining node should fetch affinity for all caches using single message
[ https://issues.apache.org/jira/browse/IGNITE-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708276#comment-15708276 ] Semen Boikov commented on IGNITE-4223: -- Hi Konstantin, Reviewed, found few issues, left some 'TODO' in your branch, please take a look. Thanks! > Joining node should fetch affinity for all caches using single message > -- > > Key: IGNITE-4223 > URL: https://issues.apache.org/jira/browse/IGNITE-4223 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Semen Boikov >Assignee: Konstantin Dudkov > Fix For: 2.0 > > > Currently when new node joins cluster and 'late affinity assignment' mode is > enabled it requests caches affinity using message per cache (see > CacheAffinitySharedManager.fetchAffinityOnJoin). Actually in 'late affinity > assignment' mode coordinator has affinity information for all caches, so > single request can be sent to coordinator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3945) Web console: Implement configuration of DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708300#comment-15708300 ] Vasiliy Sisko commented on IGNITE-3945: --- Extended *Class deployment* section to configure of deploymentSpi. > Web console: Implement configuration of DeploymentSpi > - > > Key: IGNITE-3945 > URL: https://issues.apache.org/jira/browse/IGNITE-3945 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.8 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-4332) Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to remote operations
[ https://issues.apache.org/jira/browse/IGNITE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-4332: - Assignee: (was: Semen Boikov) > Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to > remote operations > - > > Key: IGNITE-4332 > URL: https://issues.apache.org/jira/browse/IGNITE-4332 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Eduard Shangareev > Fix For: 1.8 > > > Usage of cache.getEntry inside GridCacheQueryManager.runQuery causes to > remote operations. > We must avoid remote operations if it is possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-4328) .NET: Create readme.md
[ https://issues.apache.org/jira/browse/IGNITE-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-4328. Resolution: Done Assignee: (was: Pavel Tupitsyn) Done: https://github.com/apache/ignite/tree/master/modules/platforms/dotnet > .NET: Create readme.md > -- > > Key: IGNITE-4328 > URL: https://issues.apache.org/jira/browse/IGNITE-4328 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Pavel Tupitsyn > Labels: .NET > Fix For: 1.9 > > > Java part has both readme.txt (for local viewing) and readme.md (for nice > github appearance). > .NET should have the same: > https://github.com/apache/ignite/tree/master/modules/platforms/dotnet > * We can also include a build status icon: > http://ci.ignite.apache.org/app/rest/builds/buildType:(id:IgniteTests_IgnitePlatformNet)/statusIcon > * Other links like there: https://github.com/cake-build/cake > * Link github sources on readme.io > * Link .NET & C++ folders from main readme.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.
[ https://issues.apache.org/jira/browse/IGNITE-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708420#comment-15708420 ] Taras Ledkov commented on IGNITE-4263: -- [Tests results|http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull%2F1294%2Fhead] > Hadoop: abstract out offheap/heap memory management. > > > Key: IGNITE-4263 > URL: https://issues.apache.org/jira/browse/IGNITE-4263 > Project: Ignite > Issue Type: Sub-task > Components: hadoop >Affects Versions: 2.0 >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Fix For: 2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-4329) .NET: Document web deployment specifics on readme.io
[ https://issues.apache.org/jira/browse/IGNITE-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708445#comment-15708445 ] Pavel Tupitsyn commented on IGNITE-4329: There is already a section in https://apacheignite-net.readme.io/docs/deployment#aspnet-deployment, links added in Troubleshooting and ASP.NET sections. > .NET: Document web deployment specifics on readme.io > - > > Key: IGNITE-4329 > URL: https://issues.apache.org/jira/browse/IGNITE-4329 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 1.8 > > > Deploying Ignite.NET requires additional steps in regards to Libs folder. We > have some details on > https://apacheignite-net.readme.io/docs/aspnet-output-caching page, but this > should be documented in a more general way with better visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-4329) .NET: Document web deployment specifics on readme.io
[ https://issues.apache.org/jira/browse/IGNITE-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-4329. Resolution: Fixed Assignee: (was: Pavel Tupitsyn) > .NET: Document web deployment specifics on readme.io > - > > Key: IGNITE-4329 > URL: https://issues.apache.org/jira/browse/IGNITE-4329 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Reporter: Pavel Tupitsyn > Labels: .NET > Fix For: 1.8 > > > Deploying Ignite.NET requires additional steps in regards to Libs folder. We > have some details on > https://apacheignite-net.readme.io/docs/aspnet-output-caching page, but this > should be documented in a more general way with better visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3456) Make sure EntryProcessor is always running on a OWNING partition
[ https://issues.apache.org/jira/browse/IGNITE-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-3456: - Priority: Minor (was: Major) > Make sure EntryProcessor is always running on a OWNING partition > > > Key: IGNITE-3456 > URL: https://issues.apache.org/jira/browse/IGNITE-3456 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Goncharuk >Assignee: Anton Vinogradov >Priority: Minor > > Let's say I need to maintain some sort of an aggregate function over a > partition. This aggregate is maintained using an entry processor, and before > an update this entry processor queries this local aggregate. > If an entry processor is applied on a partition with a MOVING state, the > state of the local aggregate is not valid because not all data has been > preloaded. If entry processor is applied on an OWNING partition, the result > is guaranteed to be correct. > Given that we have implemented late affinity assignment when a new node is > assigned primary only when rebalancing is finished, this should be already > maintained. We just need to add tests verifying the partition state in > EntryProcessor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1410) .NET: Implement IEvents.RecordLocal
[ https://issues.apache.org/jira/browse/IGNITE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1410: --- Summary: .NET: Implement IEvents.RecordLocal (was: .NET: Implement IEvents.RecordLocal.) > .NET: Implement IEvents.RecordLocal > --- > > Key: IGNITE-1410 > URL: https://issues.apache.org/jira/browse/IGNITE-1410 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: .net > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1410) .NET: Implement IEvents.RecordLocal.
[ https://issues.apache.org/jira/browse/IGNITE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1410: --- Summary: .NET: Implement IEvents.RecordLocal. (was: .Net: Implement IEvents.RecordLocal.) > .NET: Implement IEvents.RecordLocal. > > > Key: IGNITE-1410 > URL: https://issues.apache.org/jira/browse/IGNITE-1410 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 1.1.4 >Reporter: Vladimir Ozerov > Labels: .net > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-4045) .NET: Support DML API
[
https://issues.apache.org/jira/browse/IGNITE-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-4045:
--
Assignee: Pavel Tupitsyn
> .NET: Support DML API
> -
>
> Key: IGNITE-4045
> URL: https://issues.apache.org/jira/browse/IGNITE-4045
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Denis Magda
>Assignee: Pavel Tupitsyn
> Labels: roadmap
> Fix For: 2.0
>
>
> Ignite's Java component will provide support for DML soon (IGNITE-2294). At
> she same time DML will be supported at the level of ODBC and JDBC drivers.
> As the next step we should include the similar functionality into Ignite.NET
> by doing the following:
> - Implement DML API;
> - Enhance {{QueryExample.cs}} by doing INSERTs instead of cache.puts and
> adding UPDATE and DELETE operation examples.
> - Add documentation to Ignite.NET readme.io covering the feature. Most like
> most of the content can be take from the general documentation when this
> ticket IGNITE-4018 is ready.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3964) SQL: implement support for table alias
[ https://issues.apache.org/jira/browse/IGNITE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708477#comment-15708477 ] ASF GitHub Bot commented on IGNITE-3964: GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1301 IGNITE-3964: SQL: implement support for table alias Custom table name can be set for QueryEntity. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3964 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/1301.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1301 commit 1d03c30f6254076a6fafb280678119cdd3940ced Author: Andrey V. Mashenkov Date: 2016-11-29T16:44:26Z Added table alias > SQL: implement support for table alias > -- > > Key: IGNITE-3964 > URL: https://issues.apache.org/jira/browse/IGNITE-3964 > Project: Ignite > Issue Type: Task > Components: SQL >Affects Versions: 1.6 >Reporter: Alexey Kuznetsov >Assignee: Andrew Mashenkov > Fix For: 2.0 > > > We have ability to specify aliases for columns via > org.apache.ignite.cache.QueryEntity#getAliases. > But how about alias for table name? This could be useful in case of moving > legacy application to Ignite with a lot of SQL statements. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1683) .Net: IEvents.RemoteListen
[ https://issues.apache.org/jira/browse/IGNITE-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-1683: --- Issue Type: Improvement (was: Task) > .Net: IEvents.RemoteListen > -- > > Key: IGNITE-1683 > URL: https://issues.apache.org/jira/browse/IGNITE-1683 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 1.6 >Reporter: Pavel Tupitsyn > Labels: .net > > Bring back IEvents.RemoteListen as soon as it is fixed in Java. > Currently rmtFilter is not actually a filter and semantics are unclear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3269) Benchmark driver stops working when one of servers left grid and backupcount 0
[
https://issues.apache.org/jira/browse/IGNITE-3269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708483#comment-15708483
]
Ksenia Rybakova commented on IGNITE-3269:
-
Similar case:
ignite-1.8, 80 clients and 20 servers, backup count=1:
{noformat}
[15:23:36,733][INFO ][grid-timeout-worker-#7%null%][IgniteKernal]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=215e4b73, name=null, uptime=00:19:16:915]
^-- H/N/C [hosts=8, nodes=100, CPUs=128]
^-- CPU [cur=1.53%, avg=2%, GC=0%]
^-- Heap [used=437MB, free=57.23%, comm=1024MB]
^-- Non heap [used=44MB, free=65.29%, comm=47MB]
^-- Public thread pool [active=0, idle=0, qSize=0]
^-- System thread pool [active=0, idle=32, qSize=0]
^-- Outbound messages queue [size=0]
[15:23:37,029][WARN ][grid-nio-worker-1-#10%null%][TcpCommunicationSpi] Failed
to process selector key (will close): GridSelectorNioSessionImpl
[selectorIdx=1, queueSize=0, writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768
cap=32768], r
eadBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
recovery=GridNioRecoveryDescriptor [acked=46848, resendCnt=0, rcvCnt=46758,
sentCnt=46860, reserved=true, lastAck=46752, nodeLeft=false,
node=TcpDiscoveryNode [id=d4069148-449b
-41ee-b772-d5586265f23f, addrs=[127.0.0.1, 172.25.1.38],
sockAddrs=[/172.25.1.38:47500, /127.0.0.1:47500], discPort=47500, order=102,
intOrder=101, lastExchangeTime=1480508020664, loc=false,
ver=1.8.0#20161129-sha1:d0e0eaac, isClient=fal
se], connected=true, connectCnt=1, queueLimit=5120, reserveCnt=1],
super=GridNioSessionImpl [locAddr=/172.25.1.35:37134,
rmtAddr=/172.25.1.38:47100, createTime=1480508073194, closeTime=0,
bytesSent=52124554, bytesRcvd=24331807, sndSchedT
ime=1480508617009, lastSndTime=1480508617019, lastRcvTime=1480508616898,
readsPaused=false, filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=o.a.i.i.util.nio.GridDirectParser@76ae88f4, directMode=true],
GridConnectionBytesVeri
fyFilter], accepted=false]]
[15:23:37,030][WARN ][grid-nio-worker-1-#10%null%][TcpCommunicationSpi] Closing
NIO session because of unhandled exception [cls=class
o.a.i.i.util.nio.GridNioException, msg=Connection reset by peer]
[15:23:37,089][WARN ][tcp-comm-worker-#1%null%][TcpCommunicationSpi] Connect
timed out (consider increasing 'failureDetectionTimeout' configuration
property) [addr=/172.25.1.38:47100, failureDetectionTimeout=3]
[15:23:37,090][WARN ][tcp-comm-worker-#1%null%][TcpCommunicationSpi] Failed to
connect to a remote node (make sure that destination node is alive and
operating system firewall is disabled on local and remote hosts)
[addrs=[/172.25.1.38:4
7100, /127.0.0.1:47100]]
[15:23:37] (err) Failed to execute compound future reducer:
GridNearTxFinishFuture [futId=3204e25b851-d7870206-d4cd-4c35-a749-d1d9b5b628bc,
tx=GridNearTxLocal [mappings=IgniteTxMappingsImpl [], nearLocallyMapped=false,
colocatedLocallyMa
pped=false, needCheckBackup=null, hasRemoteLocks=true, thread=, mappings=IgniteTxMappingsImpl [],
super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
dhtNodes=[], explicitLock=false,
super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false,
depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=GridLongList
[idx=3, arr=[3716,107944136,-535738254]], txMap={IgniteTxKey
[key=o.a.i.yardstick.cache.lo
ad.model.key.Identifier [idHash=454392180, hash=-1688540165, id=1663029,
code=id 1663029], cacheId=3716]=IgniteTxEntry
[key=o.a.i.yardstick.cache.load.model.key.Identifier [idHash=454392180,
hash=-1688540165, id=1663029, code=id 1663029]
, cacheId=3716, partId=5, txKey=IgniteTxKey
[key=o.a.i.yardstick.cache.load.model.key.Identifier [idHash=454392180,
hash=-1688540165, id=1663029, code=id 1663029], cacheId=3716], val=[op=CREATE,
val=o.a.i.yardstick.cache.model.Account [i
dHash=517520528, hash=216730851, balance=1663029]], prevVal=[op=CREATE,
val=o.a.i.yardstick.cache.model.Account [idHash=517520528, hash=216730851,
balance=1663029]], oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1,
conflictEx
pireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry
[super=GridDistributedCacheEntry [super=GridCacheMapEntry
[key=o.a.i.yardstick.cache.load.mod
el.key.Identifier [idHash=454392180, hash=-1688540165, id=1663029, code=id
1663029], val=null, startVer=1480614477546, ver=GridCacheVersion
[topVer=91987517, time=1480508616519, order=1480614477371, nodeOrder=1],
hash=-1688540165, extras
=null, flags=0]]], prepared=0, locked=true,
nodeId=5650c65d-918a-4a27-af67-14d995de536b, locMapped=false, expiryPlc=null,
transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
xidVer=GridCacheVersion [topVer=91987517, time
=1480508616520, order=1480614477545, nodeOrder=72]], IgniteTxKey
[key=KeyC
