[jira] [Created] (IGNITE-5445) ServerImpl can't process NodeFailedMessage about itself

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-5445:


 Summary: ServerImpl can't process NodeFailedMessage about itself
 Key: IGNITE-5445
 URL: https://issues.apache.org/jira/browse/IGNITE-5445
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.9
Reporter: Alexander Belyak
Priority: Minor
 Fix For: 2.1


If for some reason (GC pause or heavy load) node get NodeLeft(FAILED) message 
about itself - it can't correctly handle it, because it call 
TcpDiscoveryNodesRing.removeNode with local node id and get assertion error.
I think - node should correctly determine such event and throw something like 
"segmented" event and so on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Configuration issues with IGFS in Ignite 1.9

[Denis Magda]

Vova,

Could you take a look at the issue?

—
Denis

> On Jun 7, 2017, at 1:40 PM, Konstantin Boudnik  wrote:
> 
> Guys,
> 
> after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
> a number of issues introduced by changed script interfaces and
> similar. However, the one which I still can not fix so far is this.
> The secondary file system is configured like this:
> 
>
>  
> parent="igfsCfgBase">
>  
> 
>  
>  
>  
> 
>  
>  
>
>  
>  
>  
>
>  
> 
>  
> class="org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem">
>   value='hdfs://0f6e4ed13002.bigtop.apache.org:8020'/>
>   value='/etc/hadoop/conf/core-site.xml'/>
>  
>
>  
> 
> And we are getting the following error message:
> 
> Caused by: java.lang.IllegalArgumentException: Can not create a Path
> from an empty string
>at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
>at org.apache.hadoop.fs.Path.(Path.java:134)
>at 
> org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopBasicFileSystemFactoryDelegate.start(HadoopBasicFileSystemFactoryDelegate
> .java:165)
>at 
> org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopCachingFileSystemFactoryDelegate.start(HadoopCachingFileSystemFactoryDele
> gate.java:58)
>at 
> org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopIgfsSecondaryFileSystemDelegateImpl.start(HadoopIgfsSecondaryFileSystemDe
> legateImpl.java:375)
>at 
> org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:261)
>at 
> org.apache.ignite.internal.processors.igfs.IgfsImpl.(IgfsImpl.java:186)
>at 
> org.apache.ignite.internal.processors.igfs.IgfsContext.(IgfsContext.java:101)
>at 
> org.apache.ignite.internal.processors.igfs.IgfsProcessor.start(IgfsProcessor.java:130)
>at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1644)
>at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:903)
>... 10 more
> Failed to start grid: Can not create a Path from an empty string
> 
> Removing the value from cfgPath doesn't change anything. I'd
> appreciate if someone can point me to the right direction: current
> config examples aren't helping much either. Thanks!
> --
>  Take care,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622
> 
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.

Re: Suggested changes for Apache Ignite Release procedure

[Denis Magda]

+1

> On Jun 7, 2017, at 3:40 AM, Sergey Kozlov  wrote:
> 
> Hi, Igniters
> 
> I'd start the discussion for following changes of release procedure.
> As you may know we provided not source artifacts only but also a set of
> binaries that makes using of the release is more friendly namely:
> - binary farbic artifact
> - binary hadoop artifact
> - articats in Apache Ignite Maven repository
> - artifacts for .Net/C++ in NuGet
> 
> At the moment we release it by procedure [1] and some actions should be
> processed manually (or some semi-automated way) by the release
> lead  committer.
> 
> I suggest to implement all such tasks on public teamcity as TC
> configurations in a special project and allow to run them by the release
> lead committer.
> 
> Corresponding JIRA issue is [2]
> 
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> [2] https://issues.apache.org/jira/browse/IGNITE-5249
> -- 
> Sergey Kozlov

Re: Key type name and value type name for CREATE TABLE

[Denis Magda]

Vova,


> On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov  wrote:
> 
> Valya,
> 
> It doesn't affect builder invoked from DML engine, as it know how to find
> these names. As per users who want to call IgniteCache.put() on a cache
> created through SQL - sorry, they will have hard times resolving actual
> type name.

If this limitation is to be addressed in the future release then I don’t have 
any concerns. Is it so?

Ideally, regardless how a cache was created and its SQL schema was defined 
(DDL, Spring XML and Java config), the user should be able to works with it 
using all the APIs available w/o limitations.

—
Denis

> This is OK for the first release, provided that we mask type
> names for a reason - to avoid subtle exceptions when working with DDL and
> DML.
> 
> On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> 
>> Vova,
>> 
>> If you add unique suffix losing human-readable type names, how will the
>> builder approach work? Maybe it makes sense to add an API call that returns
>> current type name for a table?
>> 
>> -Val
>> 
>> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan 
>> wrote:
>> 
>>> Vova,
>>> 
>>> I am not sure I like the key type name the way it is. Can we add some
>>> separator between the table name and key name, like "_". To me
>> "PERSON_KEY"
>>> reads a lot better than "PERSONKey".
>>> 
>>> D.
>>> 
>>> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin >> 
>>> wrote:
>>> 
 Unique suffix is a good idea.
 
 Sergi
 
 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
 
> Igniters,
> 
> In the very first implementation of CREATE TABLE we applied the
>>> following
> rule to key and value type names:
> keyTypeName == tableName + "Key"
> valTypeName == tableName
> 
> E.g.:
> CREATE TABLE Person ...
> keyTypeName == PERSONKey
> valTypeName == PERSON
> 
> After that user could potentially create objects with these type
>> names
> manually and add them to cache through native Ignite API:
> 
> BinaryObject key =
>>> IgniteBinary.builder("PERSONKey").addField().build();
> BinaryObject val = IgniteBinary.builder("PERSON")
>> .addField().build();
> IgniteCache.put(key, val);
> 
> This approach has two problems:
> 1) Type names are not unique between different tables. it means that
>> if
 two
> tables with the same name are created in different schemas, we got a
> conflict.
> 2) Type names are bound to binary metadata, so if user decides to do
>>> the
> following, he will receive and error about incompatible metadata:
> CREATE TABLE Person (id INT PRIMARY KEY);
> DROP TABLE Person;
> CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
 still
> has type "Integer".
> 
> In order to avoid that I am going to add unique suffix or so (say,
>>> UUID)
 to
> type names. This way there will be no human-readable type names any
>>> more,
> but there will be no conflicts either. In future releases we will
>> relax
> this somehow.
> 
> Thoughts?
> 
> Vladimir.
> 
 
>>> 
>> 

[jira] [Created] (IGNITE-5444) Collections.singletonList is not properly serialized by binary marshaller

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-5444:
---

 Summary: Collections.singletonList is not properly serialized by 
binary marshaller
 Key: IGNITE-5444
 URL: https://issues.apache.org/jira/browse/IGNITE-5444
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.0
Reporter: Valentin Kulichenko
 Fix For: 2.1
 Attachments: BinaryObjectSingletonList.java

Test attached. {{Collections.singletonList}} is apparently serialized by 
optimized marshaller, because when deserialized, it doesn't return collection 
of binary objects, but rather collection of deserialized objects.

Most likely the reason for this is that {{Collections.singletonList}} is not 
recognized by {{BinaryUtils.knownCollection}} method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: BinaryObjectImpl.deserializeValue with specific ClassLoader

[Valentin Kulichenko]

Hi Nick,

How exactly do you replace the class loader and can you give a little bit
more detail about why you do this?

As for the issues, here are my comments:

   1. Can you clarify this? In which scenario it doesn't work and why?
   2. Why do you deploy domain classes in the first place? Ignite
   architecture assumes that there are no classes on server side at all, so I
   think it would be very hard to load them dynamically. Can you use binary
   objects instead?
   3. I can't recall any such places from the top of my head, but frankly I
   don't think you have such a guarantee. IgniteConfiguration object is
   assumed to be created prior to node startup. It should not be modified
   after startup.

-Val

On Thu, Jun 1, 2017 at 9:46 AM, npordash  wrote:

> I wanted to provide an update on where I am at with this as I'm still
> exploring different options.
>
> For the time being I've taken the path of using a delegating ClassLoader in
> IgniteConfiguration as was previously suggested; however, with the
> difference being that whenever a service is deployed/undeployed I end up
> replacing the ClassLoader with a new instance that has the service's
> ClassLoader added/removed. The replacement is necessary so that unused/old
> classes can be reclaimed by the garbage collector and that new versions can
> be deployed in the future.
>
> Overall I think this is a more comprehensive approach since it also allows
> execution constructs like CacheEntryProcessor implementations provided by
> the service to be used across the grid without enabling p2p classloading
> (assuming the service is deployed to every node).
>
> There are a few concerns/issues with this approach:
>
> 1) There are still isolation concerns with class versions across different
> services, but as long as the services don't have dependencies between each
> other or have overlapping class usage in a cache or execution context then
> it's a non-issue.
> 2) Using OnheapCacheEnabled in conjunction with service provided domain
> classes is impossible since once the service is reloaded and we get a new
> classloader all calls to deserialize will fail.
> 3) This approach only works if nothing caches the result of
> IgniteConfiguration.getClassLoader, which isn't obvious since the docs
> related to classloader behavior in Ignite is pretty sparse (or at least I
> could not find it). I don't think anything does when I check that method
> usage, but I'm not 100% sure about that.
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-
> deserializeValue-with-specific-ClassLoader-tp17126p18358.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

Re: Data compression in Ignite 2.0

[Valentin Kulichenko]

Vyacheslav, Anton,

Are there any ideas and/or prototypes for the API? Your design suggestions
seem to make sense, but I would like to see how it all this will like from
user's standpoint.

-Val

On Wed, Jun 7, 2017 at 1:06 AM, Антон Чураев  wrote:

