[jira] [Updated] (IGNITE-5819) SQL: add support for TRUNCATE TABLE command.
[ https://issues.apache.org/jira/browse/IGNITE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh updated IGNITE-5819: - Fix Version/s: 2.5 > SQL: add support for TRUNCATE TABLE command. > > > Key: IGNITE-5819 > URL: https://issues.apache.org/jira/browse/IGNITE-5819 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Labels: sql-engine > Fix For: 2.5 > > > Add support for "TRUNCATE TABLE" command syntax. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7149) Gradient boosting for decision tree
[ https://issues.apache.org/jira/browse/IGNITE-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Nozhkin reassigned IGNITE-7149: Assignee: (was: Ilya Nozhkin) > Gradient boosting for decision tree > --- > > Key: IGNITE-7149 > URL: https://issues.apache.org/jira/browse/IGNITE-7149 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Priority: Major > > We want to implement gradient boosting for decision trees. It should be new > implementation of Trainer interface and we should keep possibility to choose > which trainer we want to use for our tree. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413124#comment-16413124 ] Roman Meerson commented on IGNITE-6879: --- [~SomeFire] Thanks for pointing. Fixed. As well as comments on ConditionFalse class > Support Spring 2.0 > -- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413112#comment-16413112 ] Ryabov Dmitrii commented on IGNITE-6879: [~homich], thank you for changes. I see failed test on TC - SpringDataExample.java:[111,29] cannot find symbol [1]. You should change spring example too. [1] https://ci.ignite.apache.org/viewLog.html?buildId=1157885=buildResultsDiv=IgniteTests24Java8_IgniteSpring > Support Spring 2.0 > -- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7962) More cases of suppressed exceptions in IsolatedUpdater
[ https://issues.apache.org/jira/browse/IGNITE-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413107#comment-16413107 ] Dmitriy Pavlov commented on IGNITE-7962: [~gvvinblade], thank you for reviewing the changes. > More cases of suppressed exceptions in IsolatedUpdater > -- > > Key: IGNITE-7962 > URL: https://issues.apache.org/jira/browse/IGNITE-7962 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > > IsolatedUpdater is a StreamReciever. > The contract for StreamReciever.recieve() is, @throws > org.apache.ignite.IgniteException If failed. > However, there's a number of cases where this doesn't happen and exceptions > are suppressed after being written in server log. Should replace (or augment) > log.error()'s with throw new IgniteException(). > See maillist discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7962) More cases of suppressed exceptions in IsolatedUpdater
[
https://issues.apache.org/jira/browse/IGNITE-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413101#comment-16413101
]
Igor Seliverstov commented on IGNITE-7962:
--
[~ilyak], [~dpavlov], changes in {{DataStreamerImpl.IsolatedUpdater#receive}}
are OK, but {{DataStreamerImpl.Buffer#submit}} isn't expected to throw any
exceptions except {{IgniteDataStreamerTimeoutException}}. What you need to do
is to finish {{curFut}} with corresponding exception and return. It will cancel
DataStreamer in a proper way.
> More cases of suppressed exceptions in IsolatedUpdater
> --
>
> Key: IGNITE-7962
> URL: https://issues.apache.org/jira/browse/IGNITE-7962
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> IsolatedUpdater is a StreamReciever.
> The contract for StreamReciever.recieve() is, @throws
> org.apache.ignite.IgniteException If failed.
> However, there's a number of cases where this doesn't happen and exceptions
> are suppressed after being written in server log. Should replace (or augment)
> log.error()'s with throw new IgniteException().
> See maillist discussion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7911) TX SQL: restrict usages of unsupported APIs and configuration parameters
[ https://issues.apache.org/jira/browse/IGNITE-7911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413083#comment-16413083 ] Igor Seliverstov commented on IGNITE-7911: -- [~al.psc], checkMvccDisabled may be replaced with MvccUtils.verifyOperationSupport - it's good to use single approach. Everything else looks OK to me > TX SQL: restrict usages of unsupported APIs and configuration parameters > > > Key: IGNITE-7911 > URL: https://issues.apache.org/jira/browse/IGNITE-7911 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.5 > > > We need to make sure that when MVCC flag is enabled, users get correct > exception in case of invalid configurations and/or API usages. Two general > rules should apply > 1) SQL and cache operations cannot be mixed in the same transactions because > they still use different APIs. This restriction will be removed in future > when native cache API is reworked to new locking logic. > 2) If configuration is invalid or not-yet-supported API is called, user gets > correct exception instead of invalid result. > All listed cases must be covered with tests. > Checklist: > 1) Cache configuration > 1.1) Cache store is not allowed for TX caches > 1.2) Expiry policy is not allowed for TX caches > 1.3) Interceptors are not allowed for TX caches > 2) Cache API unsupported operations - throw UnsupportedOperationException and > create relevant ticket (if one doesn't exist): > 2.1) withExpiryPolicy > 2.2) Continuous queries > 2.3) "clear" method family > 2.4) "lock" method family > 2.5) "load" method family > 2.6) "peek" method family > 2.7) "evict" method family > 3) Cache API consistency - make sure that these operations use consistent > snapshot assigned to transaction (as with other operations). If this is the > case - do nothing; if this is not the case - throw > UnsupportedOperationException and create a ticket (if one doesn't exist) > 3.1) Scan queries > 3.2) "size" method family > 3.3) Iterator methods (iterator, localEntries) > 4) Mixed native API and SQL usage is restricted and proper IgniteException is > thrown. When snapshot is requested for the first time we should mark > transation as either "SQL" or "native". If any SQL query is executed on > "native" transaction or vice versa throw an exception (IllegalStateException? > IgniteException?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6879) Support Spring 2.0
[ https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16413072#comment-16413072 ] Roman Meerson commented on IGNITE-6879: --- [~SomeFire] another portion of update based on your comments > Support Spring 2.0 > -- > > Key: IGNITE-6879 > URL: https://issues.apache.org/jira/browse/IGNITE-6879 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.3 >Reporter: Alexey Kukushkin >Assignee: Roman Meerson >Priority: Major > > Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt > with Spring 2.0. Trying to change the Spring dependency version to > 2.0.0.release results in compile errors like below and requires regression in > general. > This improvement was created to either migrate from Spring 1.1 to 2.0 or > create another set of modules ignite-spring-xxx-2 to have backward > compatibility with Spring 1.1. > [ERROR] > /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10] > name clash: deleteAll(java.lang.Iterable) in > org.apache.ignite.springdata.repository.IgniteRepository and > deleteAll(java.lang.Iterable) in > org.springframework.data.repository.CrudRepository have the same erasure, yet > neither overrides the other -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8014) Node.js client: basic/minimal version
[
https://issues.apache.org/jira/browse/IGNITE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411853#comment-16411853
]
Alexey Kosenchuk edited comment on IGNITE-8014 at 3/25/18 10:47 AM:
[~vozerov] thanks for the comments...
> 1) CacheClient - what is the purpose of setKeyType and setValueType methods
> from user perspective?
To be able to specify the Binary Protocol types (at least, types codes) of keys
and values which user plans to send/receive.
Their usage is optional.
When the types are not explicitly specified, the client will do automatic
mapping between some of the JavaScript types and the Binary Protocol types (the
mapping table is described in the header of the ObjectType class).
But this mapping may not satisfy user's needs.
For example, javascript has only one numeric type (number) that is standard
double. But user may want to send the protocol's INT, not DOUBLE.
Alternatively, every send/receive method could have the types (type codes)
specification parameters. But that seems excessive.
User still can send/receive data of different types to/from the same cache:
a) either call setKeyType()/setValueType() methods to change the types before
sending/receiving.
b) or use different CacheClient instances operated with the same cache, and
set different key/value types in different instances.
c) or use automatic mapping only if it's enough.
> 2) Errors - typically we try to have as least different error types as
> possible.
Fully agree with this approach.
> IllegalStateError, LostConnectionError - appears to be the same thing -
> client is not connected; I would merge it into a single entity
They are different.
IllegalStateError means an operation is not started at all (a request was not
sent to the server).
LostConnectionError means an operation was started (a request was sent to the
server) but is not completed as the connection is lost (so, the response is not
received).
We believe it is an important difference for user.
Will try to explain this more clearly in the comments.
The current "failover" algorithm, suggested in other clients, makes this a bit
more complicated. As a client will have not two ("connected"/"disconnected")
states but three: +"connecting" state when the client tries to establish a
connection with one of the endpoints from the list.
Probably, IllegalStateError should be thrown in this state as well.
> InternalError - I doubt user has any chance to react to this error in any way
> except of logging or rethrowing; I would remove it and use base
> IgniteClientError instead
The only reason was some consistency - base class error is never thrown, only
subclasses. But this is not a strong reason)))
Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are
unlikely can be processed by user either. Usually just logged for debug purpose.
Theoretically they also can be substituted by IgniteClientError with different
messages.
was (Author: alexey.kosenchuk):
[~vozerov] thanks for the comments...
> 1) CacheClient - what is the purpose of setKeyType and setValueType methods
> from user perspective?
To be able to specify the Binary Protocol types (at least, types codes) of keys
and values which user plans to send/receive.
Their usage is optional.
When the types are not explicitly specified, the client will do automatic
mapping between some of the JavaScript types and the Binary Protocol types (the
mapping table is described in the header of the ObjectType class).
But this mapping may not satisfy user's needs.
For example, javascript has only one numeric type (number) that is standard
double. But user may want to send the protocol's INT, not DOUBLE.
Alternatively, every send/receive method could have the types (type codes)
specification parameters. But that seems excessive.
User still can send/receive data of different types to/from the same cache:
a) either call setKeyType()/setValueType() methods to change the types before
sending/receiving.
b) or use different CacheClient instances operated with the same cache, and
set different key/value types in different instances.
c) or use automatic mapping only if it's enough.
> 2) Errors - typically we try to have as least different error types as
> possible.
Fully agree with this approach.
> IllegalStateError, LostConnectionError - appears to be the same thing -
> client is not connected; I would merge it into a single entity
They are different.
IllegalStateError means an operation is not started at all (a request was not
sent to the server).
LostConnectionError means an operation was started (a request was sent to the
server) but is not completed as the connection is lost (so, the response is not
received).
We believe it is an important difference for user.
Will try to explain this more clearly in the comments.
> InternalError - I doubt user has
[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release
[
https://issues.apache.org/jira/browse/IGNITE-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16412968#comment-16412968
]
Roman Guseinov commented on IGNITE-7774:
[~vveider] ,
1. Checked a build based on the master branch which includes IGNITE-7862. The
issue is still reproducable there.
2. Added maven-dependency-plugin instead of manually added dependencies as you
proposed before. It looks like a better way to solve the issue. I also
specified the jackson-core version to avoid conflicts with apache-rest-http
because ignite-gce doesn't include jackson-core 2.6.5 (it includes 2.1.3 by
default).
I updated the PR please take a look.
TC results:
[https://ci.ignite.apache.org/viewLog.html?buildId=1158398=buildResultsDiv=IgniteTests24Java8_IgniteGce]
Thanks.
> Missing Google Cloud libraries at binary release
>
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
> Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
> * google-http-client-1.22.0.jar
> * google-http-client-jackson2-1.22.0.jar
> * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
>
>
>
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
>
>
>
> value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>
>
>
>
> {code}
> 6. Copy into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML
> application context (make sure all classes used in Spring configuration are
> present at CLASSPATH)
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
> at org.apache.ignite.Ignition.start(Ignition.java:350)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> instantiate Spring XML application context (make sure all classes used in
> Spring configuration are present at CLASSPATH)
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
> at
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
> at org.apache.ignite.Ignition.start(Ignition.java:347)
> ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
> Cannot create inner bean
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean
> property 'discoverySpi'; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3'
> defined in URL
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
> Cannot create inner bean
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
> of type
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
> while setting bean property 'ipFinder'; nested
[jira] [Assigned] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kosenchuk reassigned IGNITE-8039:
Assignee: Prachi Garg
> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
> Issue Type: Bug
> Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow
> a client development basing on the spec only, w/o looking at other client
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol
> spec (v.2.4)
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?)
> - what is Object array (type code 23) ? What is the difference between it and
> Objects Wrapped In Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
>
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field
> name".
> - "Repeat for as many times as the total number of schemas you have" ->
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the
> number of fields in the Data Object ?
> Objects Wrapped In Array
>
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not
> primitives)." -> does it mean that in general a complex object (103) must
> always be sent via the Binary Protocol in a wrapper (27)?
> - "Byte array size" -> "Payload size" or "Size of the whole array with
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
