[jira] [Created] (IGNITE-2624) Hide the Clone, Remove buttons if current item is not match the filter

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2624:
--

 Summary: Hide the Clone, Remove buttons if current item is not 
match the filter
 Key: IGNITE-2624
 URL: https://issues.apache.org/jira/browse/IGNITE-2624
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


Currently these buttons are available 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

MyBatis-Ignite integration release

[Roman Shtykh]

Dear community,

I would like to share the news about MyBatis-Ignite integration release, as a 
result of the collaboration between Ignite and MyBatis teams.

http://blog.mybatis.org/2016/02/mybatis-ignite-released.html

>From now please consider using Apache Ignite as your 2nd level MaBatis cache.

Best regards,
Roman

Re: streamer documentation

[Denis Magda]

Thanks Raul!

Please don't forget to add the doc to both 1.5 and 1.6 [1], that has 
been recently created.


[1] https://apacheignite.readme.io/v1.6

--
Denis

On 2/11/2016 1:34 AM, Raul Kripalani wrote:

Hey guys,

I'll take care of Camel and MQTT this week(end).

Thanks for the patience.

Cheers,
Raúl.

On Tue, 2 Feb 2016 08:49 Denis Magda  wrote:


Dmitriy,

Raul contributed both Camel and MQTT.
Twitter streamer was implemented by Lalit Kumar Jha.

Actually I tried reach out both Raul and Lalit Kumar Jha earlier
regarding this topic but seems that they were too busy because I didn't
get any response from them.

Raul, Lalit Kumar Jha, do you have time to add the documentation or
someone else from the community should take care of this?

Regards,
Denis

On 2/2/2016 11:42 AM, Dmitriy Setrakyan wrote:

Denis,

Is there any chance you can mention the names of the contributors, so we
could reach out to them personally and ask for help with the

documentation?

I know that Camel streamer was done by Raul, but not sure about the other
two.

D.

On Tue, Feb 2, 2016 at 12:37 AM, Denis Magda 

wrote:

The tickets are already there

Twitter: https://issues.apache.org/jira/browse/IGNITE-2413
MQTT: https://issues.apache.org/jira/browse/IGNITE-2411
Camel: https://issues.apache.org/jira/browse/IGNITE-2530

It would be perfect if Igniters who contributed this functionality will
add the documentation as well.

--
Denis


On 2/2/2016 11:31 AM, Dmitriy Setrakyan wrote:


Igniters,

I have been trying to find documentation for the following streamers

but

couldn’t:

- Camel
- MQTT
- Twitter

Can I ask the contributors to document these features on readme?

Thanks,
D.

Re: Transformers in SCAN queries

[Valentin Kulichenko]

I changed the description in the ticket. If anyone has comments about the
implementation details, feel free to add them there.

-Val

On Wed, Feb 10, 2016 at 2:30 PM, Dmitriy Setrakyan 
wrote:

> I like the new method on IgniteCache API:
>
>  QueryCursor query(Query qry, Transformer transformer);
>
> I do agree that it makes little sense for the SqlFieldsQuery, but we can
> simply throw an unsupported exception here. For all other queries it does
> make sense.
>
> Val, can you put together all the thoughts expressed in this thread into a
> ticket?
>
> D.
>
> On Thu, Feb 4, 2016 at 4:14 PM, Andrey Gura  wrote:
>
> > Val,
> >
> > From my point of view, special query class that allows transforming is
> > confusing. Two points about it:
> >
> > 1. ScanTransformQuery will duplicate ScanQuery code with all drawbacks
> that
> > we have. Moreover, any fix for ScanQuery should be repeated for
> > ScanTransformQuery. It will lead to bugs. DRY.
> >
> > 2. If some users want to do transformations for SqlQuery we will
> introduce
> > SqlTransformQuery. Right? At this point see previous item.
> >
> > Transformation logic is some kind of strategy. IMHO, the most convenient
> > API should get transformation logic as some function provided by user.
> >
> > On Thu, Feb 4, 2016 at 11:05 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Agree with Sergi. Mixing SQL with Java code transformers is confusing.
> In
> > > rare case when it's really required, user can implement a custom
> > function.
> > >
> > > I copy-pasted the API to the ticket [1]. Please provide any additional
> > > comments there.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-2546
> > >
> > > -Val
> > >
> > > On Thu, Feb 4, 2016 at 10:08 AM, Andrey Gura 
> wrote:
> > >
> > > > Sergi,
> > > >
> > > >
> > > > > What you are going to transform remotely here?
> > > >
> > > >
> > > > I'm not going. I believe :)
> > > >
> > > > Just hypothetical use case: You have one SqlFieldsQuery but different
> > > > requirements for returned values. For one case you have to return
> some
> > > > string fields as is and for another case you have to trim string to
> 32
> > > > characters. Of course you still can trim strings locally but
> > transformers
> > > > allow you do it remotely.
> > > >
> > > > Anyway, this solution can be usefull for rest query types.
> > > >
> > > > On Thu, Feb 4, 2016 at 8:54 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > The whole point of Transformer is to do remote transform, how will
> > this
> > > > > work with SqlFieldsQuery? What you are going to transform remotely
> > > here?
> > > > I
> > > > > believe all the transformations must happen at SQL level here.
> > > > >
> > > > > Sergi
> > > > >
> > > > >
> > > > >
> > > > > 2016-02-04 20:10 GMT+03:00 Andrey Gura :
> > > > >
> > > > > > SqlQuery, TextQuery and SpiQuery are similar to ScanQuery because
> > all
> > > > of
> > > > > > them also defined as Query>.
> > > > > >
> > > > > > It can be usefull to have one query SqlQuery that can return
> > > different
> > > > > > result that will be produced from cache entry by transformer.
> > > > > >
> > > > > > Actually only SqlFieldsQuery has different definition. So
> > > transformers
> > > > > can
> > > > > > be applied to any type of query (including SqlFieldsQuery, I
> > > believe).
> > > > > >
> > > > > > On Thu, Feb 4, 2016 at 7:42 PM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I don't like the idea of having additional method
> *query(Query
> > > > qry,
> > > > > > > Transformer transfomer); *because I don't see how these
> > > > > > transformers
> > > > > > > will work for example with SQL, but this API makes you think
> that
> > > > > > > transformers are supported for all the query types.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2016-02-04 16:46 GMT+03:00 Andrey Gura :
> > > > > > >
> > > > > > > > Val,
> > > > > > > >
> > > > > > > > can we introduce new method into IgnteCache API?
> > > > > > > >
> > > > > > > > Now we have method: public  QueryCursor query(Query
> > > qry);
> > > > > > > >
> > > > > > > > New method will be something like this:  QueryCursor
> > > > > > query(Query
> > > > > > > > qry, Transformer transfomer);
> > > > > > > >
> > > > > > > > It allows provide transformers for all query types and
> chnages
> > > will
> > > > > be
> > > > > > > > related only with query cursor functionality.
> > > > > > > >
> > > > > > > > Will it work?
> > > > > > > >
> > > > > > > > On Thu, Feb 4, 2016 at 11:13 AM, Andrey Kornev <
> > > > > > andrewkor...@hotmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Another perhaps bigger problem with running queries
> > (including
> > > > scan
> > > > > > > > > queries) using closures was discussed at length on the @dev
> > not
> > > > so
> > > > > > long
> > > > > > > > > ago. It has to do with p