> Vyacheslav, correct me if something wrong
>
> We could provide opportunity of choose between CPU usage and MEM/NET usage
> for users by compression some attributes of stored objects.
> You have learned design, and it is possible to localize changes in
> marshalling without performance affect and current functionality.
>
> I think, that it's usefull for our project and users.
> Community, what do you think about this proposal?
>
>
> 2017-06-06 17:29 GMT+03:00 Vyacheslav Daradur :
>
> > In short,
> >
> > During marshalling a fields is represented as BinaryFieldAccessor which
> > manages its marshalling. It checks if the field is marked by annotation
> > @BinaryCompression, in that case - binary  representation of field (bytes
> > array) will be compressed. It will be marked as compressed by types
> > constant (GridBinaryMarshaller.COMPRESSED), after this the compressed
> > bytes
> > array wiil be include in binary representation of whole object. Note,
> > header of marshalled object will not be compressed. Compression affected
> > only object's field representation.
> >
> > Objects in IgniteCache is represented as BinaryObject which is wrapper
> over
> > bytes array of marshalled object.
> > BinaryObject provides some usefull methods, which are used by Ignite
> > systems.
> > For example, the Queries use BinaryObject#field method, which
> deserializes
> > only field of object, without deserializing of whole object.
> > BinaryObject#field method during deserialization, if meets the constant
> of
> > compressed type, decompress this bytes array, then continue unmarshalling
> > as usual.
> >
> > Now, I introduced the Compressor interface in IgniteConfigurations, it
> > allows user to use own implementation of compressor - it is the
> requirement
> > in the task[1].
> >
> > As far as I know, Vladimir Ozerov doesn't like the idea of granting this
> > opportunity to the user.
> > In that case we can choose a compression algorithm which we will provide
> by
> > default and will move the interface to internals of binary
> infractructure.
> > For this case I've prepared benchmarked, which I've sent earlier.
> >
> > I vote for ZSTD algorithm[2], it provides good compression ratio and good
> > throughput. It has implementation in Java, .NET and C++, and has
> > ASF-friendly license, we can use it in the all Ignite platforms.
> > You can look at an assessment of this algorithm in my benchmark's
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-3592
> > [2]https://github.com/facebook/zstd
> >
> >
> > 2017-06-06 16:02 GMT+03:00 Антон Чураев :
> >
> > > Looks good for me.
> > >
> > > Could You propose design of implementation in couple of sentences?
> > > So that we can estimate the completeness and complexity of the
> proposal.
> > >
> > > 2017-06-06 15:26 GMT+03:00 Vyacheslav Daradur :
> > >
> > > > Anton,
> > > >
> > > > Of course, the solution does not affect on existing implementation. I
> > > mean,
> > > > there is no changes if user not use the annotation
> @BinaryCompression.
> > > (no
> > > > performance changes)
> > > > Only if user make decision to use compression on specific field or
> > fields
> > > > of a class - in that case compression will be used at marshalling in
> > > > relation to annotated fields.
> > > >
> > > > 2017-06-06 15:10 GMT+03:00 Антон Чураев :
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Is it possible to propose implementation that can be switched on
> > > > on-demand?
> > > > > In this case it should not affect performance of current solution.
> > > > >
> > > > > I mean, that users should make decision what is more important for
> > > them:
> > > > > throutput or memory/net usage.
> > > > > May be they will be choose not all objects, or only some attributes
> > of
> > > > > objects for compress.
> > > > >
> > > > > 2017-06-06 14:48 GMT+03:00 Vyacheslav Daradur  >:
> > > > >
> > > > > > Conclusion:
> > > > > > Provided solution allows reduce size of an object in IgniteCache
> at
> > > the
> > > > > > cost of throughput reduction (small - in some cases), it depends
> on
> > > > part
> > > > > of
> > > > > > object which will be compressed and compression algorithm.
> > > > > > I mean, we can make more effective use of memory, and in some
> cases
> > > it
> > > > > can
> > > > > > reduce loading of the interconnect. (replication, rebalancing)
> > > > > >
> > > > > > Especially, it will be particularly useful for object's fields
> > which
> > > > are
> > > > > > large text (>~ 250 bytes) and can be effectively compressed.
> > > > > >
> > > > > > 2017-06-06 12:00 GMT+03:00 Антон Чураев 

Configuration issues with IGFS in Ignite 1.9

[Konstantin Boudnik]

Guys,

after upgrading the Bigtop stack from Ignite 1.5 to 1.9 we are seeing
a number of issues introduced by changed script interfaces and
similar. However, the one which I still can not fix so far is this.
The secondary file system is configured like this:


  

  

  
  
  

  
  

  
  
  

  

  

  
  
  

  

And we are getting the following error message:

Caused by: java.lang.IllegalArgumentException: Can not create a Path
from an empty string
at org.apache.hadoop.fs.Path.checkPathArg(Path.java:126)
at org.apache.hadoop.fs.Path.(Path.java:134)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopBasicFileSystemFactoryDelegate.start(HadoopBasicFileSystemFactoryDelegate
.java:165)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopCachingFileSystemFactoryDelegate.start(HadoopCachingFileSystemFactoryDele
gate.java:58)
at 
org.apache.ignite.internal.processors.hadoop.impl.delegate.HadoopIgfsSecondaryFileSystemDelegateImpl.start(HadoopIgfsSecondaryFileSystemDe
legateImpl.java:375)
at 
org.apache.ignite.hadoop.fs.IgniteHadoopIgfsSecondaryFileSystem.start(IgniteHadoopIgfsSecondaryFileSystem.java:261)
at 
org.apache.ignite.internal.processors.igfs.IgfsImpl.(IgfsImpl.java:186)
at 
org.apache.ignite.internal.processors.igfs.IgfsContext.(IgfsContext.java:101)
at 
org.apache.ignite.internal.processors.igfs.IgfsProcessor.start(IgfsProcessor.java:130)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1644)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:903)
... 10 more
Failed to start grid: Can not create a Path from an empty string

Removing the value from cfgPath doesn't change anything. I'd
appreciate if someone can point me to the right direction: current
config examples aren't helping much either. Thanks!
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

[jira] [Created] (IGNITE-5443) The bunch of javadoc warnings

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-5443:
-

 Summary: The bunch of javadoc warnings
 Key: IGNITE-5443
 URL: https://issues.apache.org/jira/browse/IGNITE-5443
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.1
Reporter: Sergey Kozlov


{noformat}
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2226:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2226:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2253:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2253:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2658:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2658:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2685:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2685:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2172:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2172:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2199:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2199:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 
/home/teamcity/buildAgent/work/a239320d84866d7f/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:2604:
 warning - @inheritDoc used but getCacheId(long, int) does not override or 
implement any method.
[11:38:06]W: [org.apache.ignite:ignite-core] [WARNING] 

Re: "Review workflow" changes to prevent "broken review" issues.

[Антон Чураев]

Igniters, Dmitry, basically agree

It's no secret that Ignite is a very complex project, and contributors need
a very high experience to become a committer.
But this is a potential problem for scaling the community and project
development.

I think that one of the options for solving the growth problem could be to
decompose issues for new contributors. This will allow them to be included
in the project more quickly, and it will be more convenient for the
committers to code review.

There are cons, but what do you think?

2017-06-05 19:58 GMT+03:00 Dmitry Pavlov :

> Hi Igniters, Anton,
>
> Let’s imagine that development process as a chain of production stages
> 1) Developing patch by contributor
> 2) Review changes by committer
>
> Reviews waiting too long time to be done at stage 2 may indicate that speed
> (potential throughput) of step 2 is less than throughput at step 1. T2
> In terms of this model (inspired by Goldratt’s Theory of Constraints
> (TOC)), I have a question:
> Will this responsibility movement (to find appropriate reviewer to
> contributor) help us to increase overall throughput?
>
> If we agree constraint in terms of TOC is throughput T2, I suggest
> following steps
> - Increase the throughput T2 of the committers
> - Reduce the load on the committers by improve quality of code after stage
> 1 given to review (pre review by non-committer, automatic review, code
> inspections)
>
> Best Regards,
> Dmitriy Pavlov
>
>
> пн, 5 июн. 2017 г. в 18:28, Anton Vinogradov :
>
> > Igniters,
> >
> > Currently, according to
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-SubmittingforReview
> > ,
> > contributor can ask for review by moving ticket to PATCH AVAILABLE state.
> >
> > And, as far as I can see, this cause broken tickets issue.
> > Contributor can wait somebody who'll review his changes for a month or
> even
> > more.
> >
> > I propose to change workflow and *make contributor responsible to find
> > reviewer*.
> > It's pretty easy to find a person able to review changes in most of
> cases.
> >
> > 1) You can check git history of files you modified and find persons with
> > expertise in this code
> > 2) In case you have problems with such search you can always use
> > maintainers list (
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-ReviewProcessandMaintainers
> > )
> >
> > Thoughts?
> >
>



-- 

Best Regards, Anton Churaev

Re: New version of Web Console released

[Muthu]

Thanks Alexey! for the pointers. For the ORM alternate case the use case is
the below (basically today we are thinking of using Ignite with MyBatis
with Ignite being the L2 cache (among other things) & MyBatis being the
persistence framework, the question is can Ignite do the cache with the Web
console's RDBMS Integration or Model support being used to play the role of
the persistence framework so it will be an all Ignite thingy),

1. A way to write DTOs to ignite cache which will then automatically (async
aswell) persist to DB (model/DTO generation, db persistence, etc)
  -- This includes insert, update & delete and batch/bulk operations

2. A way to read from ignite cache which will automatically read from DB if
not in cache
  -- This includes read based on any predicate (where clause), custom
select sql queries, bulk operations

Regards,
Muthu

On Wed, Jun 7, 2017 at 12:19 AM, Alexey Kuznetsov 
wrote:

> Muthu,
>
> >> Is the web console not part of or deploy-able from the ignite fabric
> distrib
> Yes. It is not part of binary distribution.
> You can build it from sources or use Docker image (see:
> https://hub.docker.com/r/apacheignite/web-console-standalone/tags/)
>
> >> .but i do not find any directory named "modules" under my IGNITE_HOME
> You need to download SOURCE release.
>
>
> >>> Can i download only a trial version from console.gridgain.com ?
> No. console.gridgain.com contains Web Console that based on Apache Ignite
> code base, but with additional features developed by GridGain.
> Please contact GridGain for that.
>
> >> Will i able to use this as an alternative to say an ORM like MyBatis?
> It depends in what you need. Please describe your use case.
>
>
>
> --
> Alexey Kuznetsov
>

Re: New version of Web Console released

[Muthu]

Sure i will do that..thanks!

Regards,
Muthu

On Wed, Jun 7, 2017 at 5:06 AM, Alexey Kuznetsov 
wrote:

> Muthu,
>
> It is better to start separate thread on user list about your use case.
>
> On Wed, Jun 7, 2017 at 4:22 PM, Muthu  wrote:
>
>>
>> Thanks Alexey! for the pointers. For the ORM alternate case the use case
>> is the below (basically today we are thinking of using Ignite with MyBatis
>> with Ignite being the L2 cache (among other things) & MyBatis being the
>> persistence framework, the question is can Ignite do the cache with the Web
>> console's RDBMS Integration or Model support being used to play the role
>> of the persistence framework so it will be an all Ignite thingy),
>>
>> 1. A way to write DTOs to ignite cache which will then automatically
>> (async aswell) persist to DB (model/DTO generation, db persistence, etc)
>>   -- This includes insert, update & delete and batch/bulk operations
>>
>> 2. A way to read from ignite cache which will automatically read from DB
>> if not in cache
>>   -- This includes read based on any predicate (where clause), custom
>> select sql queries, bulk operations
>>
>> Regards,
>> Muthu
>>
>> On Wed, Jun 7, 2017 at 12:19 AM, Alexey Kuznetsov 
>> wrote:
>>
>>> Muthu,
>>>
>>> >> Is the web console not part of or deploy-able from the ignite fabric
>>> distrib
>>> Yes. It is not part of binary distribution.
>>> You can build it from sources or use Docker image (see:
>>> https://hub.docker.com/r/apacheignite/web-console-standalone/tags/)
>>>
>>> >> .but i do not find any directory named "modules" under my IGNITE_HOME
>>> You need to download SOURCE release.
>>>
>>>
>>> >>> Can i download only a trial version from console.gridgain.com ?
>>> No. console.gridgain.com contains Web Console that based on Apache
>>> Ignite code base, but with additional features developed by GridGain.
>>> Please contact GridGain for that.
>>>
>>> >> Will i able to use this as an alternative to say an ORM like MyBatis?
>>> It depends in what you need. Please describe your use case.
>>>
>>>
>>>
>>> --
>>> Alexey Kuznetsov
>>>
>>
>>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[jira] [Created] (IGNITE-5442) Linq Conditional statement will fail for some types

[Sergey Stronchinskiy (JIRA)]

Sergey Stronchinskiy created IGNITE-5442:


 Summary: Linq Conditional statement will fail for some types
 Key: IGNITE-5442
 URL: https://issues.apache.org/jira/browse/IGNITE-5442
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Reporter: Sergey Stronchinskiy
Priority: Minor


Next code will fail:

{code}
var res = persons.Select(x => new {Foo = x.Key%2 == 0 ? 1 : (int?)null, 
x.Value}).ToArray();
{code}

Fix: strip nullable type in {{SqlTypes}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2106: IGNITE-4370: Implemented writing of batch of para...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-4370: Implemented writing of batch of parameters for ODBC.



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4370

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

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


commit 19499050347d18fc2625d1efb881436c42d3916d
Author: Igor Sapego 
Date:   2017-06-05T15:09:50Z

IGNITE-4370: Added SQL_PARAM_ARRAY_ROW_COUNTS param

commit bdc68cca6a939e800323382f69f765ba84d97a8a
Author: Igor Sapego 
Date:   2017-06-05T15:55:20Z

IGNITE-4370: Added SQL_PARAM_ARRAY_SELECTS param

commit ee040b4d9b04233c91853ac4bef2d60b86e828c5
Author: Igor Sapego 
Date:   2017-06-06T16:15:37Z

IGNITE-4370: Parameter refactored

commit cc60a056331d5a9162e710d41f208c86a4b5d27c
Author: Igor Sapego 
Date:   2017-06-06T16:32:43Z

IGNITE-4370: Fix

commit 51a01e2b772c316e2c5e3999014c146cddcde87c
Author: Igor Sapego 
Date:   2017-06-07T08:44:03Z

IGNITE-4370: Offset-related refactoring.

commit 13d217776f26ab2be9a572d46b432175c8ec613e
Author: Igor Sapego 
Date:   2017-06-07T08:53:42Z

IGNITE-4370: Implemented writing of batch of parameters.

commit c1b8b61b8087be5d6dffe2cf4df7be26ecad125f
Author: Igor Sapego 
Date:   2017-06-07T10:01:47Z

IGNITE-4370 refactored Parameter set writing

commit 745619b847d7a5776565042e92eacf0e93df10ab
Author: Igor Sapego 
Date:   2017-06-07T12:46:32Z

IGNITE-4370: OdbcQueryExecuteBatchStartRequest implemented.

commit 3a7dd6044c86bd10c2dcd45907d4dd4b2a6e33b2
Author: Igor Sapego 
Date:   2017-06-07T14:39:13Z

IGNITE-4370: Safe

commit c63120b892e64a6a19ed78d80d099f21a2f97ffa
Author: Igor Sapego 
Date:   2017-06-07T18:36:40Z

IGNITE-4370: Implemented continuation.




---
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 #2105: Ignite 5432

[a1vanov]

GitHub user a1vanov opened a pull request:

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

Ignite 5432

Fix for test IgniteMarshallerCacheClassNameConflictTest

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

$ git pull https://github.com/a1vanov/ignite ignite-5432

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

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


commit 58fbc2fe67bb675c8aa5c35d16b7461b1bbfdeab
Author: a1vanov 
Date:   2017-04-18T08:23:31Z

Merge pull request #1 from apache/master

update from origine

commit 6db0ffd36e90c140207deb0f1a8327d66b6de405
Author: a1vanov 
Date:   2017-04-18T16:35:03Z

IGNITE-3935 - Unit test - not reproduced

commit d4224cda388ea40601edbcf45fc56291c03108ef
Author: a1vanov 
Date:   2017-05-29T13:02:17Z

Merge pull request #2 from a1vanov/ignite-3935

IGNITE-3935 - Unit test - not reproduced

commit 5941b32ca5cbc1e2951c316cfc5f334255ca6076
Author: a1vanov 
Date:   2017-05-29T13:02:56Z

Merge pull request #3 from apache/master

Fork update

commit fa2ae974d5b49d6ed18a6721f07e5ace7f514864
Author: a1vanov 
Date:   2017-06-07T14:48:40Z

Merge pull request #4 from apache/master

Update

commit f21b2c8586239fd5a47a1db960ff090530550071
Author: a1vanov 
Date:   2017-06-07T15:21:05Z

IGNITE-5432 - fix for test IgniteMarshallerCacheClassNameConflictTest

commit 7a00b78dfaef7db6feb45f96276aee21c42601e3
Author: a1vanov 
Date:   2017-06-07T15:21:51Z

IGNITE-5432 - fix for test IgniteMarshallerCacheClassNameConflictTest




---
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-5441) .NET: Stack trace is lost for exceptions in ICacheStore

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5441:
--

 Summary: .NET: Stack trace is lost for exceptions in ICacheStore
 Key: IGNITE-5441
 URL: https://issues.apache.org/jira/browse/IGNITE-5441
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


When exception happens during cache store invocation ({{Write}} method in 
particular), Java stack trace is lost, original .NET stack trace is lost, 
exception is quite useless. See {{CheckCustomStoreError}} in {{TestLoadCache}}, 
this test should be improved to make sure we preserve all information.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #2104: IGNITE-5170 .NET: Compute peer deployment example

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-5170 .NET: Compute peer deployment example



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5170

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

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


commit ec70aecd30d2ccfcc715b02170ae42f9815c7dd3
Author: Pavel Tupitsyn 
Date:   2017-06-07T13:03:44Z

IGNITE-5170 .NET: Compute peer deployment example - LINQPad

commit e82bbff180d9583beaa71bceb0af3effde2eea0a
Author: Pavel Tupitsyn 
Date:   2017-06-07T13:31:18Z

wip

commit fd7fb38cff047bf9e44e717f5a1817a274158ea0
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:03:00Z

Remove AssemblyFileVersion

commit ce2b29122102b06c7219041dc8693ab53c445eae
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:09:03Z

Make examples 1.0.*

commit 3cd25dc77d4673fc1cd4452f22f3386e1d2f92f9
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:21:16Z

wip

commit eb9db9905711ed0e63ae3905136a6c12f314524b
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:43:04Z

wip

commit db4ce7be8727e053d32f8fffcb8df75ab46bd519
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:44:43Z

wip

commit a09e126b034013f89552f550e220ec059bcf5a47
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:50:04Z

wip

commit 548d607d1292f0c829ce6b3be4df6dd73a8e4302
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:54:10Z

wip

commit e6296d50dea5a5bdaadeefcfb2ab71d8a0098d02
Author: Pavel Tupitsyn 
Date:   2017-06-07T14:57:23Z

Update test

commit 0785ad1407e391fcdaf358c8af5acf4f84e956ea
Author: Pavel Tupitsyn 
Date:   2017-06-07T15:03:38Z

wip

commit da6eabcf138d305a63b4b395f16e07f714114628
Author: Pavel Tupitsyn 
Date:   2017-06-07T15:09:30Z

update docs

commit 94944aa1ad630a1fac02b3181823c9c56f4b62f9
Author: Pavel Tupitsyn 
Date:   2017-06-07T15:12:43Z

cleanup




---
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-5440) JDBC thin: support SQL esacpe processing

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5440:


 Summary: JDBC thin: support SQL esacpe processing
 Key: IGNITE-5440
 URL: https://issues.apache.org/jira/browse/IGNITE-5440
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
 Fix For: 2.2


The method {{Statement.setEscapeProcessing}} must be supported.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Optimize transaction prepare step when store is enabled IGNITE-1553

[ALEKSEY KUZNETSOV]

Hi, Igntrs!
Feel free to reviewing the ticket
https://issues.apache.org/jira/browse/IGNITE-1553
https://github.com/apache/ignite/pull/2091
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Suggested changes for Apache Ignite Release procedure

[Anton Vinogradov]

Huge +1

On Wed, Jun 7, 2017 at 1:40 PM, Sergey Kozlov  wrote:

> Hi, Igniters
>
> I'd start the discussion for following changes of release procedure.
> As you may know we provided not source artifacts only but also a set of
> binaries that makes using of the release is more friendly namely:
>  - binary farbic artifact
>  - binary hadoop artifact
>  - articats in Apache Ignite Maven repository
>  - artifacts for .Net/C++ in NuGet
>
> At the moment we release it by procedure [1] and some actions should be
> processed manually (or some semi-automated way) by the release
> lead  committer.
>
> I suggest to implement all such tasks on public teamcity as TC
> configurations in a special project and allow to run them by the release
> lead committer.
>
> Corresponding JIRA issue is [2]
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> [2] https://issues.apache.org/jira/browse/IGNITE-5249
> --
> Sergey Kozlov
>

[jira] [Created] (IGNITE-5439) JDBC thin: support query cancel

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5439:


 Summary: JDBC thin: support query cancel
 Key: IGNITE-5439
 URL: https://issues.apache.org/jira/browse/IGNITE-5439
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
 Fix For: 2.2


The JDBC {{Statement.cancel}} method must be supported.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5438) DBC thin: support query timeout

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5438:


 Summary: DBC thin: support query timeout
 Key: IGNITE-5438
 URL: https://issues.apache.org/jira/browse/IGNITE-5438
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
 Fix For: 2.2


