[jira] [Created] (IGNITE-2775) HttpRequest.changeSessionId() won't change session id
Roman Shtykh created IGNITE-2775:
Summary: HttpRequest.changeSessionId() won't change session id
Key: IGNITE-2775
URL: https://issues.apache.org/jira/browse/IGNITE-2775
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 1.5.0.final
Reporter: Roman Shtykh
Assignee: Roman Shtykh
After
{code}
request.changeSessionId();
{code}
{code}
request.getSession().getId();
{code}
returns the old session id.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2710) Session not unbind from current request after invoking request.getSession().invalidate()
[ https://issues.apache.org/jira/browse/IGNITE-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh closed IGNITE-2710. > Session not unbind from current request after invoking > request.getSession().invalidate() > > > Key: IGNITE-2710 > URL: https://issues.apache.org/jira/browse/IGNITE-2710 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.5.0.final > Environment: java8, tomcat8 >Reporter: YuxuanWang >Assignee: Roman Shtykh > Labels: community, session, user > Fix For: 1.6 > > > System.out.println(request.getSession().getId()); > request.getSession().invalidate(); > System.out.println(request.getSession().getId()); > getSession() although return the same session after the invalidation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2774) Add JPA-based store session listener
Valentin Kulichenko created IGNITE-2774: --- Summary: Add JPA-based store session listener Key: IGNITE-2774 URL: https://issues.apache.org/jira/browse/IGNITE-2774 Project: Ignite Issue Type: Improvement Components: cache Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Fix For: 1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2096) AtomicConfiguration and CollectionConfiguration should be properly checked for consistency
[
https://issues.apache.org/jira/browse/IGNITE-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2096:
Labels: usability (was: newbie)
> AtomicConfiguration and CollectionConfiguration should be properly checked
> for consistency
> --
>
> Key: IGNITE-2096
> URL: https://issues.apache.org/jira/browse/IGNITE-2096
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: usability
> Fix For: 1.6
>
>
> Currently {{AtomicConfiguration}} and {{CollectionConfiguration}} are mapped
> to system caches configuration and consistency is checked like for any other
> cache. This leads to unintuitive errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2769) Document store session listeners
[ https://issues.apache.org/jira/browse/IGNITE-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2769: Fix Version/s: 1.6 > Document store session listeners > > > Key: IGNITE-2769 > URL: https://issues.apache.org/jira/browse/IGNITE-2769 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2731) Cache metrics documentation on readme.io
[ https://issues.apache.org/jira/browse/IGNITE-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2731: Issue Type: Task (was: Bug) > Cache metrics documentation on readme.io > > > Key: IGNITE-2731 > URL: https://issues.apache.org/jira/browse/IGNITE-2731 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.5.0.final >Reporter: Denis Magda > Fix For: 1.6 > > > Cache metrics related topic is becoming hot on the user list. > 1) > http://apache-ignite-users.70518.x6.nabble.com/Monitoring-Cache-Data-counters-Cache-Data-Size-td3203.html#a3211 > 2) > http://apache-ignite-users.70518.x6.nabble.com/Is-there-a-way-to-get-cache-metrics-for-all-the-nodes-in-cluster-combined-td2674.html > 3) > http://apache-ignite-users.70518.x6.nabble.com/Metrics-for-backup-caches-td2689.html#a2692 > The time to add a specific article for this topic has come. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2413) Twitter streamer documentation is missing on readme.io
[ https://issues.apache.org/jira/browse/IGNITE-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2413: Issue Type: Task (was: Bug) > Twitter streamer documentation is missing on readme.io > -- > > Key: IGNITE-2413 > URL: https://issues.apache.org/jira/browse/IGNITE-2413 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.5.0.final >Reporter: Denis Magda >Priority: Blocker > Fix For: 1.5.0.final > > > Twitter streamer was released as a part of 1.5. However there is no > documentation available on readme.io describing the new streaming > functionality. > Following documentation can be used as a reference > https://apacheignite.readme.io/docs/jms-data-streamer > https://apacheignite.readme.io/docs/flume-data-streamer -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2511) Missing docs on readme.io for Zookeeper-based cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-2511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2511: Issue Type: Task (was: Bug) > Missing docs on readme.io for Zookeeper-based cluster discovery > --- > > Key: IGNITE-2511 > URL: https://issues.apache.org/jira/browse/IGNITE-2511 > Project: Ignite > Issue Type: Task > Components: documentation, ignite-zookeeper >Reporter: Roman Shtykh > Labels: documentation > Fix For: 1.6 > > > Nothing is said on how to use ZookeeperIpFinder on > https://apacheignite.readme.io/docs/cluster-config -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2421) EventTypes are badly documented
[
https://issues.apache.org/jira/browse/IGNITE-2421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2421:
Issue Type: Task (was: Bug)
> EventTypes are badly documented
> ---
>
> Key: IGNITE-2421
> URL: https://issues.apache.org/jira/browse/IGNITE-2421
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Labels: important
> Fix For: 1.6
>
>
> We have to go through all the {{EventTypes}} and document them well:
> - in which conditions they are fired;
> - what kind of nodes (primary, backups or both) will receive and update;
> - etc.
> As an example.
> From {{EVT_CACHE_ENTRY_CREATED}} is not clear when it's fired at all. However
> it's fired when an entry is loaded from a storage, or when it's initially
> created due to a cache put.
> The same situation is around {{EVT_CACHE_OBJECT_PUT}}. There is no info
> saying that it's fired on both primary and backup nodes. That it's not fired
> due to a loading from a cache, etc.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2771) Document machine safety
[ https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2771: Fix Version/s: 1.6 > Document machine safety > --- > > Key: IGNITE-2771 > URL: https://issues.apache.org/jira/browse/IGNITE-2771 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2196) Broken links in the documentation
[ https://issues.apache.org/jira/browse/IGNITE-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2196: Issue Type: Task (was: Bug) > Broken links in the documentation > -- > > Key: IGNITE-2196 > URL: https://issues.apache.org/jira/browse/IGNITE-2196 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.5.0.final > Environment: Apache Ignite 1.5.0-final build #45 >Reporter: Vasilisa Sidorova >Assignee: Anton Vinogradov > Fix For: 1.6 > > > There is two broken links in the binary package documentation: > # IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/CacheStore.html > (click on the CacheHibarnateBlobStore link -> go to nonexistent page > IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/hibernate/CacheHibernateBlobStore.html) > # > IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/CacheStoreSessionListener.html > (click on the CacheHibernateStoreSessionListener link -> go to nonexistent > page > IGNITE_HOME/docs/javadoc/org/apache/ignite/cache/store/hibernate/CacheHibernateStoreSessionListener.html) > Please, fix it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2180) Javadocs for some modules are missing from Maven repository
[ https://issues.apache.org/jira/browse/IGNITE-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2180: Issue Type: Task (was: Bug) > Javadocs for some modules are missing from Maven repository > - > > Key: IGNITE-2180 > URL: https://issues.apache.org/jira/browse/IGNITE-2180 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.5.0.final > Environment: Apache Ignite 1.5.0-b2 build #112 >Reporter: Vasilisa Sidorova > Fix For: 1.6 > > > Javadocs are missing from Maven repository for following modules: > * ignite-clients > * ignite-extdata-uri > * ignite-osgi-karaf > * ignite-osgi-paxlogging > * ignite-scalar > * ignite-scalar_2.10 > * ignite-spark > * ignite-spark_2.10 > * ignite-visor-console > * ignite-visor-console_2.10 > Please, fix it -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2773) Document swap space
Valentin Kulichenko created IGNITE-2773: --- Summary: Document swap space Key: IGNITE-2773 URL: https://issues.apache.org/jira/browse/IGNITE-2773 Project: Ignite Issue Type: Task Components: documentation Reporter: Valentin Kulichenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2770) Document custom SQL functions
[ https://issues.apache.org/jira/browse/IGNITE-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2770: Fix Version/s: 1.6 > Document custom SQL functions > - > > Key: IGNITE-2770 > URL: https://issues.apache.org/jira/browse/IGNITE-2770 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2771) Document machine safety
Valentin Kulichenko created IGNITE-2771: --- Summary: Document machine safety Key: IGNITE-2771 URL: https://issues.apache.org/jira/browse/IGNITE-2771 Project: Ignite Issue Type: Task Components: documentation Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2772) Document plugin development
Valentin Kulichenko created IGNITE-2772: --- Summary: Document plugin development Key: IGNITE-2772 URL: https://issues.apache.org/jira/browse/IGNITE-2772 Project: Ignite Issue Type: Task Components: documentation Reporter: Valentin Kulichenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2769) Document store session listeners
Valentin Kulichenko created IGNITE-2769: --- Summary: Document store session listeners Key: IGNITE-2769 URL: https://issues.apache.org/jira/browse/IGNITE-2769 Project: Ignite Issue Type: Task Components: documentation Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2770) Document custom SQL functions
Valentin Kulichenko created IGNITE-2770: --- Summary: Document custom SQL functions Key: IGNITE-2770 URL: https://issues.apache.org/jira/browse/IGNITE-2770 Project: Ignite Issue Type: Task Components: documentation Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2322) Downloads page lists incorrect maven version/maven central has not been updated
[ https://issues.apache.org/jira/browse/IGNITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko resolved IGNITE-2322. - Resolution: Not A Problem > Downloads page lists incorrect maven version/maven central has not been > updated > --- > > Key: IGNITE-2322 > URL: https://issues.apache.org/jira/browse/IGNITE-2322 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: James Bench > Labels: documentation, maven > > The downloads page lists the latest version from Maven as 1.5.0.final - the > latest version available from Maven Central is 1.5.0-b1. > https://ignite.apache.org/download.cgi#maven > http://mvnrepository.com/artifact/org.apache.ignite/ignite-core -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-2322) Downloads page lists incorrect maven version/maven central has not been updated
[ https://issues.apache.org/jira/browse/IGNITE-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-2322. --- > Downloads page lists incorrect maven version/maven central has not been > updated > --- > > Key: IGNITE-2322 > URL: https://issues.apache.org/jira/browse/IGNITE-2322 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: James Bench > Labels: documentation, maven > > The downloads page lists the latest version from Maven as 1.5.0.final - the > latest version available from Maven Central is 1.5.0-b1. > https://ignite.apache.org/download.cgi#maven > http://mvnrepository.com/artifact/org.apache.ignite/ignite-core -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2693) withKeepBinary and non-binary marshallers
[
https://issues.apache.org/jira/browse/IGNITE-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182357#comment-15182357
]
Oddo edited comment on IGNITE-2693 at 3/6/16 9:57 PM:
--
Vlad,
I introduced the tests and they pass. However, there are two tests that fail
(unrelated to my tests) but they both use withKeepBinary() in the following
way: grid().cache(null).withKeepBinary()
It appears that when you create a cache with a null config, it does NOT assume
a binary marshaller :-)
Should I just fix the tests and document that assumption or is this a deeper
issue that needs to be addressed?
You can look at the tests results on TC here:
http://204.14.53.151/viewLog.html?buildTypeId=IgniteTests_IgniteDataGrid=205766
Let me know what you think.
was (Author: maketo):
Vlad,
I introduced the tests and they pass. However, there are two tests that fail
(unrelated to my tests) but they both use withKeepBinary() in the following
way: grid().cache(null).
It appears that when you create a cache with a null config, it does NOT assume
a binary marshaller :-)
Should I just fix the tests and document that assumption or is this a deeper
issue that needs to be addressed?
You can look at the tests results on TC here:
http://204.14.53.151/viewLog.html?buildTypeId=IgniteTests_IgniteDataGrid=205766
Let me know what you think.
> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
> Labels: newbie
> Fix For: 1.6
>
>
> Currently the user is able to set {{.withKeepBinary()}} for any used
> marshaller. But it obviously causes ClassCastException for non-binary
> marshallers and should be available only for binary marshaller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2693) withKeepBinary and non-binary marshallers
[
https://issues.apache.org/jira/browse/IGNITE-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182357#comment-15182357
]
Oddo commented on IGNITE-2693:
--
Vlad,
I introduced the tests and they pass. However, there are two tests that fail
(unrelated to my tests) but they both use withKeepBinary() in the following
way: grid().cache(null).
It appears that when you create a cache with a null config, it does NOT assume
a binary marshaller :-)
Should I just fix the tests and document that assumption or is this a deeper
issue that needs to be addressed?
You can look at the tests results on TC here:
http://204.14.53.151/viewLog.html?buildTypeId=IgniteTests_IgniteDataGrid=205766
Let me know what you think.
> withKeepBinary and non-binary marshallers
> -
>
> Key: IGNITE-2693
> URL: https://issues.apache.org/jira/browse/IGNITE-2693
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Sergey Kozlov
>Assignee: Oddo
> Labels: newbie
> Fix For: 1.6
>
>
> Currently the user is able to set {{.withKeepBinary()}} for any used
> marshaller. But it obviously causes ClassCastException for non-binary
> marshallers and should be available only for binary marshaller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2762) Optimized StripedCompositeReadWriteLock to avoid TLS lookups.
[
https://issues.apache.org/jira/browse/IGNITE-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182234#comment-15182234
]
Vladimir Ozerov commented on IGNITE-2762:
-
I implemented this thing after I saw a little hotspot in this place during
sampling of PUT in ATOMIC cache. However, it seems that this sample was not
very precise because it was collection for 1-2 minutes or so.
Anyways, it is done. No observable speedup, but it could potentially give us
protection from collisions on thread-local entries (we see them from time to
time during porfiling/sampling of other benchmarks.
But in future we should better analyze performance data before jumping on
things like this.
> Optimized StripedCompositeReadWriteLock to avoid TLS lookups.
> -
>
> Key: IGNITE-2762
> URL: https://issues.apache.org/jira/browse/IGNITE-2762
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Currently {{StripedCompositeReadWriteLock}} relies on thread-local index to
> find-out thread index.
> As these locks are usually used inside IgniteThread, we can assign special
> index to each thread instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2762) Optimized StripedCompositeReadWriteLock to avoid TLS lookups.
[
https://issues.apache.org/jira/browse/IGNITE-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182234#comment-15182234
]
Vladimir Ozerov edited comment on IGNITE-2762 at 3/6/16 4:58 PM:
-
I implemented this thing after I saw a little hotspot in this place during
sampling of PUT in ATOMIC cache. However, it seems that this sample was not
very precise because it was collection for 1-2 minutes or so.
Anyways, it is done. No observable speedup, but it could potentially give us
protection from collisions on thread-local entries (we see them from time to
time during porfiling/sampling of other benchmarks).
But in future we should better analyze performance data before jumping on
things like this.
was (Author: vozerov):
I implemented this thing after I saw a little hotspot in this place during
sampling of PUT in ATOMIC cache. However, it seems that this sample was not
very precise because it was collection for 1-2 minutes or so.
Anyways, it is done. No observable speedup, but it could potentially give us
protection from collisions on thread-local entries (we see them from time to
time during porfiling/sampling of other benchmarks.
But in future we should better analyze performance data before jumping on
things like this.
> Optimized StripedCompositeReadWriteLock to avoid TLS lookups.
> -
>
> Key: IGNITE-2762
> URL: https://issues.apache.org/jira/browse/IGNITE-2762
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.6
>
>
> Currently {{StripedCompositeReadWriteLock}} relies on thread-local index to
> find-out thread index.
> As these locks are usually used inside IgniteThread, we can assign special
> index to each thread instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-708) Need to remove background partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182232#comment-15182232 ] Gianfranco Murador commented on IGNITE-708: --- I think it is too delicate to touch this mechanism without providing a huge amount of non-regression tests. I do not think I can accomplish this task in the limited time that I can devote to Ignite. Sorry for that :(. The ticket can be reassigned if necessary. > Need to remove background partition exchange > > > Key: IGNITE-708 > URL: https://issues.apache.org/jira/browse/IGNITE-708 > Project: Ignite > Issue Type: Task >Affects Versions: ignite-1.4 >Reporter: Yakov Zhdanov >Assignee: Gianfranco Murador >Priority: Blocker > Labels: datagrid > Fix For: 1.6 > > > Now every node sends its partition map to cache coordinator (which is the > oldest node in topology) and coordinator spreads full partition map to every > node in topology. This happens for each cache separately. This seems to take > place even if there were no changes to local partition maps. Given we > guarantee communication message delivery this background process seems to be > an overkill. > Exchange should happen only if any changes took place. > After dynamic cache start has been introduced, we can have significant amount > of live caches at some point of app lifecycle and app may suffer from > background exchange which is obviously not a requirement (and may be never > has been the one). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2768) Public API for data structures should be guarded from being invoked after node is stopped
Vladisav Jelisavcic created IGNITE-2768: --- Summary: Public API for data structures should be guarded from being invoked after node is stopped Key: IGNITE-2768 URL: https://issues.apache.org/jira/browse/IGNITE-2768 Project: Ignite Issue Type: Bug Components: data structures Affects Versions: 1.6 Reporter: Vladisav Jelisavcic Priority: Minor Fix For: 1.5.0.final For such functionality we have GridKernalGateway, which guards all public API calls from being invoked after node is stopped. Public method implementations should be surrounded with ctx.gateway().readLock() and ctx.gateway().readUnlock(). As an example see GridExecutorService. This ticket is based on conversation: [https://issues.apache.org/jira/browse/IGNITE-2735?focusedCommentId=15181493=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15181493] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2735) Interrupt all acquires on local node after ignite.close
[ https://issues.apache.org/jira/browse/IGNITE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182109#comment-15182109 ] Vladisav Jelisavcic commented on IGNITE-2735: - Nice! Didn't knew about this. It should be fixed now. I created a ticket for the other data structures (couldn't find one; hope it's not redundant): https://issues.apache.org/jira/browse/IGNITE-2768 > Interrupt all acquires on local node after ignite.close > --- > > Key: IGNITE-2735 > URL: https://issues.apache.org/jira/browse/IGNITE-2735 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 1.6 >Reporter: Vladisav Jelisavcic >Assignee: Vladisav Jelisavcic > Fix For: 1.5.0.final > > > "acquire" method should throw an exception when semaphore is no longer > accessible when node is stopped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-642) Implement IgniteReentrantLock data structure
[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15182065#comment-15182065
]
Yakov Zhdanov edited comment on IGNITE-642 at 3/6/16 9:21 AM:
--
Vlad,
Thank you for your efforts! I think we are very close to the final step.
Here are my comments. I think I will review the code one more time and provide
more comments if any.
1. classnames.properties is changed in the PR. Can you please ask Anton
Vinogradov what is the process for this and if we still use this file? Is it
autogenerated or not? I searched our wiki for "classnames.properties" but found
nothing.
2. trivial compilation error -
org/apache/ignite/internal/processors/datastructures/DataStructuresProcessor.java:1435
- "broken" variable is not final. Vlad, are you sure this is the final version?
3. java 7 generics warning - GridCacheReentrantLockImpl.java:497 + code style
- I will resolve both on PR merge
4. IgniteReentrantLock interface docs seems to be copied from JDK which
is not correct in my view. It contains, for example, a lot of "new
ReentrantLock();" mentions.
5. I think IgniteReentrantLock should:
- rename to IgniteLock
- extend SDK lock interface and override methods for providing proper
documentation.
- newCondition() should throw unsupported operation exception and should send
user to use getOrCreateCondition(String name);
- IgniteCondition should also extend SDK condition and provide proper
documentation
6.
org.apache.ignite.internal.processors.datastructures.GridCacheReentrantLockImpl.Sync#failedNodes
- seems to only grow which is strange and may lead to OOME (of course in
theory, but still). It seems you can remove this collection. You can check if
node is failed or not by checking it with discovery -
kernalContext.discovery().node(id); Will it work?
was (Author: yzhdanov):
Vlad,
Thank you for your efforts! I think we are very close to the final step.
Here are my comments. I think I will review the code one more time and provide
more comments if any.
1. classnames.properties is changed in the PR. Can you please ask Anton
Vinogradov what is the process for this and if we still use this file? Is it
autogenerated or not? I searched our wiki for "classnames.properties" but found
nothing.
2. trivial compilation error -
org/apache/ignite/internal/processors/datastructures/DataStructuresProcessor.java:1435
- "broken" variable is not final. Vlad, are you sure this is the final version?
3. java 7 generics warning - GridCacheReentrantLockImpl.java:497 + code style
- I will resolve both on PR merge
4. IgniteReentrantLock interface docs seems to be copied from JDK which
is not correct in my view. It contains, for example, a lot of "new
ReentrantLock();" mentions.
5. I think IgniteReentrantLock should:
- rename to IgniteLock
- extend SDK lock interface and override methods for providing proper
documentation.
- newCondition() should throw unsupported operation exception and should send
user to use getOrCreateCondition(String name);
- IgniteCondition should also extend SDK condition and provide proper
documentation
6.
org.apache.ignite.internal.processors.datastructures.GridCacheReentrantLockImpl.Sync#failedNodes
- seems to only grow which is strange and may lead to OOME (of course in
theory, but still). It seems you can remove this collection. You can check if
node is failed or not by checking it with discovery -
kernalContext.discovery().node(id); Will it work?
> Implement IgniteReentrantLock data structure
>
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-642) Implement IgniteReentrantLock data structure
[
https://issues.apache.org/jira/browse/IGNITE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov reassigned IGNITE-642:
Assignee: Vladisav Jelisavcic (was: Yakov Zhdanov)
Vlad,
Thank you for your efforts! I think we are very close to the final step.
Here are my comments. I think I will review the code one more time and provide
more comments if any.
1. classnames.properties is changed in the PR. Can you please ask Anton
Vinogradov what is the process for this and if we still use this file? Is it
autogenerated or not? I searched our wiki for "classnames.properties" but found
nothing.
2. trivial compilation error -
org/apache/ignite/internal/processors/datastructures/DataStructuresProcessor.java:1435
- "broken" variable is not final. Vlad, are you sure this is the final version?
3. java 7 generics warning - GridCacheReentrantLockImpl.java:497 + code style
- I will resolve both on PR merge
4. IgniteReentrantLock interface docs seems to be copied from JDK which
is not correct in my view. It contains, for example, a lot of "new
ReentrantLock();" mentions.
5. I think IgniteReentrantLock should:
- rename to IgniteLock
- extend SDK lock interface and override methods for providing proper
documentation.
- newCondition() should throw unsupported operation exception and should send
user to use getOrCreateCondition(String name);
- IgniteCondition should also extend SDK condition and provide proper
documentation
6.
org.apache.ignite.internal.processors.datastructures.GridCacheReentrantLockImpl.Sync#failedNodes
- seems to only grow which is strange and may lead to OOME (of course in
theory, but still). It seems you can remove this collection. You can check if
node is failed or not by checking it with discovery -
kernalContext.discovery().node(id); Will it work?
> Implement IgniteReentrantLock data structure
>
>
> Key: IGNITE-642
> URL: https://issues.apache.org/jira/browse/IGNITE-642
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Vladisav Jelisavcic
>
> We need to add {{IgniteReentrantLock}} data structure in addition to other
> data structures provided by Ignite. {{IgniteReentrantLock}} should have
> similar API to {{java.util.concurrent.locks.ReentrantLock}} class in JDK.
> As an example, you can see how
> [IgniteCountDownLatch|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteCountDownLatch.java]
> is implemented in
> [GridCacheCountDownLatchImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridCacheCountDownLatchImpl.java]
> class.
> In general we need to have an entity in ATOMIC cache storing lock-owner
> identifier together with a queue of waiters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