Re: streamer documentation

[Raul Kripalani]

Hey guys,

I'll take care of Camel and MQTT this week(end).

Thanks for the patience.

Cheers,
Raúl.

On Tue, 2 Feb 2016 08:49 Denis Magda  wrote:

> Dmitriy,
>
> Raul contributed both Camel and MQTT.
> Twitter streamer was implemented by Lalit Kumar Jha.
>
> Actually I tried reach out both Raul and Lalit Kumar Jha earlier
> regarding this topic but seems that they were too busy because I didn't
> get any response from them.
>
> Raul, Lalit Kumar Jha, do you have time to add the documentation or
> someone else from the community should take care of this?
>
> Regards,
> Denis
>
> On 2/2/2016 11:42 AM, Dmitriy Setrakyan wrote:
> > Denis,
> >
> > Is there any chance you can mention the names of the contributors, so we
> > could reach out to them personally and ask for help with the
> documentation?
> > I know that Camel streamer was done by Raul, but not sure about the other
> > two.
> >
> > D.
> >
> > On Tue, Feb 2, 2016 at 12:37 AM, Denis Magda 
> wrote:
> >
> >> The tickets are already there
> >>
> >> Twitter: https://issues.apache.org/jira/browse/IGNITE-2413
> >> MQTT: https://issues.apache.org/jira/browse/IGNITE-2411
> >> Camel: https://issues.apache.org/jira/browse/IGNITE-2530
> >>
> >> It would be perfect if Igniters who contributed this functionality will
> >> add the documentation as well.
> >>
> >> --
> >> Denis
> >>
> >>
> >> On 2/2/2016 11:31 AM, Dmitriy Setrakyan wrote:
> >>
> >>> Igniters,
> >>>
> >>> I have been trying to find documentation for the following streamers
> but
> >>> couldn’t:
> >>>
> >>> - Camel
> >>> - MQTT
> >>> - Twitter
> >>>
> >>> Can I ask the contributors to document these features on readme?
> >>>
> >>> Thanks,
> >>> D.
> >>>
> >>>
>
>

Re: Transformers in SCAN queries

[Dmitriy Setrakyan]

I like the new method on IgniteCache API:

 QueryCursor query(Query qry, Transformer transformer);

I do agree that it makes little sense for the SqlFieldsQuery, but we can
simply throw an unsupported exception here. For all other queries it does
make sense.

Val, can you put together all the thoughts expressed in this thread into a
ticket?

D.

On Thu, Feb 4, 2016 at 4:14 PM, Andrey Gura  wrote:

> Val,
>
> From my point of view, special query class that allows transforming is
> confusing. Two points about it:
>
> 1. ScanTransformQuery will duplicate ScanQuery code with all drawbacks that
> we have. Moreover, any fix for ScanQuery should be repeated for
> ScanTransformQuery. It will lead to bugs. DRY.
>
> 2. If some users want to do transformations for SqlQuery we will introduce
> SqlTransformQuery. Right? At this point see previous item.
>
> Transformation logic is some kind of strategy. IMHO, the most convenient
> API should get transformation logic as some function provided by user.
>
> On Thu, Feb 4, 2016 at 11:05 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Agree with Sergi. Mixing SQL with Java code transformers is confusing. In
> > rare case when it's really required, user can implement a custom
> function.
> >
> > I copy-pasted the API to the ticket [1]. Please provide any additional
> > comments there.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-2546
> >
> > -Val
> >
> > On Thu, Feb 4, 2016 at 10:08 AM, Andrey Gura  wrote:
> >
> > > Sergi,
> > >
> > >
> > > > What you are going to transform remotely here?
> > >
> > >
> > > I'm not going. I believe :)
> > >
> > > Just hypothetical use case: You have one SqlFieldsQuery but different
> > > requirements for returned values. For one case you have to return some
> > > string fields as is and for another case you have to trim string to 32
> > > characters. Of course you still can trim strings locally but
> transformers
> > > allow you do it remotely.
> > >
> > > Anyway, this solution can be usefull for rest query types.
> > >
> > > On Thu, Feb 4, 2016 at 8:54 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > > wrote:
> > >
> > > > The whole point of Transformer is to do remote transform, how will
> this
> > > > work with SqlFieldsQuery? What you are going to transform remotely
> > here?
> > > I
> > > > believe all the transformations must happen at SQL level here.
> > > >
> > > > Sergi
> > > >
> > > >
> > > >
> > > > 2016-02-04 20:10 GMT+03:00 Andrey Gura :
> > > >
> > > > > SqlQuery, TextQuery and SpiQuery are similar to ScanQuery because
> all
> > > of
> > > > > them also defined as Query>.
> > > > >
> > > > > It can be usefull to have one query SqlQuery that can return
> > different
> > > > > result that will be produced from cache entry by transformer.
> > > > >
> > > > > Actually only SqlFieldsQuery has different definition. So
> > transformers
> > > > can
> > > > > be applied to any type of query (including SqlFieldsQuery, I
> > believe).
> > > > >
> > > > > On Thu, Feb 4, 2016 at 7:42 PM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > I don't like the idea of having additional method *query(Query
> > > qry,
> > > > > > Transformer transfomer); *because I don't see how these
> > > > > transformers
> > > > > > will work for example with SQL, but this API makes you think that
> > > > > > transformers are supported for all the query types.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2016-02-04 16:46 GMT+03:00 Andrey Gura :
> > > > > >
> > > > > > > Val,
> > > > > > >
> > > > > > > can we introduce new method into IgnteCache API?
> > > > > > >
> > > > > > > Now we have method: public  QueryCursor query(Query
> > qry);
> > > > > > >
> > > > > > > New method will be something like this:  QueryCursor
> > > > > query(Query
> > > > > > > qry, Transformer transfomer);
> > > > > > >
> > > > > > > It allows provide transformers for all query types and chnages
> > will
> > > > be
> > > > > > > related only with query cursor functionality.
> > > > > > >
> > > > > > > Will it work?
> > > > > > >
> > > > > > > On Thu, Feb 4, 2016 at 11:13 AM, Andrey Kornev <
> > > > > andrewkor...@hotmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Another perhaps bigger problem with running queries
> (including
> > > scan
> > > > > > > > queries) using closures was discussed at length on the @dev
> not
> > > so
> > > > > long
> > > > > > > > ago. It has to do with partitions migration due to cluster
> > > topology
> > > > > > > changes
> > > > > > > > which may result in the query returning incomplete result.
> And
> > > > while
> > > > > it
> > > > > > > is
> > > > > > > > possible to solve this problem for the scan queries by using
> > some
> > > > > > clever
> > > > > > > > tricks, all bets are off with the SQL queries.Andrey
> > > > > > > > _
> > > > > > > > From: Valentin Kulichenko 
> > > > > > > > Sent: Thursd

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

[Dmitriy Setrakyan]

I remember seeing some work done for the .NET support to provide better
precision for time data values. Could it be that SQL now converts
everything to Timestamp because of that?

D.

On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego  wrote:

> Hello,
>
> Recently I've been working on implementation of the Date and Timestamp
> types support for C++ client [1] and I today have faced an issue when I was
> running tests with Date and SqlFieldQuery.
>
> Here is the issue. I have class that have field of type 'Date'. I was able
> to create
> instances of that class and put them in a cache, but when I tried to
> retrieve
> these fields with SQL query I've got an exception. After the short debug
> session
> I have found that the values that SQL queries return are of type
> 'Timestamp'.
>
> So now I'm wonder, is it an expected behavior? Because to me it looks like
> something that may be very confusing for a user. User knows that object's
> field
> is of type 'Date' but when they try to call GetNext on query row they
> get an
> exception.
>
> I have also tested simple caches with Date where Date is a value and these
> tests
> work just fine with 'Date' returned as a result of Cache#Get() requests.
>
> [1] - IGNITE-: CPP: Implement Date and Timestamp data types support for
> binary protocol. 
> Best Regards,
> Igor
>

Re: Full API coverage enhancement

[Dmitriy Setrakyan]

Agree about separation. I think we need to define some internal
permutations that keep coming up with bugs. I can start the list here:

   1. Serializable, Externalizable, neither.
   1. We should run the whole suite 3 times, once for each serialization
  mode. Having 2 or 3 nodes in the cluster here should be enough.
No need to
  test it on the changing cluster.
   2. On-heap and off-heap with entry processor and peer-deployment
   1. on-heap, entry-processor, peer-deployment=true/false
  2. off-heap, entry-processor, peer-deployment=true/false
   3. On-heap and off-heap with eviction policies
  1. eviction policy, memory-mode=on-heap
  2. eviction policy, memory-mode=off-heap
  3. eviction policy, memory-mode=off-heap-values
   4. On-heap and off-heap with continuous queries and
   peer-deployment=true/false
   5. …

I think we can come up with about 20 most important permutations. Thoughts?

D.


On Wed, Feb 10, 2016 at 9:24 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Dmitriy, the size of the circular buffer can be decreased by setting
> IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE system property.
>
> I was wondering what our next steps will be after implementing the
> framework. From the initial discussion I thought we want to convert some
> older tests to this new framework and run all new tests using this
> framework. However, from what Artem already has written, this sounds
> unrealistic because adding even a simple test case will induce hours of run
> time. I think we still need to separate more important and less important
> configurations, run important ones on a daily basis, and use all others for
> after-code-freeze runs, for example.
>
> Thoughts?
>