The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: IGNITE-5432

[Alexey Goncharuk]

Hi Alexey,

I've added you to the contributors' list. Please assign the issue to
yourself.

--AG

2017-06-07 14:47 GMT+03:00 Alexey Ivanov :

> Hi, everybody
>
> I'd like fix this issue:
>
> https://issues.apache.org/jira/browse/IGNITE-5432
>
> Alexey Ivanov (a1vanov)
>
>

[jira] [Created] (IGNITE-5437) SQL: Incorrect partition is derived from query when argument type differs from column type

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-5437:
--

 Summary: SQL: Incorrect partition is derived from query when 
argument type differs from column type
 Key: IGNITE-5437
 URL: https://issues.apache.org/jira/browse/IGNITE-5437
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Sergey Kalashnikov
 Fix For: 2.1


Ignite SQL attempts to derive partition from the query in certain cases and 
sends the map queries only to nodes which have those calculated partitions.
Such queries are limited to contain equality conditions over key or affinity 
key columns at the left and constant or parameter at the right.
When the type of argument does not match the column type, the calculation leads 
to wrong result.

For example, the following query produces incomplete results when _key column 
is INTEGER and the argument is CHAR. 

select * from test where _key = ?

However, this is valid and resultive query for H2, which does implicit 
conversion in such cases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1852: ignite-5030

[daradurvs]

Github user daradurvs closed the pull request at:

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


---
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 #1852: ignite-5030

[daradurvs]

GitHub user daradurvs reopened a pull request:

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

ignite-5030



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

$ git pull https://github.com/daradurvs/ignite ignite-5030

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

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






---
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 #1651: ignite-4211

[daradurvs]

Github user daradurvs closed the pull request at:

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


---
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 #1852: ignite-5030

[daradurvs]

Github user daradurvs closed the pull request at:

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


---
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 #1852: ignite-5030

[daradurvs]

GitHub user daradurvs reopened a pull request:

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

ignite-5030



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

$ git pull https://github.com/daradurvs/ignite ignite-5030

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

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


commit 958749be996e531a05fa5afd284aadd9e9838359
Author: Vyacheslav Daradur 
Date:   2017-04-21T10:28:56Z

ignite-5030: the method was implemented




---
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-5436) .NET: CacheConfiguration.GroupName

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5436:
--

 Summary: .NET: CacheConfiguration.GroupName
 Key: IGNITE-5436
 URL: https://issues.apache.org/jira/browse/IGNITE-5436
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.1


Propagate {{CacheConfiguration.GroupName}} configuration property.

Caches within the same group underneath use single physical Ignite cache.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5435) JDBC thin: support statement close on completion

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5435:


 Summary: JDBC thin: support statement close on completion
 Key: IGNITE-5435
 URL: https://issues.apache.org/jira/browse/IGNITE-5435
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
 Fix For: 2.2


The methods of JDBC {Statement} must be supported:
- {{closeOnCompletion(boolean)}};
- {{isCloseOnCompletion}};



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: New version of Web Console released

[Alexey Kuznetsov]

Muthu,

It is better to start separate thread on user list about your use case.

On Wed, Jun 7, 2017 at 4:22 PM, Muthu  wrote:

>
> Thanks Alexey! for the pointers. For the ORM alternate case the use case
> is the below (basically today we are thinking of using Ignite with MyBatis
> with Ignite being the L2 cache (among other things) & MyBatis being the
> persistence framework, the question is can Ignite do the cache with the Web
> console's RDBMS Integration or Model support being used to play the role
> of the persistence framework so it will be an all Ignite thingy),
>
> 1. A way to write DTOs to ignite cache which will then automatically
> (async aswell) persist to DB (model/DTO generation, db persistence, etc)
>   -- This includes insert, update & delete and batch/bulk operations
>
> 2. A way to read from ignite cache which will automatically read from DB
> if not in cache
>   -- This includes read based on any predicate (where clause), custom
> select sql queries, bulk operations
>
> Regards,
> Muthu
>
> On Wed, Jun 7, 2017 at 12:19 AM, Alexey Kuznetsov 
> wrote:
>
>> Muthu,
>>
>> >> Is the web console not part of or deploy-able from the ignite fabric
>> distrib
>> Yes. It is not part of binary distribution.
>> You can build it from sources or use Docker image (see:
>> https://hub.docker.com/r/apacheignite/web-console-standalone/tags/)
>>
>> >> .but i do not find any directory named "modules" under my IGNITE_HOME
>> You need to download SOURCE release.
>>
>>
>> >>> Can i download only a trial version from console.gridgain.com ?
>> No. console.gridgain.com contains Web Console that based on Apache
>> Ignite code base, but with additional features developed by GridGain.
>> Please contact GridGain for that.
>>
>> >> Will i able to use this as an alternative to say an ORM like MyBatis?
>> It depends in what you need. Please describe your use case.
>>
>>
>>
>> --
>> Alexey Kuznetsov
>>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

IGNITE-5432

[Alexey Ivanov]

Hi, everybody

I'd like fix this issue:

https://issues.apache.org/jira/browse/IGNITE-5432

Alexey Ivanov (a1vanov)

Re: IGNITE-5229 is ready for review

[Anton Vinogradov]

Roman,

Today I added some tips how to request review in most efficient way.
See thread '*"Review workflow" changes to prevent "broken review" issues*'
for details.

I'd like to ask you to help me to check my theory that these tips works.

Could you please ask review using tips from
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview
?

Please let me know will tips help you or not.

On Wed, Jun 7, 2017 at 8:49 AM, Roman Shtykh 
wrote:

> Igniters,
> IGNITE-5229 is ready for review.Now Redis can have its default cache
> specified and used as a template when switching to other caches, as
> discussed earlier in this ml (please see the JIRA issue).
>
> [1] https://issues.apache.org/jira/browse/IGNITE-5229
> -- Roman
>

[GitHub] ignite pull request #2103: IGNITE-5431 Better handling of cache SQL flag inc...

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5431 Better handling of cache SQL flag incompatibility.



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5431

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

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


commit c334090835e204ec4f3fa7c3931a34cc93aa20a3
Author: Alexander Paschenko 
Date:   2017-06-07T11:31:26Z

IGNITE-5431 Better handling of cache SQL flag incompatibility.




---
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 #2102: IGNITE-5196 Ignite JDBC Driver fix

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-5196 Ignite JDBC Driver fix



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

$ git pull https://github.com/gridgain/apache-ignite jdbc-fix

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

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


commit 8ddd4713fb12d23adf87e4b78ca5b808b6688ffe
Author: Igor Seliverstov 
Date:   2017-06-07T11:24:24Z

Ignite JDBC Driver fix




---
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-5434) Yardstick sql benchmarks broken on Ignite-5267 branch

[Aleksey Chetaev (JIRA)]

Aleksey Chetaev created IGNITE-5434:
---

 Summary: Yardstick sql benchmarks broken on Ignite-5267 branch
 Key: IGNITE-5434
 URL: https://issues.apache.org/jira/browse/IGNITE-5434
 Project: Ignite
  Issue Type: Bug
  Components: sql, yardstick
Affects Versions: 2.1
Reporter: Aleksey Chetaev
Priority: Critical


