[jira] [Created] (IGNITE-2633) Make allow to choose several caches in one 'Sender cache' item

Pavel Konstantinov created IGNITE-2633: -- Summary: Make allow to choose several caches in one 'Sender cache' item Key: IGNITE-2633 URL: https://issues.apache.org/jira/browse/IGNITE-2633 Project:

[jira] [Created] (IGNITE-2634) Do not export system columns when thea are not showed in result

Vasiliy Sisko created IGNITE-2634: - Summary: Do not export system columns when thea are not showed in result Key: IGNITE-2634 URL: https://issues.apache.org/jira/browse/IGNITE-2634 Project: Ignite

[GitHub] ignite pull request: Ignite-2509 fixed offHeap_values case

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/470 --- 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

Re: 'Date' and 'Timestamp' types in SQL queries

Ok, then I propose following solution: when user of the C++ client tries to read 'Date' value when there is an 'Timestamp' value in a stream implicit cast from 'Timestamp' to 'Date' happens and user gets his value. What do you think? Best Regards, Igor On Thu, Feb 11, 2016 at 11:25 PM, Vladimir

[jira] [Created] (IGNITE-2636) Server cache metrics for put-get-remove avg time are incorrect for case when request sent from client

Vladimir Ershov created IGNITE-2636: --- Summary: Server cache metrics for put-get-remove avg time are incorrect for case when request sent from client Key: IGNITE-2636 URL:

[jira] [Created] (IGNITE-2641) Improve usability of "SELECT *" SqlQuery.

Vladimir Ozerov created IGNITE-2641: --- Summary: Improve usability of "SELECT *" SqlQuery. Key: IGNITE-2641 URL: https://issues.apache.org/jira/browse/IGNITE-2641 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-2642) The second run of MessagingExampleprints out the received messages twice

Sergey Kozlov created IGNITE-2642: - Summary: The second run of MessagingExampleprints out the received messages twice Key: IGNITE-2642 URL: https://issues.apache.org/jira/browse/IGNITE-2642 Project:

[jira] [Created] (IGNITE-2638) "Connection to Ignite Web Agent is not established" form not in focus

Ilya Suntsov created IGNITE-2638: Summary: "Connection to Ignite Web Agent is not established" form not in focus Key: IGNITE-2638 URL: https://issues.apache.org/jira/browse/IGNITE-2638 Project:

Unfriendly "SELECT *"

Folks, I noticed that the following simple *SqlQuery* doesn't not work: SELECT * FROM Employee e The reason is that it is incorrectly expanded to SELECT *Employee*._KEY, *Employee*._VAL FROM Employee *e* ... while correct form should be: SELECT *e*._KEY, *e*._VAL FROM Employee *e* I understand

[GitHub] ignite pull request: IGNTIE-2483 Cache metrics functionality for c...

GitHub user VladimirErshov opened a pull request: https://github.com/apache/ignite/pull/479 IGNTIE-2483 Cache metrics functionality for client nodes should be developed. Added new version of CacheMetricsSnapshot. Fixed merging logic. Added proper put/get/remove time

[GitHub] ignite pull request: IGNITE-2635: Timestamp values can be read as ...

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/477 IGNITE-2635: Timestamp values can be read as Date now. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite ignite-2635

[jira] [Created] (IGNITE-2639) Need to handle security token changing

Pavel Konstantinov created IGNITE-2639: -- Summary: Need to handle security token changing Key: IGNITE-2639 URL: https://issues.apache.org/jira/browse/IGNITE-2639 Project: Ignite Issue

[jira] [Created] (IGNITE-2640) [Failed test] ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper

Andrey Gura created IGNITE-2640: --- Summary: [Failed test] ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper Key: IGNITE-2640 URL: https://issues.apache.org/jira/browse/IGNITE-2640 Project: Ignite

[GitHub] ignite pull request: ignite-2640 Zookeeper test timeout increased

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/478 ignite-2640 Zookeeper test timeout increased You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-2640 Alternatively

[jira] [Created] (IGNITE-2643) ODBC: Potential memory leak during client disconnect.

Vladimir Ozerov created IGNITE-2643: --- Summary: ODBC: Potential memory leak during client disconnect. Key: IGNITE-2643 URL: https://issues.apache.org/jira/browse/IGNITE-2643 Project: Ignite

Grid behavior at key deserialization failure during rebalancing

Igniters, At this moment key deserialization failure during rebalancing cause strange situation: Rebalancing from node sent supply message with broken key will be cancelled at current topology. All upcoming supply messages from this node will be be ignored, no new demand messages to this node

[jira] [Created] (IGNITE-2645) Assertion error in ATOMIC cachce for invokeAll and cache store

Alexey Goncharuk created IGNITE-2645: Summary: Assertion error in ATOMIC cachce for invokeAll and cache store Key: IGNITE-2645 URL: https://issues.apache.org/jira/browse/IGNITE-2645 Project:

[jira] [Created] (IGNITE-2644) ODBC: Add metrics.

Vladimir Ozerov created IGNITE-2644: --- Summary: ODBC: Add metrics. Key: IGNITE-2644 URL: https://issues.apache.org/jira/browse/IGNITE-2644 Project: Ignite Issue Type: Sub-task

[jira] [Created] (IGNITE-2637) CPP: Some API function throw exceptions even if err parameter is specified.

