[jira] [Created] (IGNITE-3156) WebSession: remove invalidation check from getId() method.
Vladimir Ozerov created IGNITE-3156: --- Summary: WebSession: remove invalidation check from getId() method. Key: IGNITE-3156 URL: https://issues.apache.org/jira/browse/IGNITE-3156 Project: Ignite Issue Type: Task Components: websession Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 According to the most recent Servlet 3.0 spec, this method should not throw exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3156) WebSession: remove invalidation check from getId() method.
[ https://issues.apache.org/jira/browse/IGNITE-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3156. - Resolution: Fixed > WebSession: remove invalidation check from getId() method. > -- > > Key: IGNITE-3156 > URL: https://issues.apache.org/jira/browse/IGNITE-3156 > Project: Ignite > Issue Type: Task > Components: websession >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > According to the most recent Servlet 3.0 spec, this method should not throw > exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3156) WebSession: remove invalidation check from getId() method.
[ https://issues.apache.org/jira/browse/IGNITE-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3156. --- > WebSession: remove invalidation check from getId() method. > -- > > Key: IGNITE-3156 > URL: https://issues.apache.org/jira/browse/IGNITE-3156 > Project: Ignite > Issue Type: Task > Components: websession >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > According to the most recent Servlet 3.0 spec, this method should not throw > exceptions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3157) WebSession: genuine session is not always propagated to Ignite sessin.
Vladimir Ozerov created IGNITE-3157: --- Summary: WebSession: genuine session is not always propagated to Ignite sessin. Key: IGNITE-3157 URL: https://issues.apache.org/jira/browse/IGNITE-3157 Project: Ignite Issue Type: Task Reporter: Vladimir Ozerov -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3158) WebSession: genuine session is not always propagated to Ignite session.
Vladimir Ozerov created IGNITE-3158: --- Summary: WebSession: genuine session is not always propagated to Ignite session. Key: IGNITE-3158 URL: https://issues.apache.org/jira/browse/IGNITE-3158 Project: Ignite Issue Type: Task Components: websession Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 See WebSessionFilter.createSessionV2() method - null sometimes is passed as genuine session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3158) WebSession: genuine session is not always propagated to Ignite session.
[ https://issues.apache.org/jira/browse/IGNITE-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-3158. - Resolution: Fixed > WebSession: genuine session is not always propagated to Ignite session. > --- > > Key: IGNITE-3158 > URL: https://issues.apache.org/jira/browse/IGNITE-3158 > Project: Ignite > Issue Type: Task > Components: websession >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > See WebSessionFilter.createSessionV2() method - null sometimes is passed as > genuine session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3158) WebSession: genuine session is not always propagated to Ignite session.
[ https://issues.apache.org/jira/browse/IGNITE-3158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-3158. --- > WebSession: genuine session is not always propagated to Ignite session. > --- > > Key: IGNITE-3158 > URL: https://issues.apache.org/jira/browse/IGNITE-3158 > Project: Ignite > Issue Type: Task > Components: websession >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 1.6 > > > See WebSessionFilter.createSessionV2() method - null sometimes is passed as > genuine session. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3090) Memory leak in IgniteH2Indexing prepared statements cache
[
https://issues.apache.org/jira/browse/IGNITE-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288610#comment-15288610
]
ASF GitHub Bot commented on IGNITE-3090:
Github user tledkov-gridgain closed the pull request at:
https://github.com/apache/ignite/pull/712
> Memory leak in IgniteH2Indexing prepared statements cache
> --
>
> Key: IGNITE-3090
> URL: https://issues.apache.org/jira/browse/IGNITE-3090
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Labels: community, important
> Fix For: 1.6
>
>
> IgniteH2Indexing caches prepared statements in {{stmtCache}} that uses
> Threads as keys. Under they high load when there are many Threads the cache
> can grow significantly. Plus if a Thread is terminated its prepared
> statements are not get cleaned introducing a memory leak.
> A special background Thread should be introduced that will iterate over
> {{stmCache}} performing the following:
> - cleaning records for terminated Threads;
> - cleaning records of the Threads that were not used for a long time. A
> special configuration parameter can be set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2744) Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
[ https://issues.apache.org/jira/browse/IGNITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-2744: - Fix Version/s: (was: 1.6) 1.7 > Optimize "unwindEvict" call in GridCacheIoManager.processMessage(). > --- > > Key: IGNITE-2744 > URL: https://issues.apache.org/jira/browse/IGNITE-2744 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Semen Boikov >Priority: Critical > Labels: performance > Fix For: 1.7 > > > We call this method on every (!!!) received cache message. This call is > pretty heavy as it iterates over all caches. > We need to optimize it. E.g., check evicts only for the cache to which > received message belongs. And iterate over the whole set only if we know for > sure that several caches are affected (e.g. due to cross-cache TX). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3159) WebSession: Incorrect handling of HttpServletRequest.getRequestedSessionId.
Vladimir Ozerov created IGNITE-3159:
---
Summary: WebSession: Incorrect handling of
HttpServletRequest.getRequestedSessionId.
Key: IGNITE-3159
URL: https://issues.apache.org/jira/browse/IGNITE-3159
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Dmitry Karachentsev
Fix For: 1.7
{{WebSessionFilter}} use HttpServletRequest.getRequestedSessionId() method to
get session ID.
However, specification says that this method might return ID which is different
from ID of currently active session. E.g. when request is performed with ID of
already invalidated session. But we never account for this and pass this
session ID to our session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3160) WebSession: Incorrect session ID change logic.
Vladimir Ozerov created IGNITE-3160: --- Summary: WebSession: Incorrect session ID change logic. Key: IGNITE-3160 URL: https://issues.apache.org/jira/browse/IGNITE-3160 Project: Ignite Issue Type: Bug Components: websession Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Dmitry Karachentsev Priority: Critical Fix For: 1.7 When user change session ID, we call invalidate() method on our session after leaving the filter. This call will invalidate genuine session as well, which is wrong. Looks like our session ID change is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3161) WebSession: Session must be created on demand, not always.
Vladimir Ozerov created IGNITE-3161:
---
Summary: WebSession: Session must be created on demand, not always.
Key: IGNITE-3161
URL: https://issues.apache.org/jira/browse/IGNITE-3161
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Dmitry Karachentsev
Priority: Critical
Fix For: 1.7
Our filter will always creates new session (both in Ignite and in container).
This is wrong, as session must be created only when it is really requested
through {{HttpRequest.getSession(true)}} call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3162) WebSession: NPE is possible in WebSessionV2 ctor.
Vladimir Ozerov created IGNITE-3162:
---
Summary: WebSession: NPE is possible in WebSessionV2 ctor.
Key: IGNITE-3162
URL: https://issues.apache.org/jira/browse/IGNITE-3162
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Dmitry Karachentsev
Priority: Critical
Fix For: 1.7
Constructor of {{WebSessoinV2}} accept both genuine session and
{{WebSessionEntity}}. Both of them are nullable. If real values are nulls, NPE
will be thrown. We need to rework that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3163) IGFS: Add working directory notion.
[ https://issues.apache.org/jira/browse/IGNITE-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3163: Priority: Critical (was: Major) > IGFS: Add working directory notion. > --- > > Key: IGNITE-3163 > URL: https://issues.apache.org/jira/browse/IGNITE-3163 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 1.7 > > > Currently when user configure secondary file system, it provides URI. We do > not use path of this URI and rely only on authority component. For this > reason "file:///" and "file:///path/" setting will be processed in the same > We need to respect path component as well and append it so that use can use > relative paths easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3163) IGFS: Add working directory notion.
[ https://issues.apache.org/jira/browse/IGNITE-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3163: Fix Version/s: (was: 1.6) 1.7 > IGFS: Add working directory notion. > --- > > Key: IGNITE-3163 > URL: https://issues.apache.org/jira/browse/IGNITE-3163 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 1.7 > > > Currently when user configure secondary file system, it provides URI. We do > not use path of this URI and rely only on authority component. For this > reason "file:///" and "file:///path/" setting will be processed in the same > We need to respect path component as well and append it so that use can use > relative paths easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3163) IGFS: Add working directory notion.
Vladimir Ozerov created IGNITE-3163: --- Summary: IGFS: Add working directory notion. Key: IGNITE-3163 URL: https://issues.apache.org/jira/browse/IGNITE-3163 Project: Ignite Issue Type: Task Components: IGFS Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.6 Currently when user configure secondary file system, it provides URI. We do not use path of this URI and rely only on authority component. For this reason "file:///" and "file:///path/" setting will be processed in the same We need to respect path component as well and append it so that use can use relative paths easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3163) IGFS: Add working directory notion.
[ https://issues.apache.org/jira/browse/IGNITE-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3163: Labels: important (was: ) > IGFS: Add working directory notion. > --- > > Key: IGNITE-3163 > URL: https://issues.apache.org/jira/browse/IGNITE-3163 > Project: Ignite > Issue Type: Task > Components: IGFS >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: important > Fix For: 1.7 > > > Currently when user configure secondary file system, it provides URI. We do > not use path of this URI and rely only on authority component. For this > reason "file:///" and "file:///path/" setting will be processed in the same > We need to respect path component as well and append it so that use can use > relative paths easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3009) querySql sometimes fails in Ignite RDD embedded mode test
[ https://issues.apache.org/jira/browse/IGNITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3009: - Fix Version/s: 1.7 > querySql sometimes fails in Ignite RDD embedded mode test > - > > Key: IGNITE-3009 > URL: https://issues.apache.org/jira/browse/IGNITE-3009 > Project: Ignite > Issue Type: Bug > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Alexei Scherbakov >Assignee: Taras Ledkov > Fix For: 1.7 > > > JavaEmbeddedIgniteRDDSelfTest.testQueryObjectsFromIgnite > occasionally fails in the line 215 on the objectSql query > If a cache size request is made before query(currently code is commented), > all works fine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3009) querySql sometimes fails in Ignite RDD embedded mode test
[ https://issues.apache.org/jira/browse/IGNITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3009: - Priority: Major (was: Minor) > querySql sometimes fails in Ignite RDD embedded mode test > - > > Key: IGNITE-3009 > URL: https://issues.apache.org/jira/browse/IGNITE-3009 > Project: Ignite > Issue Type: Bug > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Alexei Scherbakov >Assignee: Taras Ledkov > Fix For: 1.7 > > > JavaEmbeddedIgniteRDDSelfTest.testQueryObjectsFromIgnite > occasionally fails in the line 215 on the objectSql query > If a cache size request is made before query(currently code is commented), > all works fine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3009) querySql sometimes fails in Ignite RDD embedded mode test
[ https://issues.apache.org/jira/browse/IGNITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov updated IGNITE-3009: - Assignee: Taras Ledkov > querySql sometimes fails in Ignite RDD embedded mode test > - > > Key: IGNITE-3009 > URL: https://issues.apache.org/jira/browse/IGNITE-3009 > Project: Ignite > Issue Type: Bug > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Alexei Scherbakov >Assignee: Taras Ledkov >Priority: Minor > Fix For: 1.7 > > > JavaEmbeddedIgniteRDDSelfTest.testQueryObjectsFromIgnite > occasionally fails in the line 215 on the objectSql query > If a cache size request is made before query(currently code is commented), > all works fine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
Valentin Kulichenko created IGNITE-3164:
---
Summary: Add an option to send resulting value instead of entry
processor in transactional cache
Key: IGNITE-3164
URL: https://issues.apache.org/jira/browse/IGNITE-3164
Project: Ignite
Issue Type: Improvement
Components: cache
Affects Versions: 1.5.0.final
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Fix For: 1.7
In some cases user can't guarantee that EP behaves consistently on all nodes.
In transactional cache this can lead to inconsistent cache, because we invoke
EP on both primary and backup nodes.
We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
override current default behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Tikhonov reassigned IGNITE-3164:
Assignee: Nikolay Tikhonov (was: Valentin Kulichenko)
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
> Labels: important
> Fix For: 1.7
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288705#comment-15288705 ] Alexey Kuznetsov commented on IGNITE-1371: -- I do one more review, fixed minor problems (like missing ASF headers and typos) and merged into ignite-1.6. But we need: 1) Create issue for refactoring of serializers as I mentioned in previous comment. 2) Create a test suite and configure it to run on ci.ignite.apache.org 3) Describe how this module could be manually tested. > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3165) Hadoop: Incorrect file extension resolution during resource initialization.
Vladimir Ozerov created IGNITE-3165:
---
Summary: Hadoop: Incorrect file extension resolution during
resource initialization.
Key: IGNITE-3165
URL: https://issues.apache.org/jira/browse/IGNITE-3165
Project: Ignite
Issue Type: Task
Components: hadoop
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
Fix For: 1.6
{{HadoopV2JobResourceManager.processFiles()}} method incorrectly resolves
extension because it call {{URI.getFragment()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3166) Incorrect java code in corner case
Pavel Konstantinov created IGNITE-3166:
--
Summary: Incorrect java code in corner case
Key: IGNITE-3166
URL: https://issues.apache.org/jira/browse/IGNITE-3166
Project: Ignite
Issue Type: Sub-task
Reporter: Pavel Konstantinov
# add two caches with incorrect name, e.g. '%' and '+'
# verify generated java code
{code}
cfg.setCacheConfiguration(cache_(), cache_());
...
public static CacheConfiguration cache_()
...
public static CacheConfiguration cache__1()
{code}
should be
{code}
cfg.setCacheConfiguration(cache_(), cache__1());
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-3164:
Description:
In some cases user can't guarantee that EP behaves consistently on all nodes.
In transactional cache this can lead to inconsistent cache, because we invoke
EP on both primary and backup nodes.
We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
override current default behavior.
We also need to update documentation, especially provide the explanation of EP
behavior in atomic and transactional caches.
was:
In some cases user can't guarantee that EP behaves consistently on all nodes.
In transactional cache this can lead to inconsistent cache, because we invoke
EP on both primary and backup nodes.
We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
override current default behavior.
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Nikolay Tikhonov
> Labels: important
> Fix For: 1.7
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3165) Hadoop: Incorrect file extension resolution during resource initialization.
[
https://issues.apache.org/jira/browse/IGNITE-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-3165.
---
> Hadoop: Incorrect file extension resolution during resource initialization.
> ---
>
> Key: IGNITE-3165
> URL: https://issues.apache.org/jira/browse/IGNITE-3165
> Project: Ignite
> Issue Type: Task
> Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> {{HadoopV2JobResourceManager.processFiles()}} method incorrectly resolves
> extension because it call {{URI.getFragment()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3165) Hadoop: Incorrect file extension resolution during resource initialization.
[
https://issues.apache.org/jira/browse/IGNITE-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-3165.
-
Resolution: Fixed
> Hadoop: Incorrect file extension resolution during resource initialization.
> ---
>
> Key: IGNITE-3165
> URL: https://issues.apache.org/jira/browse/IGNITE-3165
> Project: Ignite
> Issue Type: Task
> Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Fix For: 1.6
>
>
> {{HadoopV2JobResourceManager.processFiles()}} method incorrectly resolves
> extension because it call {{URI.getFragment()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3004) Implement config variations test for ContinuousQueries
[ https://issues.apache.org/jira/browse/IGNITE-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288856#comment-15288856 ] Semen Boikov commented on IGNITE-3004: -- Reviewed, my commetns: - please also add single node test - please rename IgniteContinuousQueryVarSuite -> IgniteContinuousQueryConfigVariationsSuite to be consistent with others suites - correct fix for 'removeOffheap' in GridCacheMapEntry is call it after interceptor is called > Implement config variations test for ContinuousQueries > -- > > Key: IGNITE-3004 > URL: https://issues.apache.org/jira/browse/IGNITE-3004 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Nikolay Tikhonov >Priority: Blocker > Fix For: 1.7 > > > Need implement test for continuous qeries with configuration variations. > Make sure these points are covered (in addition to nodes number/cache modes > and configuration paramers variaions): > - different key/values types (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - keepBinary mode > - with/without filters > - ContinuousQuery API and IgniteCache.registerCacheEntryListener > - async/sync listener and filter > - all cache update operations > - CacheEntryListenerConfiguration.isSynchronous true/false -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2667) Allow to start caches in PRIVATE and ISOLATED deployment modes when BinaryMarshaller is used
[ https://issues.apache.org/jira/browse/IGNITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288860#comment-15288860 ] Denis Magda commented on IGNITE-2667: - Vlad, I've reviewed and done a couple of modifications in the test. Please see attached modification.patch. Update your branch with the latest changes from master, apply the patch and re-run tests on TC. > Allow to start caches in PRIVATE and ISOLATED deployment modes when > BinaryMarshaller is used > > > Key: IGNITE-2667 > URL: https://issues.apache.org/jira/browse/IGNITE-2667 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladislav Pyatkov > Labels: community > Fix For: 1.7 > > > Refer to this discussion for details: > http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Distributed-queue-problem-with-peerClassLoading-enabled-td4521.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2667) Allow to start caches in PRIVATE and ISOLATED deployment modes when BinaryMarshaller is used
[ https://issues.apache.org/jira/browse/IGNITE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-2667: Attachment: modification.patch > Allow to start caches in PRIVATE and ISOLATED deployment modes when > BinaryMarshaller is used > > > Key: IGNITE-2667 > URL: https://issues.apache.org/jira/browse/IGNITE-2667 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Assignee: Vladislav Pyatkov > Labels: community > Fix For: 1.7 > > Attachments: modification.patch > > > Refer to this discussion for details: > http://apache-ignite-developers.2346864.n4.nabble.com/Fwd-Distributed-queue-problem-with-peerClassLoading-enabled-td4521.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-2620) Extra 'entry expired' events
[ https://issues.apache.org/jira/browse/IGNITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-2620: Assignee: Semen Boikov (was: Yakov Zhdanov) > Extra 'entry expired' events > > > Key: IGNITE-2620 > URL: https://issues.apache.org/jira/browse/IGNITE-2620 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Semen Boikov >Assignee: Semen Boikov > > Added test reproducing issue: IgniteCacheEntryListenerExpiredEventsTest (more > then 1 event can be fired for single entry expiration). > Very suspicious place is GridCacheMapEntry.onTtlExpired: even when entry is > obsolete it calls 'clearIndex' and 'releaseSwap' (these calls should be > prohibited for obsolete entry). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2620) Extra 'entry expired' events
[ https://issues.apache.org/jira/browse/IGNITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288872#comment-15288872 ] Semen Boikov commented on IGNITE-2620: -- Original issue with extra events is already fixed, but problem with broken synchronization in GridCacheMapEntry.onTtlExpired still exists. > Extra 'entry expired' events > > > Key: IGNITE-2620 > URL: https://issues.apache.org/jira/browse/IGNITE-2620 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.5.0.final >Reporter: Semen Boikov >Assignee: Semen Boikov > > Added test reproducing issue: IgniteCacheEntryListenerExpiredEventsTest (more > then 1 event can be fired for single entry expiration). > Very suspicious place is GridCacheMapEntry.onTtlExpired: even when entry is > obsolete it calls 'clearIndex' and 'releaseSwap' (these calls should be > prohibited for obsolete entry). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3040) Implement config variations test for IgniteMessaging
[ https://issues.apache.org/jira/browse/IGNITE-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1522#comment-1522 ] Semen Boikov commented on IGNITE-3040: -- Reviewed, merged into master (commit 909cfe0). > Implement config variations test for IgniteMessaging > > > Key: IGNITE-3040 > URL: https://issues.apache.org/jira/browse/IGNITE-3040 > Project: Ignite > Issue Type: Test > Components: messaging >Reporter: Semen Boikov >Assignee: Vladislav Pyatkov > Fix For: 1.7 > > > Need implement configuration variations test for IgniteMessaging (use > IgniteComputeConfigVariationsFullApiTest developed in IGNITE-3019 as example). > Test should cover following cases: > - all supported marshaller (Optimized, Binary, JDK) > - different data types for message topics, messages (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - single server node > - multiple servers, multiple clients, send message from server->client, > client->client, client->server > - true/false for IgniteConfiguration.peerClassLoadingEnabled > - all 'sendXXX' method from IgniteMessaging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3040) Implement config variations test for IgniteMessaging
[ https://issues.apache.org/jira/browse/IGNITE-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov closed IGNITE-3040. Assignee: (was: Vladislav Pyatkov) > Implement config variations test for IgniteMessaging > > > Key: IGNITE-3040 > URL: https://issues.apache.org/jira/browse/IGNITE-3040 > Project: Ignite > Issue Type: Test > Components: messaging >Reporter: Semen Boikov > Fix For: 1.7 > > > Need implement configuration variations test for IgniteMessaging (use > IgniteComputeConfigVariationsFullApiTest developed in IGNITE-3019 as example). > Test should cover following cases: > - all supported marshaller (Optimized, Binary, JDK) > - different data types for message topics, messages (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - single server node > - multiple servers, multiple clients, send message from server->client, > client->client, client->server > - true/false for IgniteConfiguration.peerClassLoadingEnabled > - all 'sendXXX' method from IgniteMessaging -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3167) Hadoop: restore external execution.
Vladimir Ozerov created IGNITE-3167: --- Summary: Hadoop: restore external execution. Key: IGNITE-3167 URL: https://issues.apache.org/jira/browse/IGNITE-3167 Project: Ignite Issue Type: Task Components: hadoop Affects Versions: 1.5.0.final Reporter: Vladimir Ozerov Priority: Critical Fix For: 1.7 Some time ago we decided to get rid external execution mode. It appears to be a wrong decision. Hadoop users rely on its process-per-job nature in lot's places. One of such case could be observed in HiBench Bayes benchmark: 1) Job creates something in the local file system through Hadoop FileSystem API. 2) Then it tries to get this data using regular java.io.FileReader and relative paths. This doesn't work in embedded mode because our LocalFileSystem wrapper assigns different work dirs for jobs, but process-wide working directory is always the same. As a result, aforementioned benchmark doesn't work in Ignite, but work with standard Hadoop job tracker. It seems that we must return external execution back. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3009) querySql sometimes fails in Ignite RDD embedded mode test
[ https://issues.apache.org/jira/browse/IGNITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289012#comment-15289012 ] Taras Ledkov commented on IGNITE-3009: -- The test is stabilized by waiting for partition map exchange after a cache creation. Should the waiting logic be added at the IgniteContext or IgniteRDD? > querySql sometimes fails in Ignite RDD embedded mode test > - > > Key: IGNITE-3009 > URL: https://issues.apache.org/jira/browse/IGNITE-3009 > Project: Ignite > Issue Type: Bug > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Alexei Scherbakov >Assignee: Taras Ledkov > Fix For: 1.7 > > > JavaEmbeddedIgniteRDDSelfTest.testQueryObjectsFromIgnite > occasionally fails in the line 215 on the objectSql query > If a cache size request is made before query(currently code is commented), > all works fine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (IGNITE-3009) querySql sometimes fails in Ignite RDD embedded mode test
[ https://issues.apache.org/jira/browse/IGNITE-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-3009: - Comment: was deleted (was: The test is stabilized by waiting for partition map exchange after a cache creation. Should the waiting logic be added at the IgniteContext or IgniteRDD?) > querySql sometimes fails in Ignite RDD embedded mode test > - > > Key: IGNITE-3009 > URL: https://issues.apache.org/jira/browse/IGNITE-3009 > Project: Ignite > Issue Type: Bug > Components: Ignite RDD >Affects Versions: 1.5.0.final >Reporter: Alexei Scherbakov >Assignee: Taras Ledkov > Fix For: 1.7 > > > JavaEmbeddedIgniteRDDSelfTest.testQueryObjectsFromIgnite > occasionally fails in the line 215 on the objectSql query > If a cache size request is made before query(currently code is commented), > all works fine -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3168) Ignite mesos framework should provide ability to configure timeouts.
Nikolay Tikhonov created IGNITE-3168: Summary: Ignite mesos framework should provide ability to configure timeouts. Key: IGNITE-3168 URL: https://issues.apache.org/jira/browse/IGNITE-3168 Project: Ignite Issue Type: Improvement Affects Versions: 1.5.0.final Reporter: Nikolay Tikhonov Fix For: 1.7 Need to add in ClusterProperties class properties which allow to configure jetty timeouts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3169) .NET: Provide better error messages when user assembly loading has failed
Pavel Tupitsyn created IGNITE-3169: -- Summary: .NET: Provide better error messages when user assembly loading has failed Key: IGNITE-3169 URL: https://issues.apache.org/jira/browse/IGNITE-3169 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.7 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2528) Deadlocks caused by Ignite.close()
[
https://issues.apache.org/jira/browse/IGNITE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289098#comment-15289098
]
Alexei Scherbakov commented on IGNITE-2528:
---
Patch available.
Awaiting TC results.
> Deadlocks caused by Ignite.close()
> --
>
> Key: IGNITE-2528
> URL: https://issues.apache.org/jira/browse/IGNITE-2528
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
> Fix For: 1.7
>
>
> If to start stopping an Ignite instance and execute {{cluster.nodes()}} from
> an {{EntryProcessor}} or some other place of the code that holds a lock on
> cache's gateway then this can lead to the deadlock:
> Ignite.close:
> - holds kernel.gateway lock;
> - tries to get a gateway lock on cache A;
> Entry.processor is called for cache A:
> - a gateway lock is acquired for cache A;
> - calling {{cluster.nodes()}};
> - trying to acquire kernel's gateway lock.
> To fix this deadlock we can do the following:
> - introduce a volatile variable that has to be set to 'true' when a node is
> being stopped;
> - check this variable before acquiring kernel's gateway.
> Also probably it makes sense to try to use try lock here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3170) .NET: Add user-friendly ToString overrides for public types
Pavel Tupitsyn created IGNITE-3170: -- Summary: .NET: Add user-friendly ToString overrides for public types Key: IGNITE-3170 URL: https://issues.apache.org/jira/browse/IGNITE-3170 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 1.1.4 Reporter: Pavel Tupitsyn Fix For: 1.7 Events, cache entry events, mutable cache entries, etc, should have ToString overridden, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2899) BinaryObject is deserialized before getting passed to CacheInterceptor
[
https://issues.apache.org/jira/browse/IGNITE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289430#comment-15289430
]
Artem Shutak commented on IGNITE-2899:
--
Fixed p1 in a more right way.
Waiting for TC results.
> BinaryObject is deserialized before getting passed to CacheInterceptor
> --
>
> Key: IGNITE-2899
> URL: https://issues.apache.org/jira/browse/IGNITE-2899
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
> Fix For: 1.7
>
> Attachments: BinaryInterceptorIssue.java,
> BinaryInterceptorNoTypeIssue.java
>
>
> If {{CacheInterceptor}} is configured for a cache that stores
> {{BinaryObjects}} then the objects are always deserialized before being
> passed to the interceptor body.
> Refer to BinaryInterceptorIssue test attached to the ticket to reproduce the
> following stack trace
> {noformat}
> java.lang.ClassCastException:
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidObject cannot be
> cast to org.apache.ignite.binary.BinaryObject
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue$ValidationInterceptor.onBeforePut(BinaryInterceptorIssue.java:49)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2309)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2044)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1314)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:457)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1400(GridNearAtomicUpdateFuture.java:72)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:931)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:283)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1006)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:737)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:1004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:465)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2491)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:440)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2170)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1127)
> at
> org.apache.ignite.examples.tests.BinaryInterceptorIssue.main(BinaryInterceptorIssue.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1577)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1931)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1134)
> at
> org.apache.ignite.examples.tests.Bina
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289494#comment-15289494 ] Konstantin Boudnik commented on IGNITE-1371: [~irudyak], could you please open new tickets for the work, so [~kuaw26] comments are addressed? Thanks everyone for making it happen! > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3171) Support column selectivity calculation for SQL
Sergi Vladykin created IGNITE-3171: -- Summary: Support column selectivity calculation for SQL Key: IGNITE-3171 URL: https://issues.apache.org/jira/browse/IGNITE-3171 Project: Ignite Issue Type: Improvement Reporter: Sergi Vladykin Need to support ANALYZE command. http://h2database.com/html/grammar.html#analyze Currently H2 explicitly ignores external table engines (don't see any reasons why). Probably we have to fix H2 by adding method Table.canAnalyze() and use it in that check. Also when IGNITE-1232 will be merged we'll need to propagate this statistics to clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3172) Ignite-Cassandra serializers
Igor Rudyak created IGNITE-3172: --- Summary: Ignite-Cassandra serializers Key: IGNITE-3172 URL: https://issues.apache.org/jira/browse/IGNITE-3172 Project: Ignite Issue Type: Improvement Components: cache Reporter: Igor Rudyak Assignee: Igor Rudyak Ignite-Cassandra module should contain only "standard" serializer based on Java serialization mechanism. It should be a separate module in Ignite project for all other alternative implementations of serializers (based on Kryo, providing compression, encryption and etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289912#comment-15289912 ] Igor Rudyak commented on IGNITE-1371: - Just opened a new ticket: https://issues.apache.org/jira/browse/IGNITE-3172 > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Fix For: 1.6 > > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3173) IP Finder for Azure Cloud
Denis Magda created IGNITE-3173:
---
Summary: IP Finder for Azure Cloud
Key: IGNITE-3173
URL: https://issues.apache.org/jira/browse/IGNITE-3173
Project: Ignite
Issue Type: New Feature
Reporter: Denis Magda
{{TcpDiscoveryCloudIpFinder}} can't be used on Azure cloud because Compute
Service functionality from JClouds is not supported for Azure. See
ComputeService” list of supported providers [1].
It means that we have to implement {{TcpDiscoveryAzureIpFinder}} in a similar
way as it's done for AWS ({{TcpDiscoveryS3IpFinder}}) and Google Compute Engine
({{TcpDiscoveryGoogleStorageIpFinder}}).
[1] http://jclouds.apache.org/reference/providers/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3174) Missing documentation for TcpDiscoverySharedFsIpFinder on readme.io
Denis Magda created IGNITE-3174:
---
Summary: Missing documentation for TcpDiscoverySharedFsIpFinder on
readme.io
Key: IGNITE-3174
URL: https://issues.apache.org/jira/browse/IGNITE-3174
Project: Ignite
Issue Type: Bug
Reporter: Denis Magda
Documentation for {{TcpDiscoverySharedFsIpFinder}} has to be added to the
following page:
https://apacheignite.readme.io/docs/cluster-config
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2969) Optimistic transactions support in deadlock detection
[
https://issues.apache.org/jira/browse/IGNITE-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290057#comment-15290057
]
Andrey Gura commented on IGNITE-2969:
-
[~sboikov], I see only one reliable way to provide proper synchronization.
Because {{GridNearOptimisticTxPrepareFuture}} sends all
{{GridNearTxPrepareRequest}} sequentially and always awaits response before
sending next request we can use this property.
Main synchronization point is
{{GridNearOptimisticTxPrepareFuture.proceedPrepare()}} method that should not
make progress (send next request) in case of timeout happened. Instead it
should call deadlock detection task and finish without future completion.
Synchronization primitive in this case just atomic reference that contains
{{null}} value before timeout. So we initialize this reference by deadlock
detection task (some kind of {{Runnable}}) on timeout and use {{cas(null,
null)}} before make progress in {{proceedPrepare}} method.
Thus deadlock detection can be started only when there are now requests in
progress. It will allow to avoid creation {{DhtTxLocal}} and {{DhtTxRemote}}
instances after or concurrently with transaction finishing.
I've implemented POC and it seems to work.
Does it makes sense?
> Optimistic transactions support in deadlock detection
> -
>
> Key: IGNITE-2969
> URL: https://issues.apache.org/jira/browse/IGNITE-2969
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.7
>
>
> Deadlock detection doesn't support optimistic transactions now. It should be
> implemented.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
[
https://issues.apache.org/jira/browse/IGNITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290508#comment-15290508
]
Roman Shtykh commented on IGNITE-3153:
--
[~vkulichenko] Seems you forgot to paste the details of the exception ;)
> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP
> finder is used. Most likely this is caused by the fact that {{initGuard}} is
> flipped back to {{false}} when the context is destroyed and new curator
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