Yardstick benchmarks:
*sql-query
*sql-query-join
*sql-query-put 
broken in  Ignite-5267 branch, in master all ok. 

Exception:
<00:39:22> Starting warmup.



 
Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017]   



 
ERROR: Shutting down benchmark driver to unexpected exception.  



 
Type '--help' for usage.



 
javax.cache.CacheException: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse 
query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM 
"query"."Person" WHERE salary >= ? and salary <= ?  
   
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)


 
at 
org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90)


   
at 
org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64)


   
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) 



  
at java.lang.Thread.run(Thread.java:745)



 
Caused by: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse 
query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM 
"query"."Person" WHERE salary >= ? and salary <= ?  


at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1291)


 
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1196)

[GitHub] ignite pull request #2101: IGNITE-5430

[devozerov]

Github user devozerov closed the pull request at:

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


---
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: "Review workflow" changes to prevent "broken review" issues.

[Anton Vinogradov]

Page updated.

On Wed, Jun 7, 2017 at 1:33 PM, Anton Vinogradov 
wrote:

> Dmitriy,
>
> Got it,
> I'll add this as an optional "Tips to pass review quickly".
>
> On Tue, Jun 6, 2017 at 7:11 PM, Dmitriy Setrakyan 
> wrote:
>
>> On Tue, Jun 6, 2017 at 7:40 AM, Anton Vinogradov <
>> avinogra...@gridgain.com>
>> wrote:
>>
>> > Igniters,
>> >
>> > Since we found that proposed approach can help,
>> > no one mind that I'll add text listed above to the wiki?
>> >
>>
>> I don't think that we have an agreement yet. Again, I still don't think it
>> is fair for a contributor to find a committer that has a relevant area of
>> expertise. A contributor should feel free to ask any committer for a
>> review, but it should not be mandatory. I would rather have an existing
>> contributor or committer help with finding a reviewer.
>>
>>
>> >
>> > On Tue, Jun 6, 2017 at 1:19 PM, Anton Vinogradov <
>> avinogra...@gridgain.com
>> > >
>> > wrote:
>> >
>> > > Dmitry,
>> > >
>> > > 1) See my initial email, it contains instruction how to find a
>> reviewer.
>> > > And it's pretty easy to do when you have something to review (you did
>> > some
>> > > code changes).
>> > >
>> > > I want to add following to our wiki:
>> > >
>> > > "
>> > > Ask commiter to review changes.
>> > > Check affected file's git history to find commiter most likely able to
>> > > review changes.
>> > > In case it's hard to determine who's able to review by git history use
>> > > maintainers list presented above.
>> > > Add "review request" comment to the ticket starting with a commiter
>> > > username.
>> > >
>> > > for example: "[~avinogradov], Please review my changes."
>> > >
>> > > Commiter will gain notification and review your changes and/or find
>> > > another commiter to do this.
>> > >
>> > > Important: Each comment should be started with [~username].
>> > > "
>> > >
>> > > 2) It will be a huge help to the community!
>> > >
>> > > On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlov 
>> > > wrote:
>> > >
>> > >> Anton,
>> > >>
>> > >>
>> > >> Thank you for explanation. Personal ask instead of group broadcast
>> may
>> > >> really help. I understand the idea now.
>> > >>
>> > >>
>> > >> One argument against solution way 1) it may be not easy for
>> contributor,
>> > >> especially newcomer, to find a right person.
>> > >>
>> > >>
>> > >> What do you think about way 2? Personally, I'm ready to help with
>> > analysis
>> > >> and assignment of these 66 tasks from next week.
>> > >>
>> > >>
>> > >>
>> > >> вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov <
>> avinogra...@gridgain.com
>> > >:
>> > >>
>> > >> > Dmitry Pavlov,
>> > >> >
>> > >> > There is *HUGE *difference between "Devlist, please review my
>> changes"
>> > >> > and "Dmitry Pavlov, please review my changes".
>> > >> >
>> > >> > In case you're busy right now, you'll, most likely, ignore appeal
>> to
>> > >> > devlist, but, I'm pretty sure, you'll check appeal to yourself.
>> > >> > Am I right?
>> > >> >
>> > >> > So, my idea is: appeal to devlist is a useless spam maker approach,
>> > but
>> > >> > appeal to person(s) works.
>> > >> >
>> > >> > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan <
>> > >> dsetrak...@apache.org>
>> > >> > wrote:
>> > >> >
>> > >> > > Wow, we have 66 tickets waiting for review this is pretty
>> bad.
>> > >> > > Something must definitely change.
>> > >> > >
>> > >> > > From my side, having a contributor shop around for a reviewer is
>> not
>> > >> > really
>> > >> > > fair. However, I would support the idea of Apache Ignite
>> community
>> > >> > electing
>> > >> > > a person responsible to find reviewers for all contributions.
>> > >> > >
>> > >> > > D.
>> > >> > >
>> > >> > > On Mon, Jun 5, 2017 at 11:23 AM, Dmitry Pavlov <
>> > dpavlov@gmail.com
>> > >> >
>> > >> > > wrote:
>> > >> > >
>> > >> > > > 1) There is waiting for review list here
>> > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/
>> > >> > > > Issues+waiting+for+review
>> > >> > > >
>> > >> > > > 2) some of contributions are supplemented by dev-list messages
>> > >> (please
>> > >> > > > review my PR…)
>> > >> > > >
>> > >> > > >
>> > >> > > > And these two tools sometimes do not help. I suppose it is
>> because
>> > >> of
>> > >> > > > reviewers already have some things to do, but not because of
>> lack
>> > of
>> > >> > tool
>> > >> > > > support. Do you have other explanations?
>> > >> > > >
>> > >> > > >
>> > >> > > > But still, Igor’s suggestion to notify to dev list sounds
>> > >> reasonable to
>> > >> > > me.
>> > >> > > >
>> > >> > > >
>> > >> > > >
>> > >> > > > Anton, could it solve your requirement to know about issue
>> needed
>> > to
>> > >> > > > review?
>> > >> > > >
>> > >> > > > пн, 5 июн. 2017 г. в 21:06, Igor Sapego > >:
>> > >> > > >
>> > >> > > > > By the way, there are emails being sent from Jira to devlist
>> > every
>> > >> > > > > time someone adds comment to ticket, or, 

Suggested changes for Apache Ignite Release procedure

[Sergey Kozlov]

Hi, Igniters

I'd start the discussion for following changes of release procedure.
As you may know we provided not source artifacts only but also a set of
binaries that makes using of the release is more friendly namely:
 - binary farbic artifact
 - binary hadoop artifact
 - articats in Apache Ignite Maven repository
 - artifacts for .Net/C++ in NuGet

At the moment we release it by procedure [1] and some actions should be
processed manually (or some semi-automated way) by the release
lead  committer.

I suggest to implement all such tasks on public teamcity as TC
configurations in a special project and allow to run them by the release
lead committer.

Corresponding JIRA issue is [2]

[1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
[2] https://issues.apache.org/jira/browse/IGNITE-5249
-- 
Sergey Kozlov

Re: "Review workflow" changes to prevent "broken review" issues.

[Anton Vinogradov]

Dmitriy,

Got it,
I'll add this as an optional "Tips to pass review quickly".

On Tue, Jun 6, 2017 at 7:11 PM, Dmitriy Setrakyan 
wrote:

> On Tue, Jun 6, 2017 at 7:40 AM, Anton Vinogradov  >
> wrote:
>
> > Igniters,
> >
> > Since we found that proposed approach can help,
> > no one mind that I'll add text listed above to the wiki?
> >
>
> I don't think that we have an agreement yet. Again, I still don't think it
> is fair for a contributor to find a committer that has a relevant area of
> expertise. A contributor should feel free to ask any committer for a
> review, but it should not be mandatory. I would rather have an existing
> contributor or committer help with finding a reviewer.
>
>
> >
> > On Tue, Jun 6, 2017 at 1:19 PM, Anton Vinogradov <
> avinogra...@gridgain.com
> > >
> > wrote:
> >
> > > Dmitry,
> > >
> > > 1) See my initial email, it contains instruction how to find a
> reviewer.
> > > And it's pretty easy to do when you have something to review (you did
> > some
> > > code changes).
> > >
> > > I want to add following to our wiki:
> > >
> > > "
> > > Ask commiter to review changes.
> > > Check affected file's git history to find commiter most likely able to
> > > review changes.
> > > In case it's hard to determine who's able to review by git history use
> > > maintainers list presented above.
> > > Add "review request" comment to the ticket starting with a commiter
> > > username.
> > >
> > > for example: "[~avinogradov], Please review my changes."
> > >
> > > Commiter will gain notification and review your changes and/or find
> > > another commiter to do this.
> > >
> > > Important: Each comment should be started with [~username].
> > > "
> > >
> > > 2) It will be a huge help to the community!
> > >
> > > On Tue, Jun 6, 2017 at 1:12 PM, Dmitry Pavlov 
> > > wrote:
> > >
> > >> Anton,
> > >>
> > >>
> > >> Thank you for explanation. Personal ask instead of group broadcast may
> > >> really help. I understand the idea now.
> > >>
> > >>
> > >> One argument against solution way 1) it may be not easy for
> contributor,
> > >> especially newcomer, to find a right person.
> > >>
> > >>
> > >> What do you think about way 2? Personally, I'm ready to help with
> > analysis
> > >> and assignment of these 66 tasks from next week.
> > >>
> > >>
> > >>
> > >> вт, 6 июн. 2017 г. в 12:57, Anton Vinogradov <
> avinogra...@gridgain.com
> > >:
> > >>
> > >> > Dmitry Pavlov,
> > >> >
> > >> > There is *HUGE *difference between "Devlist, please review my
> changes"
> > >> > and "Dmitry Pavlov, please review my changes".
> > >> >
> > >> > In case you're busy right now, you'll, most likely, ignore appeal to
> > >> > devlist, but, I'm pretty sure, you'll check appeal to yourself.
> > >> > Am I right?
> > >> >
> > >> > So, my idea is: appeal to devlist is a useless spam maker approach,
> > but
> > >> > appeal to person(s) works.
> > >> >
> > >> > On Tue, Jun 6, 2017 at 2:40 AM, Dmitriy Setrakyan <
> > >> dsetrak...@apache.org>
> > >> > wrote:
> > >> >
> > >> > > Wow, we have 66 tickets waiting for review this is pretty bad.
> > >> > > Something must definitely change.
> > >> > >
> > >> > > From my side, having a contributor shop around for a reviewer is
> not
> > >> > really
> > >> > > fair. However, I would support the idea of Apache Ignite community
> > >> > electing
> > >> > > a person responsible to find reviewers for all contributions.
> > >> > >
> > >> > > D.
> > >> > >
> > >> > > On Mon, Jun 5, 2017 at 11:23 AM, Dmitry Pavlov <
> > dpavlov@gmail.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > 1) There is waiting for review list here
> > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/
> > >> > > > Issues+waiting+for+review
> > >> > > >
> > >> > > > 2) some of contributions are supplemented by dev-list messages
> > >> (please
> > >> > > > review my PR…)
> > >> > > >
> > >> > > >
> > >> > > > And these two tools sometimes do not help. I suppose it is
> because
> > >> of
> > >> > > > reviewers already have some things to do, but not because of
> lack
> > of
> > >> > tool
> > >> > > > support. Do you have other explanations?
> > >> > > >
> > >> > > >
> > >> > > > But still, Igor’s suggestion to notify to dev list sounds
> > >> reasonable to
> > >> > > me.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > Anton, could it solve your requirement to know about issue
> needed
> > to
> > >> > > > review?
> > >> > > >
> > >> > > > пн, 5 июн. 2017 г. в 21:06, Igor Sapego :
> > >> > > >
> > >> > > > > By the way, there are emails being sent from Jira to devlist
> > every
> > >> > > > > time someone adds comment to ticket, or, for example, edits
> its
> > >> > > > > title which helps a lot to keep a track of ticket's state.
> > >> > > > >
> > >> > > > > But by some reason there is no such notification when ticket
> > >> silently
> > >> > > > > getting moved to "Patch available" state. I believe, 