Re: IgniteCompute.withAsync can execute tasks synchronously

[Dmitriy Setrakyan]

Andrey,

I think we should keep it simple. From the API standpoint, I am not sure
why not just always execute the task asynchronously every time when
withAsync() API is invoked? Why add additional parameters to the API?

D.

On Wed, Feb 10, 2016 at 6:53 AM, Andrey Gura  wrote:

> Guys,
>
> during debugging of failed test
> (GridSessionCheckpointSelfTest.testSharedFsCheckpoint) I've noticed that
> GridTaskWorker can invoke reduce() method in caller thread.
>
> If task isn't annotated by @ComputeTaskMapAsync then mapping job will be
> run in caller thread. Since job mapping will be finished
> processDelayedResponses() method will be invoked and if delayed responses
> queue isn't empty then caller thread can invoke reduce() method eventually
> and perform reducing synchronously.
>
> It can be usefull in case of synchronous execution but, IMHO, it is very
> strange behavior for asynchronous case because user expects that method
> will return after creation of task.
>
> Similar behavior is possible for all places where code invokes
> GridTaskProcessor.execute() method (IgniteCompute.broadcast(),
> IgniteCAche.size(), REST handlers, etc.)
>
> I see three options in order to fix the problem:
>
> 1. Remove GridTaskWorker.processDelayedResponses() method and all calls.
> Perhaps, performance can sufer a little bit (but I'm not sure).
>
> 2. Add special flag to execute method (e.g. usePool) that will give
> guarantees that task will not be executed in caller thread. Of course this
> flag should be add for all methods in call chain.
>
> 3. Use task process thread context (GridTaskProcessor.thCtx) and special
> key that will represent requirement about execution task in pool similar to
> usePool flag.
>
> In case of 2nd and 3rd options we should analyze every usage of
> GridTaskProcessor.execute() method and solve should caller thread execute
> task or not.
>
> Maybe I missed something and there is better way to solve this problem.
>
> I will be grateful for any advice or idea.
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>

[jira] [Created] (IGNITE-2623) [Failed test] ClientTcpMultiThreadedSelfTest.testMultithreadedTaskRun

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-2623:
---

 Summary: [Failed test] 
ClientTcpMultiThreadedSelfTest.testMultithreadedTaskRun
 Key: IGNITE-2623
 URL: https://issues.apache.org/jira/browse/IGNITE-2623
 Project: Ignite
  Issue Type: Test
Affects Versions: 1.5.0.final
Reporter: Andrey Gura
Assignee: Andrey Gura


{{ClientTcpMultiThreadedSelfTest.testMultithreadedTaskRun}} test fails 
periodically.

{noformat}
java.lang.Exception: class 
org.apache.ignite.internal.client.GridClientException: Failed to deserialize 
object with given class loader: IsolatedClassLoader{roleName='test'}
at 
org.apache.ignite.internal.client.ClientAbstractMultiThreadedSelfTest.testMultithreadedTaskRun(ClientAbstractMultiThreadedSelfTest.java:279)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1723)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.ignite.internal.client.GridClientException: Failed to 
deserialize object with given class loader: IsolatedClassLoader{roleName='test'}
at 
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:612)
at 
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:547)
at 
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:628)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:270)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
at 
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:107)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:107)
at 
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:2246)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:173)
at 
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:759)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:1512)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:1445)
at 
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1280)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Possible problem:

* N threads are trying to execute task.
* The first thread is trying to put registered class into marshaller cache (see 
{{MarshallerContextImpl.registerClassName}}). Performs put locally and waiting 
for responses from backups.
* The second thread get registered class locally (first thread already updated 
cache) and send task to remote node.
* Remote node (it is backup node) trying to deserialize task and get class 
descriptor by {{typeId}}. But update from first thread still is not executed on 
this node. Task execution fails because can't deserialize task.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

'Date' and 'Timestamp' types in SQL queries

[Igor Sapego]

Hello,

Recently I've been working on implementation of the Date and Timestamp
types support for C++ client [1] and I today have faced an issue when I was
running tests with Date and SqlFieldQuery.

Here is the issue. I have class that have field of type 'Date'. I was able
to create
instances of that class and put them in a cache, but when I tried to
retrieve
these fields with SQL query I've got an exception. After the short debug
session
I have found that the values that SQL queries return are of type
'Timestamp'.

So now I'm wonder, is it an expected behavior? Because to me it looks like
something that may be very confusing for a user. User knows that object's
field
is of type 'Date' but when they try to call GetNext on query row they
get an
exception.

I have also tested simple caches with Date where Date is a value and these
tests
work just fine with 'Date' returned as a result of Cache#Get() requests.

[1] - IGNITE-: CPP: Implement Date and Timestamp data types support for
binary protocol. 
Best Regards,
Igor

Re: NoopSwapSpaceSpi and dynamically started caches

[Dmitriy Setrakyan]

Artem,

I like the option with proper exception in case if a dynamic cache is
started with swap enabled while there was no swap configured in Ignite.

Starting FileSwapSpaceSpi all the time is not a good option as user will
face the same problem when trying to change to a different SPI.

D.

On Wed, Feb 10, 2016 at 4:39 AM, Artem Shutak  wrote:

> Igniters,
>
> I've noticed an issue with NoopSwapSpaceSpi and dynamically started cashes.
>
> We have the following logic on node start:
>
> if (cfg.getSwapSpaceSpi() == null) {
> boolean needSwap = false;
>
> if (cfg.getCacheConfiguration() != null &&
> !Boolean.TRUE.equals(cfg.isClientMode())) {
> for (CacheConfiguration c :
> cfg.getCacheConfiguration()) {
> if (c.isSwapEnabled()) {
> needSwap = true;
>
> break;
> }
> }
> }
>
> cfg.setSwapSpaceSpi(needSwap ? new FileSwapSpaceSpi() : new
> NoopSwapSpaceSpi());
> }
>
> According to the code above, if IgniteConfiguration doesn't contain cache
> configurations or all configured caches configured without swap, then node
> will be started with NoopSwapSpaceSpi.
> As a result in this case, when we start dynamic cache with enabled swap
> then actually swap doesn't work.
>
> There is simple workaround - user have to explicitly set FileSwapSpaceSpi
> to configuration. But now, there is no any warning or exception.
>
> What we can do:
>
>1. Throw an exception on dynamic cache start (with swap enabled)
>if NoopSwapSpaceSpi is configured.
>2. Actually, I don't see why we need NoopSwapSpaceSpi at all. I think we
>should configure FileSwapSpaceSpi always if user doesn't provide any
>SwapSpaceSpi explicitly.
>
> Thoughts?
>
> Thanks,
> -- Artem --
>

Re: Full API coverage enhancement

[Alexey Goncharuk]

Dmitriy, the size of the circular buffer can be decreased by setting
IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE system property.

I was wondering what our next steps will be after implementing the
framework. From the initial discussion I thought we want to convert some
older tests to this new framework and run all new tests using this
framework. However, from what Artem already has written, this sounds
unrealistic because adding even a simple test case will induce hours of run
time. I think we still need to separate more important and less important
configurations, run important ones on a daily basis, and use all others for
after-code-freeze runs, for example.

Thoughts?

[GitHub] ignite pull request: added missing file header to org.apache.ignit...

[iveselovskiy]

Github user iveselovskiy closed the pull request at:

https://github.com/apache/ignite/pull/473


---
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.
---

[GitHub] ignite pull request: added missing file header to org.apache.ignit...

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

https://github.com/apache/ignite/pull/473

added missing file header to org.apache.ignite.hadoop.fs.KerberosHado…

…opFileSystemFactorySelfTest

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/iveselovskiy/ignite ignite-2195c

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/473.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 #473


commit a652adec401dc11e6f930fcef9de9b2ee5ecdbb9
Author: iveselovskiy 
Date:   2016-02-10T15:54:36Z

added missing file header to 
org.apache.ignite.hadoop.fs.KerberosHadoopFileSystemFactorySelfTest




---
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.
---

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

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/472

ignite-169 GridSessionCheckpointSelfTest.testSharedFsCheckpoint test …

…fixed

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-169

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/472.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 #472


commit 8788059de3febfdf44bd2c68b5c283d6b9e978fa
Author: agura 
Date:   2016-02-10T14:58:46Z

ignite-169 GridSessionCheckpointSelfTest.testSharedFsCheckpoint test fixed




---
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.
---

IgniteCompute.withAsync can execute tasks synchronously

[Andrey Gura]

Guys,

during debugging of failed test
(GridSessionCheckpointSelfTest.testSharedFsCheckpoint) I've noticed that
GridTaskWorker can invoke reduce() method in caller thread.

If task isn't annotated by @ComputeTaskMapAsync then mapping job will be
run in caller thread. Since job mapping will be finished
processDelayedResponses() method will be invoked and if delayed responses
queue isn't empty then caller thread can invoke reduce() method eventually
and perform reducing synchronously.

It can be usefull in case of synchronous execution but, IMHO, it is very
strange behavior for asynchronous case because user expects that method
will return after creation of task.

Similar behavior is possible for all places where code invokes
GridTaskProcessor.execute() method (IgniteCompute.broadcast(),
IgniteCAche.size(), REST handlers, etc.)

I see three options in order to fix the problem:

1. Remove GridTaskWorker.processDelayedResponses() method and all calls.
Perhaps, performance can sufer a little bit (but I'm not sure).

2. Add special flag to execute method (e.g. usePool) that will give
guarantees that task will not be executed in caller thread. Of course this
flag should be add for all methods in call chain.

3. Use task process thread context (GridTaskProcessor.thCtx) and special
key that will represent requirement about execution task in pool similar to
usePool flag.

In case of 2nd and 3rd options we should analyze every usage of
GridTaskProcessor.execute() method and solve should caller thread execute
task or not.

Maybe I missed something and there is better way to solve this problem.

I will be grateful for any advice or idea.

-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

[GitHub] ignite pull request: IGNITE-2544: Empty schema names treated as a ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/456


---
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.
---

[GitHub] ignite pull request: IGNITE-2543: Tables look up now return tables...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/454


---
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.
---

[GitHub] ignite pull request: IGNITE-2522: Now null-columns are included to...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/445


---
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.
---

[GitHub] ignite pull request: IGNITE-2495: ODBC: One-row queries can not be...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/438


---
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-2622) Excessive memory usage by objects of destroyed caches

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-2622:


 Summary: Excessive memory usage by objects of destroyed caches
 Key: IGNITE-2622
 URL: https://issues.apache.org/jira/browse/IGNITE-2622
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: ignite-1.4
Reporter: Alexey Goncharuk


If I start and stop tens of caches in a loop, cache's configuration gets stored 
in the following objects:
 * PartitionExchangeFuture.reqs Change requests contain configuration which is 
then used in cache
 * ServerImpl.PendingMessages.msgs also contain the same reqs

