IGNITE-1144
Hello all, I was wondering if anyone can take a look at the PR I submitted for IGNITE-1144 [1]. It compiles and I think the code is good but the tests I submitted are failing - specifically, one test: I am using assertThrows() to make sure that an exception is thrown if affinityRun() is invoked on a queue that is not collocated. In the tests I basically set up a queue that has a configuration that invokes setCollocated(false) and then I invoke an affinityRun() with an "empty" job. For some reason the tests are failing with an error that the exception wasn't thrown. However, in this case I actually think that my test is bad and the PR code is good ;-). Can someone with more Java experience take a quick look? Thanks! [1] https://issues.apache.org/jira/browse/IGNITE-1144
[jira] [Created] (IGNITE-2707) SkipStore flag is not overridden for a transaction entry
Alexey Goncharuk created IGNITE-2707:
Summary: SkipStore flag is not overridden for a transaction entry
Key: IGNITE-2707
URL: https://issues.apache.org/jira/browse/IGNITE-2707
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: ignite-1.4
Reporter: Alexey Goncharuk
Fix For: 1.6
Consider the following code snippet:
{code}
try (Transaction tx = ignite.transactions().txStart()) {
cache.withSkipStore().get(key);
cache.put(key, value);
tx.commit();
}
{code}
Transaction commit will not trigger store write because {{skipStore}} flag is
set to {{true}} for the transaction entry and is not overridden on put()
operation (see IgniteTxLocalAdapter:3780).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2708) Need to validate that SPIs are started only once
Valentin Kulichenko created IGNITE-2708:
---
Summary: Need to validate that SPIs are started only once
Key: IGNITE-2708
URL: https://issues.apache.org/jira/browse/IGNITE-2708
Project: Ignite
Issue Type: Improvement
Components: general
Reporter: Valentin Kulichenko
User forum discussion:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-instance-hangs-during-restart-in-client-mode-td3101.html
If one uses the same instance of {{IgniteConfiguration}} more than once, it
doesn't work because SPIs have lifecycle and can be started only once.
Currently this causes hang on start which is counterintuitive.
We should add a validation step to {{GridSpiAdapter}} that will check that the
SPI was never started before. Its {{spiStart()}} method should set some flag
there or throw exception if it has already been set. All internal SPI
implementations should be changed to call {{super.spiStart()}} as first
statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Binary mode for Data Structures
+1 to this change. It sounds like a very important feature for collocated queues, especially after [1] is fixed. [1] https://issues.apache.org/jira/browse/IGNITE-1144 -Val On Sat, Feb 20, 2016 at 3:42 AM, Pavel Tupitsyn wrote: > No replies, so I've created an issue: > https://issues.apache.org/jira/browse/IGNITE-2701 > > On Thu, Feb 18, 2016 at 3:06 PM, Pavel Tupitsyn > wrote: > > > Igniters, > > > > Currently we don't have binary mode (withKeepBinary) in Data Structures > > (Queue, AtomicReference). > > Are there any plans for implementing this, or may be a workaround? > > > > Lack of binary mode prevents us from implementing IgniteQueue in .NET > > (.NET types in most cases can't be deserialized in Java). > > > > AtomicReference is already implemented, and it works because values are > > wrapped in GridCacheAtomicReferenceValue. So there is inconsistent > behavior > > between data structures. > > > > Thoughts? > > > > -- > > -- > > Pavel Tupitsyn > > GridGain Systems, Inc. > > www.gridgain.com > > > > > > -- > -- > Pavel Tupitsyn > GridGain Systems, Inc. > www.gridgain.com >
[jira] [Created] (IGNITE-2709) High contention on a cache key leads to high thread stack usage
Alexey Goncharuk created IGNITE-2709:
Summary: High contention on a cache key leads to high thread stack
usage
Key: IGNITE-2709
URL: https://issues.apache.org/jira/browse/IGNITE-2709
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: ignite-1.4
Reporter: Alexey Goncharuk
Currently {{GridCacheMvccManager#onOwnerChanged}} callback notifies listeners
synchronously. This means that the call stack size for a transaction commit is
proportional to the size of MVCC candidates queue. On a big enough queue size
this leads to a StackOverflowError (see the file attached).
I suggest the {{GridCacheMvccManager:158}} line be executed asynchronously
after some (3-5) nested calls.
The change should be properly benchmarked.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: ODBC processor default behaviour
I think the behavior of OdbcProcessor should be consistent with RestProcessor. It tries a configurable range of ports, binds to the first available and prints it out in the log. -Val On Sat, Feb 20, 2016 at 7:33 AM, Yakov Zhdanov wrote: > Not sure if it works. DB connection string should have certain port afaik. > > --Yakov > > 2016-02-20 18:26 GMT+03:00 Sergey Kozlov : > > > What's about to use the port range like TcpDiscoveryVmIpFinder? > > > > On Sat, Feb 20, 2016 at 6:22 PM, Yakov Zhdanov > > wrote: > > > > > How about outputting warning like and keep retrying in a background > > thread? > > > > > > warning - "Failed to bind ODBC processor TCP server to port (retrying > > every > > > 2 sec) [port=ABC] > > > > > > --Yakov > > > > > > 2016-02-20 17:38 GMT+03:00 Igor Sapego : > > > > > > > Igniters, > > > > > > > > I'm currently working on the ODBC driver. It connects by TCP to the > > > > OdbcProcessor > > > > on the node side. OdbcProcessor is enabled by default and it starts > TCP > > > > server on the > > > > specific TCP port or throws exception if the port is busy. > > > > > > > > The problem is that such behavior breaks tests that start more than > one > > > > node on the > > > > same machine as the second node fails to start because ODBC port is > > > already > > > > taken > > > > by the first node. > > > > > > > > Does anyone has ideas what is the best way to fix that? > > > > > > > > Best Regards, > > > > Igor > > > > > > > > > > > > > > > -- > > Sergey Kozlov > > GridGain Systems > > www.gridgain.com > > >
[GitHub] ignite pull request: Ignite-2707 - Fixed skipStore flag handling.
GitHub user agoncharuk opened a pull request: https://github.com/apache/ignite/pull/508 Ignite-2707 - Fixed skipStore flag handling. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2707 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/508.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 #508 commit 31f91e2959b5ebe25d876dfbbdd43165ff2ec48e Author: Alexey Goncharuk Date: 2016-02-23T02:10:53Z Ignite-2707 - Fixed skipStore flag handling. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: IGNITE-1144
Hi, Thanks for the pull request! I will take a look as soon as possible. -Val On Mon, Feb 22, 2016 at 9:14 AM, Dood@ODDO wrote: > Hello all, > > I was wondering if anyone can take a look at the PR I submitted for > IGNITE-1144 [1]. It compiles and I think the code is good but the tests I > submitted are failing - specifically, one test: I am using assertThrows() > to make sure that an exception is thrown if affinityRun() is invoked on a > queue that is not collocated. In the tests I basically set up a queue that > has a configuration that invokes setCollocated(false) and then I invoke an > affinityRun() with an "empty" job. For some reason the tests are failing > with an error that the exception wasn't thrown. However, in this case I > actually think that my test is bad and the PR code is good ;-). Can someone > with more Java experience take a quick look? > > Thanks! > > [1] https://issues.apache.org/jira/browse/IGNITE-1144 >
[GitHub] ignite pull request: Ignite-2709 - Fixed stack overflow for conten...
GitHub user agoncharuk opened a pull request: https://github.com/apache/ignite/pull/509 Ignite-2709 - Fixed stack overflow for contented puts. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2709 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/509.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 #509 commit 311dcc2e43a13635fe5dc181251c65186869383f Author: Alexey Goncharuk Date: 2016-02-23T02:35:07Z Ignite-2709 - Fixed stack overflow for contented puts. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-2710) Session not unbind from current request after invoke request.getSession().invalidate()
YuxuanWang created IGNITE-2710: -- Summary: Session not unbind from current request after invoke 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 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)
Re: IGNITE-1144
Val, All the test passed on TC - you can look at the PR at any time. Thanks! On 2/22/2016 8:13 PM, Valentin Kulichenko wrote: Hi, Thanks for the pull request! I will take a look as soon as possible. -Val On Mon, Feb 22, 2016 at 9:14 AM, Dood@ODDO wrote: Hello all, I was wondering if anyone can take a look at the PR I submitted for IGNITE-1144 [1]. It compiles and I think the code is good but the tests I submitted are failing - specifically, one test: I am using assertThrows() to make sure that an exception is thrown if affinityRun() is invoked on a queue that is not collocated. In the tests I basically set up a queue that has a configuration that invokes setCollocated(false) and then I invoke an affinityRun() with an "empty" job. For some reason the tests are failing with an error that the exception wasn't thrown. However, in this case I actually think that my test is bad and the PR code is good ;-). Can someone with more Java experience take a quick look? Thanks! [1] https://issues.apache.org/jira/browse/IGNITE-1144