[jira] [Created] (IGNITE-5433) Incorrect warning when "default" memory policy is used

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-5433:
---

 Summary: Incorrect warning when "default" memory policy is used
 Key: IGNITE-5433
 URL: https://issues.apache.org/jira/browse/IGNITE-5433
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Ksenia Rybakova
Priority: Minor
 Fix For: 2.1


The following memory config is used:
{noformat}





{noformat}
No any additional memory policies are configured.

Server RAM is 98Gb (at least 50Gb is free). Default memory policy should use 
80% of it.

But warning in log is:
{noformat}
[WARN ][main][IgniteCacheDatabaseSharedManager] No user-defined default 
MemoryPolicy found; system default of 1GB size will be used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5432) Test IgniteMarshallerCacheClassNameConflictTest failed

[Alexey Ivanov (JIRA)]

Alexey Ivanov created IGNITE-5432:
-

 Summary:  Test IgniteMarshallerCacheClassNameConflictTest failed
 Key: IGNITE-5432
 URL: https://issues.apache.org/jira/browse/IGNITE-5432
 Project: Ignite
  Issue Type: Bug
 Environment: 

Reporter: Alexey Ivanov


Test suit:
IgniteBinarySimpleNameMapperBasicTestSuite

Test:
IgniteMarshallerCacheClassNameConflictTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Persistent Distributed Store Metrics

[Alexey Goncharuk]

Denis,

Thanks for the review. I addressed your comments and merged the changes to
ignite-5267 branch.

2017-06-06 22:56 GMT+03:00 Denis Magda :

> > On Jun 5, 2017, at 8:02 PM, Konstantin Boudnik  wrote:
> >
> > On Mon, Jun 05, 2017 at 07:41PM, Dmitriy Setrakyan wrote:
> >> On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik 
> wrote:
> >>
> >>> Wow, hold on - as far as I remember there was a VOTE to accept the
> >>> contribution of the code into the project _on a branch_. We haven't
> vetted
> >>> its
> >>> inclusion into the next release, We are still at the phase of getting
> >>> familiar
> >>> with the code.
> >>>
> >>
> >> Cos, the community has been vetting the inclusion of the new code for
> over
> >> 3 weeks already (the process and dates are documented here [2]). To be
> >> honest, I am not sure what the appropriate time frame should be, but I
> >> would think that a month would be a good check-in point.
> >
> > I would think it should be as long as we, as the community, are
> comfortable
> > with the massive change coming into the release. We already been through
> the
> > discussion on the timing, etc. and I don't want to harp on that.
>
> Just in case I’m working on the high-level storage documentation. Here is
> a draft for your reference:
> https://apacheignite.readme.io/docs/distributed-persistent-store <
> https://apacheignite.readme.io/docs/distributed-persistent-store>
>
> The page is invisible for wide audience at the moment. Only for Ignite
> committers.
>
> —
> Denis
>
> > On Jun 5, 2017, at 8:02 PM, Konstantin Boudnik  wrote:
> >
> > On Mon, Jun 05, 2017 at 07:41PM, Dmitriy Setrakyan wrote:
> >> On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik 
> wrote:
> >>
> >>> Wow, hold on - as far as I remember there was a VOTE to accept the
> >>> contribution of the code into the project _on a branch_. We haven't
> vetted
> >>> its
> >>> inclusion into the next release, We are still at the phase of getting
> >>> familiar
> >>> with the code.
> >>>
> >>
> >> Cos, the community has been vetting the inclusion of the new code for
> over
> >> 3 weeks already (the process and dates are documented here [2]). To be
> >> honest, I am not sure what the appropriate time frame should be, but I
> >> would think that a month would be a good check-in point.
> >
> > I would think it should be as long as we, as the community, are
> comfortable
> > with the massive change coming into the release. We already been through
> the
> > discussion on the timing, etc. and I don't want to harp on that.
> >
> >> There is also an active stabilization thread for the persistence branch
> >> [3]. I encouraged the community to get involved and post any questions
> or
> >> concerns there as well.
> >>
> >> There is an upcoming in-memory computing conference that is coming up in
> >> June in Amsterdam [4], where there are many Ignite talks scheduled. It
> >> would be great to be able to talk about the persistence features of
> Ignite
> >> there as well. I would like to ask the community to mobilize with
> reviewing
> >> the donated code, so we could have something concrete to tell the
> audience
> >> on the conference.
> >
> > I am sure that having the code on the branch is good enough to be able
> to talk
> > about this. Having this in the release isn't really a contingency to be
> able
> > to make a presentation, right?
> >
> > Cos
> >
> >> [2]
> >> http://incubator.apache.org/ip-clearance/persistent-
> distributed-store-ignite.html
> >> [3]
> >> http://apache-ignite-developers.2346864.n4.nabble.com/Persistent-Store-
> Stabilization-for-release-td18288.html
> >> [4] https://imcsummit.org/
> >>
> >>
> >>
> >>> And from what I am seeing in the discussions like this [1], we need to
> be
> >>> extra careful.
> >>>
> >>
> >> I would keep the discussion in [1] separate from the persistence store.
> >> These are 2 unrelated issues. I will respond on [1] either today or
> >> tomorrow, but I agree in general that it should be fixed ASAP.
> >>
> >>
> >>> BTW, you have sent this email 9 days before the vote had happened! A
> bit
> >>> too
> >>> soon, if you ask me.
> >>>
> >>
> >> Cos, this email was sent 1 week after the initial donated code branch
> was
> >> presented to the community (see [2] above). The developers involved were
> >> eager to make it available to the users as soon as possible, but no code
> >> has been merged to the master branch yet.
> >>
> >> I would like to encourage everyone in the community to participate in
> the
> >> persistence branch coding discussions, like the one in this thread, and
> >> familiarize themselves with the code.
> >>
> >>
> >>>
> >>> [1] https://is.gd/UQCr51
> >>>
> >>> Cos
> >>>
> >>> On Wed, May 17, 2017 at 11:16AM, Dmitriy Govorukhin wrote:
>  Folk,
> 
>  As you know, ignite 2.1 will contain new module (pds), it will be
>  provide ability to store data on disk. Let's discuss what type of

[GitHub] ignite pull request #2101: IGNITE-5430

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-5430



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5430

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

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


commit 53f0958792919d72483f8a2a83ec5ba22b2d393c
Author: devozerov 
Date:   2017-06-07T09:57:00Z

Done.




---
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 #2100: IGNITE-5422

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5422



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5422

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

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


commit 7698dd35c39bd636e9386e25e29a108acd815886
Author: Alexander Paschenko 
Date:   2017-06-07T09:51:48Z

IGNITE-5422 CREATE TABLE with no value columns.

commit f481f9e73ec3278df7d8cb91017414b042682433
Author: Alexander Paschenko 
Date:   2017-06-07T09:52:25Z

Merge remote-tracking branch 'apache/master' into ignite-5422




---
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-5431) Better exception message when SQL cache flag doesn't match

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5431:
---

 Summary: Better exception message when SQL cache flag doesn't match
 Key: IGNITE-5431
 URL: https://issues.apache.org/jira/browse/IGNITE-5431
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
 Fix For: 2.1


SQL flag configuration check is performed in {{ClusterCachesInfo>checkCache}}. 
Default validation mechanics is used and the following error message appears: 
{code}
SQL flag mismatch (fix sql flag in cache configuration or set 
-DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true system property) 
[cacheName=SQL_PUBLIC_Person, localSql=false, remoteSql=true, 
rmtNodeId=b975316b-ad6a-4f64-b8a4-9eaac642]
{code}