Igor Sapego created IGNITE-2637: --- Summary: CPP: Some API function throw exceptions even if err parameter is specified. Key: IGNITE-2637 URL: https://issues.apache.org/jira/browse/IGNITE-2637 Project:

Re: 'Date' and 'Timestamp' types in SQL queries

Igor, I will wait for Vova to comment on your last suggestion. Just wanted to add that we should be careful not to loose any precision during the conversion, as we got hit by it in the past. D. On Fri, Feb 12, 2016 at 1:36 AM, Igor Sapego wrote: > Ok, then I propose

[jira] [Created] (IGNITE-2646) IgniteCompute.withAsync can execute tasks synchronously

Andrey Gura created IGNITE-2646: --- Summary: IgniteCompute.withAsync can execute tasks synchronously Key: IGNITE-2646 URL: https://issues.apache.org/jira/browse/IGNITE-2646 Project: Ignite Issue

Re: IgniteCompute.withAsync can execute tasks synchronously

I've created ticket https://issues.apache.org/jira/browse/IGNITE-2646 On Thu, Feb 11, 2016 at 4:12 PM, Andrey Gura wrote: > Dmitry, > > GridTaskProcessor does't know what kind of IgniteCompute implementation > was used by client code. So we need some kind of flag that will

[GitHub] ignite pull request: ignite-169 GridSessionCheckpointSelfTest.test...

Github user agura closed the pull request at: https://github.com/apache/ignite/pull/472 --- 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

[GitHub] ignite pull request: ignite-2588 Test fixed

Github user agura closed the pull request at: https://github.com/apache/ignite/pull/463 --- 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

[jira] [Created] (IGNITE-2647) Cache is undeployed even when BinaryMarshaller is used

Denis Magda created IGNITE-2647: --- Summary: Cache is undeployed even when BinaryMarshaller is used Key: IGNITE-2647 URL: https://issues.apache.org/jira/browse/IGNITE-2647 Project: Ignite Issue

Re: Unfriendly "SELECT *"

Sergi, This problem is more about aliases, then about "SELECT *". The query FROM Employee e doesn't work either. And this is the problem, because as soon as JOINs appear, aliases greatly help to reduce SQL boilerplate. And as I understand it is hard to make this query work due to complex

Re: Unfriendly "SELECT *"

Use SqlFieldsQuery, Luke! I tried, it works! :) I was always against SELECT in SqlQuery, it was terrible design decision, but for "historical reasons" it is supported in SqlQuery. As for adding new parsing, the more fancier parsing we will introduce, the worse performance we will have. Sergi

Async and sync ops in IgniteQueue and IgniteSet implementations

Hello all, This may be a very dumb question (and feel free to "reprimand" me ;-) but I will ask it anyways. I am working on https://issues.apache.org/jira/browse/IGNITE-1144 and one of the comments on the submitted code was that I marked both methods I am implemented as

Re: Async and sync ops in IgniteQueue and IgniteSet implementations

Hi, First of all, the JavaDoc is incorrect, there are no async counterparts for queue and set operations in the current API. The question is - do we need them? I think we should have have them for new affinityRun and affinityCall methods that you're adding, but I'm not sure about others. Does

Re: Async and sync ops in IgniteQueue and IgniteSet implementations

Val, My question was also - if all I am doing is calling affinityRun() and affinityCall() that is already implemented elsewhere (just making sure it is done on a collocated queue/set) - do I need to do anything special looking at IgniteComputeImpl.java it looks like affinityRun()/Call() are

Re: Async and sync ops in IgniteQueue and IgniteSet implementations

For affinityRun and affinityCall you don't need to implement anything for async support, because this is already supported by IgniteCompute. But you have to add async support to the API as I described in earlier the ticket, because currently there is no way to get the Future from queue or set.

Re: labeling tickets that come from user list

OK, “community” it is then. Let us all follow this guideline to ensure that we are able to properly prioritize Jira tickets. On Fri, Feb 12, 2016 at 12:40 PM, Denis Magda wrote: > I label such tickets as "community". > > It aggregates tickets coming from both user & dev

Ignite components deserialization

Folks, I reopened the ticket where we improved the serialization of Ignite components [1]. >From what I can see, the fix was made for IgniteKernal, but not for other classes like ClusterGroupAdapter, GridKernalContextImpl and others. What is the reason for this? Vladimir Ershov, it looks like

Re: labeling tickets that come from user list

I label such tickets as "community". It aggregates tickets coming from both user & dev lists. Let's use this label? On Friday, February 12, 2016, Dmitriy Setrakyan wrote: > Igniters, > > I think that we should start labeling tickets that come form user lists. > Such

Re: Ignite components deserialization

I have also looked at the ticket, and I do not see if the review was done there. Can I please ask all the committers to make sure to add review comments to the tickets? Otherwise, it is impossible to understand the history of the fix. Thanks, D. On Fri, Feb 12, 2016 at 3:30 PM, Valentin

Re: Grid behavior at key deserialization failure during rebalancing

Anton, I am not sure I fully grok the use case. Can you please explain why a key can be broken? D. On Fri, Feb 12, 2016 at 7:11 AM, Anton Vinogradov wrote: > Igniters, > > At this moment key deserialization failure during rebalancing cause strange > situation: > >