Both collections are limited, however consider the following scenario: create a 
cache with an eviction policy, fill it up with data, destroy cache, repeat. 
Even though the cache is destroyed, it's entries are saved in the eviction 
policy and do not get collected until both exchange future and pending message 
(see above) gets cleared.

Possible solutions:
 * Use a copy of eviction policy for cache creation.
 * Clear requests in exchange future after it's done (easy) and discovery 
custom message when it's not needed (hard)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2621) .NET: Compute may fail in mixed-platform cluster

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2621:
--

 Summary: .NET: Compute may fail in mixed-platform cluster
 Key: IGNITE-2621
 URL: https://issues.apache.org/jira/browse/IGNITE-2621
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Priority: Critical
 Fix For: 1.6


Start Java-only node, start .NET node, attempt to execute a computation. 
.NET jobs will fail on Java-only nodes.

1) Make sure that .NET nodes can be identified (via an attribute)
2) Use .NET projection in platform compute. 
If Affinity computation maps to a Java-only node, there will be a 
ClusterGroupEmptyException



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: Ignite 2195 "Accessing from IGFS to HDFS that...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/464


---
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.
---

[GitHub] ignite pull request: Ignite 2396 - Service deployment for dynamic ...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

https://github.com/apache/ignite/pull/471

Ignite 2396 - Service deployment for dynamic caches



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agoncharuk/ignite ignite-2396

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/471.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 #471


commit d708e874d6e1a4c939043e5af79639a8460a7ff0
Author: Alexey Goncharuk 
Date:   2016-01-28T10:13:46Z

IGNITE-2396 - Fixed service deployment for dynamic cache creation.

commit 8bac590668605e55c22159ce37ca6c8a8ae0f410
Author: Alexey Goncharuk 
Date:   2016-01-28T10:13:46Z

IGNITE-2396 - Fixed service deployment for dynamic cache creation.

commit c9dd3e2a32dc1cc6e395c432ae385baefdb2c33e
Author: Alexey Goncharuk 
Date:   2016-02-10T12:38:32Z

Merge branch 'ignite-2396' of github.com:agoncharuk/ignite into ignite-2396




---
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.
---

[GitHub] ignite pull request: IGNITE-2396 - Fixed service deployment for dy...

[agoncharuk]

Github user agoncharuk closed the pull request at:

https://github.com/apache/ignite/pull/432


---
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.
---

NoopSwapSpaceSpi and dynamically started caches

[Artem Shutak]

Igniters,

I've noticed an issue with NoopSwapSpaceSpi and dynamically started cashes.

We have the following logic on node start:

if (cfg.getSwapSpaceSpi() == null) {
boolean needSwap = false;

if (cfg.getCacheConfiguration() != null &&
!Boolean.TRUE.equals(cfg.isClientMode())) {
for (CacheConfiguration c :
cfg.getCacheConfiguration()) {
if (c.isSwapEnabled()) {
needSwap = true;

break;
}
}
}

cfg.setSwapSpaceSpi(needSwap ? new FileSwapSpaceSpi() : new
NoopSwapSpaceSpi());
}

According to the code above, if IgniteConfiguration doesn't contain cache
configurations or all configured caches configured without swap, then node
will be started with NoopSwapSpaceSpi.
As a result in this case, when we start dynamic cache with enabled swap
then actually swap doesn't work.

There is simple workaround - user have to explicitly set FileSwapSpaceSpi
to configuration. But now, there is no any warning or exception.

What we can do:

   1. Throw an exception on dynamic cache start (with swap enabled)
   if NoopSwapSpaceSpi is configured.
   2. Actually, I don't see why we need NoopSwapSpaceSpi at all. I think we
   should configure FileSwapSpaceSpi always if user doesn't provide any
   SwapSpaceSpi explicitly.

Thoughts?

Thanks,
-- Artem --

[jira] [Created] (IGNITE-2620) Extra 'entry expired' events

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-2620:


 Summary: 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: Yakov Zhdanov


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] [Created] (IGNITE-2619) BinaryObjectException: Cannot find schema for object with compact footer

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-2619:


 Summary: BinaryObjectException: Cannot find schema for object with 
compact footer
 Key: IGNITE-2619
 URL: https://issues.apache.org/jira/browse/IGNITE-2619
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Semen Boikov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.6


Added test CacheQueryBuildValueTest:
- first build and put in cache object without indexed field
- then build and put in cache object with indexed field 
- second put fails with error 'BinaryObjectException: Cannot find schema for 
object with compact footer'




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2564: MemoryReallocate handler added.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/460


---
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.
---

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

[VladimirErshov]

GitHub user VladimirErshov opened a pull request:

https://github.com/apache/ignite/pull/470

Ignite-2509 fixed offHeap_values case

Ignite-2509 fixed offHeap_values case

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/VladimirErshov/ignite ignite-2509

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/470.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 #470


commit d49b25ed189d5e8374d7dfa3e0d668841216c9a0
Author: vershov 
Date:   2016-02-03T10:05:57Z

ignite-2509 offHeap Fix. Test added.

commit 3571a0a13a5ceaca0c5172be23f86e97ca97c7f2
Author: vershov 
Date:   2016-02-04T09:06:26Z

IGNITE-2539 test and commented a way to reproduce

commit 3203fc3fe2937f95c657e3033bdfacb87b73
Author: vershov 
Date:   2016-02-04T09:07:04Z

ignite-2509 finalization. sout removed. Commit message edit

commit d411ede27ef1796d030f1cb3cbb764c4bf9db91b
Author: vershov 
Date:   2016-02-04T10:17:52Z

IGNITE-2509 jdk7 cmpt, test added to suit