Apparently, it is misleading because there is no such config property. Need to 
fix that and make sure that {{DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK}} 
has no effect on this check.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Key type name and value type name for CREATE TABLE

[Vladimir Ozerov]

Sergi,

This will require additional coordination between nodes, so I would not do
that for now. We have more serious problem here - binary metadata in
current implementation is not suited for DDL operations. We will feel it
better when start working on ALTER TABLE command, when single attribute
could change it's type in runtime, which is not supported by binary
metadata at the moment (this is append-only structure).

So I would put aside any questions around type names and metadata for now
and just let CREATE TABLE work. Hopefully in 2.2 we will have binary
metadata persistence, and align binary metadata with CREATE TABLE and ALTER
TABLE commands correctly.

On Wed, Jun 7, 2017 at 11:28 AM, Sergi Vladykin 
wrote:

> Vova,
>
> May be it makes sense to have an increasing version instead of UUID?
>
> Like sql_myschema_Person_1_Key.
>
> So that user will be able to pass just a table name `Person` to our API and
> receive a correct latest type name for that table.
>
> What do you think?
>
> Sergi
>
> 2017-06-07 11:20 GMT+03:00 Vladimir Ozerov :
>
> > Valya,
> >
> > It doesn't affect builder invoked from DML engine, as it know how to find
> > these names. As per users who want to call IgniteCache.put() on a cache
> > created through SQL - sorry, they will have hard times resolving actual
> > type name. This is OK for the first release, provided that we mask type
> > names for a reason - to avoid subtle exceptions when working with DDL and
> > DML.
> >
> > On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Vova,
> > >
> > > If you add unique suffix losing human-readable type names, how will the
> > > builder approach work? Maybe it makes sense to add an API call that
> > returns
> > > current type name for a table?
> > >
> > > -Val
> > >
> > > On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > > wrote:
> > >
> > > > Vova,
> > > >
> > > > I am not sure I like the key type name the way it is. Can we add some
> > > > separator between the table name and key name, like "_". To me
> > > "PERSON_KEY"
> > > > reads a lot better than "PERSONKey".
> > > >
> > > > D.
> > > >
> > > > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Unique suffix is a good idea.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > In the very first implementation of CREATE TABLE we applied the
> > > > following
> > > > > > rule to key and value type names:
> > > > > > keyTypeName == tableName + "Key"
> > > > > > valTypeName == tableName
> > > > > >
> > > > > > E.g.:
> > > > > > CREATE TABLE Person ...
> > > > > > keyTypeName == PERSONKey
> > > > > > valTypeName == PERSON
> > > > > >
> > > > > > After that user could potentially create objects with these type
> > > names
> > > > > > manually and add them to cache through native Ignite API:
> > > > > >
> > > > > > BinaryObject key =
> > > > IgniteBinary.builder("PERSONKey").addField().build();
> > > > > > BinaryObject val = IgniteBinary.builder("PERSON")
> > > .addField().build();
> > > > > > IgniteCache.put(key, val);
> > > > > >
> > > > > > This approach has two problems:
> > > > > > 1) Type names are not unique between different tables. it means
> > that
> > > if
> > > > > two
> > > > > > tables with the same name are created in different schemas, we
> got
> > a
> > > > > > conflict.
> > > > > > 2) Type names are bound to binary metadata, so if user decides to
> > do
> > > > the
> > > > > > following, he will receive and error about incompatible metadata:
> > > > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > > > DROP TABLE Person;
> > > > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old
> > meta
> > > > > still
> > > > > > has type "Integer".
> > > > > >
> > > > > > In order to avoid that I am going to add unique suffix or so
> (say,
> > > > UUID)
> > > > > to
> > > > > > type names. This way there will be no human-readable type names
> any
> > > > more,
> > > > > > but there will be no conflicts either. In future releases we will
> > > relax
> > > > > > this somehow.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[GitHub] ignite pull request #2085: IGNITE-5400 .NET: IgniteConfiguration.SqlConnecto...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #2099: IGNITE-5325 Cache group param in CREATE TABLE

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5325 Cache group param in CREATE TABLE



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

$ git pull https://github.com/gridgain/apache-ignite ignite-5325

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

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


commit 15bbe2093acfec931554da49f0144e57c78dff43
Author: Alexander Paschenko 
Date:   2017-06-07T08:50:54Z

IGNITE-5325 Cache group param in CREATE TABLE




---
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: is IGNITE-3142 actual now

[Вадим Опольский]

OK, thank you, Denis!

2017-06-06 21:04 GMT+03:00 Denis Magda :

> Vadim,
>
> Please try to run the reproducer attached. If the error pops up then the
> bug needs to be fixed.
>
> —
> Denis
>
> > On Jun 6, 2017, at 4:36 AM, Вадим Опольский 
> wrote:
> >
> > Hello guys!
> >
> > I want to resolve issue https://issues.apache.org/
> jira/browse/IGNITE-3142  >
> >
> > Is it actual now?
> >
> > Vadim Opolski
>
>

Re: Key type name and value type name for CREATE TABLE

[Sergi Vladykin]

Vova,

May be it makes sense to have an increasing version instead of UUID?

Like sql_myschema_Person_1_Key.

So that user will be able to pass just a table name `Person` to our API and
receive a correct latest type name for that table.

What do you think?

Sergi

2017-06-07 11:20 GMT+03:00 Vladimir Ozerov :

> Valya,
>
> It doesn't affect builder invoked from DML engine, as it know how to find
> these names. As per users who want to call IgniteCache.put() on a cache
> created through SQL - sorry, they will have hard times resolving actual
> type name. This is OK for the first release, provided that we mask type
> names for a reason - to avoid subtle exceptions when working with DDL and
> DML.
>
> On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Vova,
> >
> > If you add unique suffix losing human-readable type names, how will the
> > builder approach work? Maybe it makes sense to add an API call that
> returns
> > current type name for a table?
> >
> > -Val
> >
> > On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan 
> > wrote:
> >
> > > Vova,
> > >
> > > I am not sure I like the key type name the way it is. Can we add some
> > > separator between the table name and key name, like "_". To me
> > "PERSON_KEY"
> > > reads a lot better than "PERSONKey".
> > >
> > > D.
> > >
> > > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > > wrote:
> > >
> > > > Unique suffix is a good idea.
> > > >
> > > > Sergi
> > > >
> > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
> > > >
> > > > > Igniters,
> > > > >
> > > > > In the very first implementation of CREATE TABLE we applied the
> > > following
> > > > > rule to key and value type names:
> > > > > keyTypeName == tableName + "Key"
> > > > > valTypeName == tableName
> > > > >
> > > > > E.g.:
> > > > > CREATE TABLE Person ...
> > > > > keyTypeName == PERSONKey
> > > > > valTypeName == PERSON
> > > > >
> > > > > After that user could potentially create objects with these type
> > names
> > > > > manually and add them to cache through native Ignite API:
> > > > >
> > > > > BinaryObject key =
> > > IgniteBinary.builder("PERSONKey").addField().build();
> > > > > BinaryObject val = IgniteBinary.builder("PERSON")
> > .addField().build();
> > > > > IgniteCache.put(key, val);
> > > > >
> > > > > This approach has two problems:
> > > > > 1) Type names are not unique between different tables. it means
> that
> > if
> > > > two
> > > > > tables with the same name are created in different schemas, we got
> a
> > > > > conflict.
> > > > > 2) Type names are bound to binary metadata, so if user decides to
> do
> > > the
> > > > > following, he will receive and error about incompatible metadata:
> > > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > > DROP TABLE Person;
> > > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old
> meta
> > > > still
> > > > > has type "Integer".
> > > > >
> > > > > In order to avoid that I am going to add unique suffix or so (say,
> > > UUID)
> > > > to
> > > > > type names. This way there will be no human-readable type names any
> > > more,
> > > > > but there will be no conflicts either. In future releases we will
> > relax
> > > > > this somehow.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vladimir.
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-5430) Mask cache name for CREATE TABLE operation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5430:
---

 Summary: Mask cache name for CREATE TABLE operation
 Key: IGNITE-5430
 URL: https://issues.apache.org/jira/browse/IGNITE-5430
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.1


Masked name should be: {{sql_schemaName_tableName}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Key type name and value type name for CREATE TABLE

[Vladimir Ozerov]

Valya,

It doesn't affect builder invoked from DML engine, as it know how to find
these names. As per users who want to call IgniteCache.put() on a cache
created through SQL - sorry, they will have hard times resolving actual
type name. This is OK for the first release, provided that we mask type
names for a reason - to avoid subtle exceptions when working with DDL and
DML.

On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Vova,
>
> If you add unique suffix losing human-readable type names, how will the
> builder approach work? Maybe it makes sense to add an API call that returns
> current type name for a table?
>
> -Val
>
> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan 
> wrote:
>
> > Vova,
> >
> > I am not sure I like the key type name the way it is. Can we add some
> > separator between the table name and key name, like "_". To me
> "PERSON_KEY"
> > reads a lot better than "PERSONKey".
> >
> > D.
> >
> > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin  >
> > wrote:
> >
> > > Unique suffix is a good idea.
> > >
> > > Sergi
> > >
> > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
> > >
> > > > Igniters,
> > > >
> > > > In the very first implementation of CREATE TABLE we applied the
> > following
> > > > rule to key and value type names:
> > > > keyTypeName == tableName + "Key"
> > > > valTypeName == tableName
> > > >
> > > > E.g.:
> > > > CREATE TABLE Person ...
> > > > keyTypeName == PERSONKey
> > > > valTypeName == PERSON
> > > >
> > > > After that user could potentially create objects with these type
> names
> > > > manually and add them to cache through native Ignite API:
> > > >
> > > > BinaryObject key =
> > IgniteBinary.builder("PERSONKey").addField().build();
> > > > BinaryObject val = IgniteBinary.builder("PERSON")
> .addField().build();
> > > > IgniteCache.put(key, val);
> > > >
> > > > This approach has two problems:
> > > > 1) Type names are not unique between different tables. it means that
> if
> > > two
> > > > tables with the same name are created in different schemas, we got a
> > > > conflict.
> > > > 2) Type names are bound to binary metadata, so if user decides to do
> > the
> > > > following, he will receive and error about incompatible metadata:
> > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > DROP TABLE Person;
> > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> > > still
> > > > has type "Integer".
> > > >
> > > > In order to avoid that I am going to add unique suffix or so (say,
> > UUID)
> > > to
> > > > type names. This way there will be no human-readable type names any
> > more,
> > > > but there will be no conflicts either. In future releases we will
> relax
> > > > this somehow.
> > > >
> > > > Thoughts?
> > > >
> > > > Vladimir.
> > > >
> > >
> >
>