commit 0493be4636aa6c4fa4584630a7e249b07536e793
Author: vershov 
Date:   2016-02-04T13:19:07Z

ignite-2509 license added. Fix identical cache name in two different tests 
in GridAffinityNoCacheSelfTest

commit a6b2236b02d30af893bb6a47578eb026f3899f2e
Author: vershov 
Date:   2016-02-04T16:22:36Z

IGNITE-2509 correct fix for the test

commit 0420d9a6729687e7dbec22be08a8f81b6b3e28c3
Author: vershov 
Date:   2016-02-10T10:53:56Z

ignite-2509 fixed offheapValues case. JD improved. Cluster metrics test 
added




---
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-2618) SQL page: on second scroll to the same query title of query located under affix

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2618:
-

 Summary: SQL page: on second scroll to the same query title of 
query located under affix
 Key: IGNITE-2618
 URL: https://issues.apache.org/jira/browse/IGNITE-2618
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2617) Add spining wheel for long-time operation

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2617:
--

 Summary: Add spining wheel for long-time operation
 Key: IGNITE-2617
 URL: https://issues.apache.org/jira/browse/IGNITE-2617
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov


For example try to Export All after SCAN of very large table



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2616) NonHeap memory usage metrics don't work as expected.

[Vladimir Ershov (JIRA)]

Vladimir Ershov created IGNITE-2616:
---

 Summary: NonHeap memory usage metrics don't work as expected.
 Key: IGNITE-2616
 URL: https://issues.apache.org/jira/browse/IGNITE-2616
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5.0.final
Reporter: Vladimir Ershov
Priority: Minor


This simple code:
{noformat}
public static void main(String ... args) {
MemoryMXBean mxBean = ManagementFactory.getMemoryMXBean();
System.out.println(mxBean.getNonHeapMemoryUsage());
GridUnsafeMemory uMem = new GridUnsafeMemory(1024L * 1024 * 1024 * 3); 
//3GB
System.out.println(mxBean.getNonHeapMemoryUsage());
uMem.allocate(1024 * 1024 * 1024, true, false);
System.out.println(mxBean.getNonHeapMemoryUsage());
uMem.allocate(1024 * 1024 * 1024, true, true);
System.out.println(mxBean.getNonHeapMemoryUsage());
}
{noformat}
shows: 
{noformat}
init = 2555904(2496K) used = 4783352(4671K) committed = 8060928(7872K) max = 
-1(-1K)
init = 2555904(2496K) used = 5018704(4901K) committed = 8060928(7872K) max = 
-1(-1K)
init = 2555904(2496K) used = 5018960(4901K) committed = 8060928(7872K) max = 
-1(-1K)
init = 2555904(2496K) used = 5018960(4901K) committed = 8060928(7872K) max = 
-1(-1K)
{noformat}
which means: offHeap metrics are incorrect. The  problem is: Apache Ignite uses 
that MemoryMXBean  for collecting metrics, thus Apache Ignite offHeap metrics 
are incorrect too. We should find the way to fix this, if there are any.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2615) SQL query fails for cache with an eviction policy to offheap

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-2615:
-

 Summary: SQL query fails for cache with an eviction policy to 
offheap
 Key: IGNITE-2615
 URL: https://issues.apache.org/jira/browse/IGNITE-2615
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Sergey Kozlov
Priority: Critical


1 Start server node
2. Start client that creates an onheap cache and performs  random 
put/get/sqlquery
3. Client fails at query execution after starting eviciton in offheap:

Client log
{noformat}
>>> ---
>>> Cache configuation used: 1
>>> CacheConfiguration [name=cache_d37d89a5_239_09203172203377125, 
>>> storeConcurrentLoadAllThreshold=5, rebalancePoolSize=
2, rebalanceTimeout=1, evictPlc=FifoEvictionPolicy [max=3, batchSize=1, 
maxMemSize=0, memSize=0], evictSync=fals
e, evictKeyBufSize=1024, evictSyncConcurrencyLvl=4, evictSyncTimeout=1, 
evictFilter=null, evictMaxOverflowRatio=10.0
, eagerTtl=true, dfltLockTimeout=0, startSize=150, nearCfg=null, 
writeSync=PRIMARY_SYNC, storeFactory=null, storeKee
pBinary=false, loadPrevVal=false, aff=null, cacheMode=REPLICATED, 
atomicityMode=ATOMIC, atomicWriteOrderMode=null, backu
ps=0, invalidate=false, tmLookupClsName=null, rebalanceMode=SYNC, 
rebalanceOrder=0, rebalanceBatchSize=524288, rebalance
BatchesPrefetchCount=2, offHeapMaxMem=1000, swapEnabled=false, 
maxConcurrentAsyncOps=500, writeBehindEnabled=false,
writeBehindFlushSize=10240, writeBehindFlushFreq=5000, 
writeBehindFlushThreadCnt=1, writeBehindBatchSize=512, memMode=ON
HEAP_TIERED, affMapper=null, rebalanceDelay=0, rebalanceThrottle=0, 
interceptor=null, longQryWarnTimeout=3000, readFromB
ackup=true, nodeFilter=null, sqlSchema=null, sqlEscapeAll=false, 
sqlOnheapRowCacheSize=10240, snapshotableIdx=false, cpO
nRead=true, topValidator=null]
>>> ---
[13:07:57,506][INFO][exchange-worker-#38%null%][GridCacheProcessor] Started 
cache [name=cache_d37d89a5_239_0920317220337
7125, mode=REPLICATED]
>>> Node for ordered messages: 86d4d306
>>> Node for unordered messages: 86d4d306
>>>Empty cache, loading data by streamer ...
Loaded 3 key(s)
>>> 1309 operation(s), op/sec: 261, cache size: 33840
>>> Latest value is Data [modified=0, longCol=14658, 
>>> doubleCol=0.3403571235222742, stringCol='14658*', boolean=true,
 int=14658, bytesCol='[49, 52, 54, 53, 56, 42, 42, 42, 42, 42]', 
innerDataCol=inner [longCol=7329]', mapCol='{map_key_14
658=map_value_14658}']
>>> Operation counters: 
>>> replace=81,scanquery=86,put=444,remove=77,get=379,putall=36,removeall=44,sqlquery=81,msg=0,contq
uery=0,getall=81
>>> 2596 operation(s), op/sec: 259, cache size: 36128
>>> Latest value is Data [modified=0, longCol=33912, 
>>> doubleCol=0.9348676568832568, stringCol='33912*', boolean=true,
 int=33912, bytesCol='[51, 51, 57, 49, 50, 42, 42, 42, 42, 42]', 
innerDataCol=inner [longCol=16956]', mapCol='{map_key_3
3912=map_value_33912}']
>>> Operation counters: 
>>> replace=157,scanquery=166,put=856,remove=154,get=782,putall=69,removeall=90,sqlquery=170,msg=0,c
ontquery=0,getall=152
>>> 4022 operation(s), op/sec: 268, cache size: 40428
>>> Latest value is Data [modified=0, longCol=31128, 
>>> doubleCol=0.33278377289395045, stringCol='31128*', boolean=true
, int=31128, bytesCol='[51, 49, 49, 50, 56, 42, 42, 42, 42, 42]', 
innerDataCol=inner [longCol=15564]', mapCol='{map_key_
31128=map_value_31128}']
>>> Operation counters: 
>>> replace=238,scanquery=241,put=1314,remove=244,get=1255,putall=109,removeall=133,sqlquery=250,msg
=0,contquery=0,getall=238
[13:08:25,463][INFO][grid-timeout-worker-#23%null%][IgniteKernal]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=d37d89a5, name=null]
^-- H/N/C [hosts=1, nodes=2, CPUs=8]
^-- CPU [cur=0,07%, avg=3,76%, GC=0%]
^-- Heap [used=68MB, free=73,05%, comm=253MB]
^-- Public thread pool [active=0, idle=16, qSize=0]
^-- System thread pool [active=0, idle=16, qSize=0]
^-- Outbound messages queue [size=0]
[13:09:17,128][INFO][sys-#15%null%][GridDeploymentLocalStore] Class locally 
deployed: class org.apache.ignite.IgniteChec
kedException
[13:09:17,133][INFO][sys-#15%null%][GridDeploymentLocalStore] Class locally 
deployed: class org.apache.ignite.IgniteExce
ption
[13:09:17,145][INFO][main][GridTcpRestProtocol] Command protocol successfully 
stopped: TCP binary
[13:09:17,167][INFO][main][GridCacheProcessor] Stopped cache: 
ignite-marshaller-sys-cache
[13:09:17,170][INFO][main][GridCacheProcessor] Stopped cache: ignite-sys-cache
[13:09:17,182][INFO][main][GridCacheProcessor] Stopped cache: 
ignite-atomics-sys-cache
[13:09:17,193][INFO][main][GridCacheProcessor] Stopped cache: 
cache_d37d89a5_239_09203172203377125
[13:09:17,207][INFO][main][GridDeploymentLocalStore]

[jira] [Created] (IGNITE-2614) Do not allow to create notebook with exist name.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2614:
-

 Summary: Do not allow to create notebook with exist name.
 Key: IGNITE-2614
 URL: https://issues.apache.org/jira/browse/IGNITE-2614
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2575 Add limit on minimal value of IGF...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/469


---
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.
---

[GitHub] ignite pull request: IGNITE-2555 fix

[ruskim]

GitHub user ruskim reopened a pull request:

https://github.com/apache/ignite/pull/468

IGNITE-2555 fix

 Added offheap usage (used/free/committed) to local node reports.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ruskim/ignite IGNITE-2555

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/468.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 #468


commit db1417f98133d35e10ae4acd20428b51e2b1
Author: ruskim 
Date:   2016-02-09T18:06:32Z

fix IGNITE-2555

commit 78dfb1815a8ffda8aae8a6471e13a73a9a4cfa78
Author: ruskim 
Date:   2016-02-10T08:55:31Z

added node uptime to ket parameters log




---
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.
---

[GitHub] ignite pull request: IGNITE-2555 fix

[ruskim]

Github user ruskim closed the pull request at:

https://github.com/apache/ignite/pull/468


---
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.
---

[GitHub] ignite pull request: IGNITE-2575 Add limit on minimal value of IGF...

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

https://github.com/apache/ignite/pull/469

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkarachentsev/ignite master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/469.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 #469


commit 946dccb9e98419bf9921b12607667d74ef87ecda
Author: dkarachentsev 
Date:   2016-02-10T08:33:04Z

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration.




---
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-2613) On filtration of cluster list hide editor fields if selected item is filtered

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2613:
-

 Summary: On filtration of cluster list hide editor fields if 
selected item is filtered
 Key: IGNITE-2613
 URL: https://issues.apache.org/jira/browse/IGNITE-2613
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Vasiliy Sisko
Assignee: Dmitriyff






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2612) Refactor Caches screen to Angular directives

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2612:


 Summary: Refactor Caches screen to Angular directives
 Key: IGNITE-2612
 URL: https://issues.apache.org/jira/browse/IGNITE-2612
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)