Re: Key type name and value type name for CREATE TABLE

[Vladimir Ozerov]

Dima,

Currently key and val type names for the table "myschema"."Person" will be
something like this.
key: "sql_myschema_Person_[RANDOM_UUID]_Key"
val: "sql_myschema_Person_[RANDOM_UUID]"


On Wed, Jun 7, 2017 at 5:42 AM, Dmitriy Setrakyan 
wrote:

> Vova,
>
> I am not sure I like the key type name the way it is. Can we add some
> separator between the table name and key name, like "_". To me "PERSON_KEY"
> reads a lot better than "PERSONKey".
>
> D.
>
> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin 
> wrote:
>
> > Unique suffix is a good idea.
> >
> > Sergi
> >
> > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov :
> >
> > > Igniters,
> > >
> > > In the very first implementation of CREATE TABLE we applied the
> following
> > > rule to key and value type names:
> > > keyTypeName == tableName + "Key"
> > > valTypeName == tableName
> > >
> > > E.g.:
> > > CREATE TABLE Person ...
> > > keyTypeName == PERSONKey
> > > valTypeName == PERSON
> > >
> > > After that user could potentially create objects with these type names
> > > manually and add them to cache through native Ignite API:
> > >
> > > BinaryObject key = IgniteBinary.builder("
> PERSONKey").addField().build();
> > > BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
> > > IgniteCache.put(key, val);
> > >
> > > This approach has two problems:
> > > 1) Type names are not unique between different tables. it means that if
> > two
> > > tables with the same name are created in different schemas, we got a
> > > conflict.
> > > 2) Type names are bound to binary metadata, so if user decides to do
> the
> > > following, he will receive and error about incompatible metadata:
> > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > DROP TABLE Person;
> > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> > still
> > > has type "Integer".
> > >
> > > In order to avoid that I am going to add unique suffix or so (say,
> UUID)
> > to
> > > type names. This way there will be no human-readable type names any
> more,
> > > but there will be no conflicts either. In future releases we will relax
> > > this somehow.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>

Re: Data compression in Ignite 2.0

[Антон Чураев]

Vyacheslav, correct me if something wrong

We could provide opportunity of choose between CPU usage and MEM/NET usage
for users by compression some attributes of stored objects.
You have learned design, and it is possible to localize changes in
marshalling without performance affect and current functionality.

I think, that it's usefull for our project and users.
Community, what do you think about this proposal?


2017-06-06 17:29 GMT+03:00 Vyacheslav Daradur :

> In short,
>
> During marshalling a fields is represented as BinaryFieldAccessor which
> manages its marshalling. It checks if the field is marked by annotation
> @BinaryCompression, in that case - binary  representation of field (bytes
> array) will be compressed. It will be marked as compressed by types
> constant (GridBinaryMarshaller.COMPRESSED), after this the compressed
> bytes
> array wiil be include in binary representation of whole object. Note,
> header of marshalled object will not be compressed. Compression affected
> only object's field representation.
>
> Objects in IgniteCache is represented as BinaryObject which is wrapper over
> bytes array of marshalled object.
> BinaryObject provides some usefull methods, which are used by Ignite
> systems.
> For example, the Queries use BinaryObject#field method, which deserializes
> only field of object, without deserializing of whole object.
> BinaryObject#field method during deserialization, if meets the constant of
> compressed type, decompress this bytes array, then continue unmarshalling
> as usual.
>
> Now, I introduced the Compressor interface in IgniteConfigurations, it
> allows user to use own implementation of compressor - it is the requirement
> in the task[1].
>
> As far as I know, Vladimir Ozerov doesn't like the idea of granting this
> opportunity to the user.
> In that case we can choose a compression algorithm which we will provide by
> default and will move the interface to internals of binary infractructure.
> For this case I've prepared benchmarked, which I've sent earlier.
>
> I vote for ZSTD algorithm[2], it provides good compression ratio and good
> throughput. It has implementation in Java, .NET and C++, and has
> ASF-friendly license, we can use it in the all Ignite platforms.
> You can look at an assessment of this algorithm in my benchmark's
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3592
> [2]https://github.com/facebook/zstd
>
>
> 2017-06-06 16:02 GMT+03:00 Антон Чураев :
>
> > Looks good for me.
> >
> > Could You propose design of implementation in couple of sentences?
> > So that we can estimate the completeness and complexity of the proposal.
> >
> > 2017-06-06 15:26 GMT+03:00 Vyacheslav Daradur :
> >
> > > Anton,
> > >
> > > Of course, the solution does not affect on existing implementation. I
> > mean,
> > > there is no changes if user not use the annotation @BinaryCompression.
> > (no
> > > performance changes)
> > > Only if user make decision to use compression on specific field or
> fields
> > > of a class - in that case compression will be used at marshalling in
> > > relation to annotated fields.
> > >
> > > 2017-06-06 15:10 GMT+03:00 Антон Чураев :
> > >
> > > > Vyacheslav,
> > > >
> > > > Is it possible to propose implementation that can be switched on
> > > on-demand?
> > > > In this case it should not affect performance of current solution.
> > > >
> > > > I mean, that users should make decision what is more important for
> > them:
> > > > throutput or memory/net usage.
> > > > May be they will be choose not all objects, or only some attributes
> of
> > > > objects for compress.
> > > >
> > > > 2017-06-06 14:48 GMT+03:00 Vyacheslav Daradur :
> > > >
> > > > > Conclusion:
> > > > > Provided solution allows reduce size of an object in IgniteCache at
> > the
> > > > > cost of throughput reduction (small - in some cases), it depends on
> > > part
> > > > of
> > > > > object which will be compressed and compression algorithm.
> > > > > I mean, we can make more effective use of memory, and in some cases
> > it
> > > > can
> > > > > reduce loading of the interconnect. (replication, rebalancing)
> > > > >
> > > > > Especially, it will be particularly useful for object's fields
> which
> > > are
> > > > > large text (>~ 250 bytes) and can be effectively compressed.
> > > > >
> > > > > 2017-06-06 12:00 GMT+03:00 Антон Чураев :
> > > > >
> > > > > > Vyacheslav, thank you! But could you please provide a conclusions
> > or
> > > > > > proposals based on this benchmarks?
> > > > > >
> > > > > > 2017-06-06 11:28 GMT+03:00 Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > > >
> > > > > > > Dmitry,
> > > > > > >
> > > > > > > Excel-pages:
> > > > > > >
> > > > > > > 1). "Compression ratio (2)" - shows object size, with
> compression
> > > and
> > > > > > > without compression. (Conditions: literal text)
> > > > > > > 1st 

Re: Persistent Store Stabilization for release

[Alexey Goncharuk]

I am currently in the middle of the debugging - the issue does not look
related to the persistent store changes now.

2017-06-07 5:47 GMT+03:00 Dmitriy Setrakyan :

> On Tue, Jun 6, 2017 at 1:21 AM, Semyon Boikov 
> wrote:
>
> > Does anybody monitor TeamCity for ignite-5267? I see suite 'Ignite PDS 2'
> > started to hang 100% after recent merges.
> >
>
> Do we have any progress on this?
>

Re: New version of Web Console released

[Alexey Kuznetsov]

Denis,

>>>Sounds great! BTW, was this ticket resolved as a part of the release:
>>> https://issues.apache.org/jira/browse/IGNITE-5303 (supporting multiple
RDBMS configurations from the wizard)

Yes we fixed this issue, now it is on testing with all major RDBMS.

-- 
Alexey Kuznetsov

Re: New version of Web Console released

[Alexey Kuznetsov]

Muthu,

>> Is the web console not part of or deploy-able from the ignite fabric
distrib
Yes. It is not part of binary distribution.
You can build it from sources or use Docker image (see:
https://hub.docker.com/r/apacheignite/web-console-standalone/tags/)

>> .but i do not find any directory named "modules" under my IGNITE_HOME
You need to download SOURCE release.


>>> Can i download only a trial version from console.gridgain.com ?
No. console.gridgain.com contains Web Console that based on Apache Ignite
code base, but with additional features developed by GridGain.
Please contact GridGain for that.

>> Will i able to use this as an alternative to say an ORM like MyBatis?
It depends in what you need. Please describe your use case.



-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-5429) Affinity run: optimize partition reservations for caches in the same group

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-5429:


 Summary: Affinity run: optimize partition reservations for caches 
in the same group
 Key: IGNITE-5429
 URL: https://issues.apache.org/jira/browse/IGNITE-5429
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
 Fix For: 2.1


For affinityRun we reserve partitions per-cache 
(GridJobProcessor.PartitionsReservation), it can be optimzied if caches belong 
to the same group.

Also need add corresponding tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)