[GitHub] ignite pull request #813: ignite-3326

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/813 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: HTTP Rest API: increment/decrement or append/prepend are candidates to deprecate?

Sure Dmitriy I can pick it up. Regards Saikat On Tue, Jun 21, 2016 at 6:34 AM, Dmitriy Setrakyan wrote: > I personally think we should not remove these commands, unless they become > really painful to maintain. > > Igniters, anyone in the community wants to pick up

[jira] [Created] (IGNITE-3345) Implement support for optional key type in REST HTTP get command

Alexey Kuznetsov created IGNITE-3345: Summary: Implement support for optional key type in REST HTTP get command Key: IGNITE-3345 URL: https://issues.apache.org/jira/browse/IGNITE-3345 Project:

Re: Add key type detection for REST HTTP GET command

I also like the idea. Should we file a ticket? On Mon, Jun 20, 2016 at 3:31 AM, Sergey Kozlov wrote: > Hi Alexey. > > It's a good idea! Now I'm facing the issue when load the data via java code > (Long, Person) but REST Get/GetAll returns null for loaded keys. I suppose >

Re: HTTP Rest API: increment/decrement or append/prepend are candidates to deprecate?

I personally think we should not remove these commands, unless they become really painful to maintain. Igniters, anyone in the community wants to pick up IGNITE-945 ? Does not look like a complicated fix. Thanks, D. On Mon, Jun 20, 2016 at 6:23

[GitHub] ignite pull request #820: ignite-3336

GitHub user sboikov opened a pull request: https://github.com/apache/ignite/pull/820 ignite-3336 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3336 Alternatively you can review and apply these

[GitHub] ignite pull request #819: IGNITE-3330: Cache::Invoke method implemented.

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/819 IGNITE-3330: Cache::Invoke method implemented. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite ignite-1680 Alternatively you

Re: IGNITE-3337

Hi Alexey , Sergey Thank you for your time and reviewing the PR. I agree we can deprecate cacheName for metadata command. I have updated the files and request you to review the changes. Also can you please share where the docs are hosted and I can then update the rest api doc. Regards Saikat

[GitHub] ignite pull request #818: Ignite 3184

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/818 Ignite 3184 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3184 Alternatively you can review and apply

Re: Ignite 3227

Sure Alexey, Thank you Saikat On Mon, Jun 20, 2016 at 10:36 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Saikat, > > Please also correct the test to check new methods for PARTITIONED and > REPLICATED cache - I see that you only test them for local cache and > partition 0 (I added

Re: Ignite 3227

Saikat, Please also correct the test to check new methods for PARTITIONED and REPLICATED cache - I see that you only test them for local cache and partition 0 (I added a comment to the ticket). 2016-06-20 9:17 GMT-07:00 Saikat Maitra : > Thank you Ilya, I will review

[jira] [Created] (IGNITE-3344) Couldn't import Ignite Image to Google Compute

Vasilisa Sidorova created IGNITE-3344: -- Summary: Couldn't import Ignite Image to Google Compute Key: IGNITE-3344 URL: https://issues.apache.org/jira/browse/IGNITE-3344 Project: Ignite

Re: Ignite 3227

Thank you Ilya, I will review and update PR accordingly. Regards Saikat On Mon, Jun 20, 2016 at 8:36 PM, Ilya Lantukh wrote: > Hi Saikat, > > I've added a comment to the jira ticket regarding implementation of > GridCacheAdapter#localSizeLong(int partition,

Re: Ignite REST API is not actually RESTful

Be stateless == be intrinsically limited. No transactions, no efficient queries, etc.. We have serious interest to both HTTP protocol itself and to Node.JS integration which is based on it. If we are concerned about "REST" word, then lets rename it to "not-exactly-REST" :-) Vladimir. On Mon, Jun

Re: Ignite Download links broken

I thought that Mirrors were broken, not the resolution. If we are still using the mirrors, then there is no issue. On Mon, Jun 20, 2016 at 8:34 AM, Anton Vinogradov wrote: > Dmitriy, > > I'm not sure I understand what should I ask INFRA to do. > We had broken mirror

Re: Ignite Download links broken

Dmitriy, I'm not sure I understand what should I ask INFRA to do. We had broken mirror resolving at download page, not sure INFRA can solve html/js issues. On Mon, Jun 20, 2016 at 6:07 PM, Dmitriy Setrakyan wrote: > Anton, did you file an INFRA issue? > > On Mon, Jun 20,

Re: Ignite REST API is not actually RESTful

Alexey, In this case we will make Not REST again. Here is good article about idempotency: http://www.restapitutorial.com/lessons/idempotency.html On Mon, Jun 20, 2016 at 5:46 PM, Alexey Kuznetsov wrote: > Pavel, > > >> What is the use case? > As far as I know it could

Re: Ignite REST API is not actually RESTful

Pavel, >> What is the use case? As far as I know it could be used for quick testing. But I agree that it is not mandatory. Testing could be done with appropriate tools. >>> large SQL query that could be fetched page by page >>REST is stateless. This should be handled by the user (with

Re: Ignite REST API is not actually RESTful

Alexey, > be able to run all command from browser address line What is the use case? Non-developers do not need that. Developers have better tools than a browser to test an API. GET requests must never modify data, this is very important. People and software assume GET to be safe. > large SQL

Re: Ignite REST API is not actually RESTful

Pavel, Current API was developed long time ago and was not actively developed. It may looks inconsistent for some use cases. May be it is a good idea to develop new API and deprecate current. >From my experience we should take care: 1) "null" cache names 2) some commands could have state, for

Re: Ignite REST API is not actually RESTful

We also can consider to keep the compatibility and move new API either to new http port or use new url (e.g. http://localhost:8080/api/rest instead of http://localhost:8080/ignite) On Mon, Jun 20, 2016 at 5:15 PM, Alexey Kuznetsov wrote: > Pavel, > > Current API was

Re: Ignite REST API is not actually RESTful

Pavel, Looks good, but: According to Swagger demo need to use singular (caches->cache). And I'm also not sure we need ignite preffix. On Mon, Jun 20, 2016 at 5:15 PM, Alexey Kuznetsov wrote: > Pavel, > > Current API was developed

[jira] [Created] (IGNITE-3342) Hadoop: improve Java options documentation.

Vladimir Ozerov created IGNITE-3342: --- Summary: Hadoop: improve Java options documentation. Key: IGNITE-3342 URL: https://issues.apache.org/jira/browse/IGNITE-3342 Project: Ignite Issue

Ignite REST API is not actually RESTful

Igniters, There are two serious issues with current Ignite REST API: 1) It does not care about HTTP verbs (GET/POST/etc). GET must never modify anything, for example (because GET requests can be cached, duplicated, etc). 2) Proper resource paths are not used For example, to get a cache value,

Re: Ignite Download links broken

Thanks Anton, works for me now. On Mon, Jun 20, 2016 at 4:29 PM, Anton Vinogradov wrote: > Download urls changed to https://archive.apache.org/dist/ignite/* > > > On Mon, Jun 20, 2016 at 4:14 PM, Dmitriy Setrakyan > wrote: > >> I think we should

Re: Ignite Download links broken

Download urls changed to https://archive.apache.org/dist/ignite/* On Mon, Jun 20, 2016 at 4:14 PM, Dmitriy Setrakyan wrote: > I think we should do it, at least for now, until the mirror issue is > resolved. We should also file an INFRA issue in parallel. Anton, do you >

HTTP Rest API: increment/decrement or append/prepend are candidates to deprecate?

Hi Igniters I've reviewed the API for HTTP Rest provided by Ignite and have a question: do we really need some commands which cover the particular cases of value type like increment/decrement (value is integer) or append/prepend (value is string).

Re: Ignite Download links broken

I think we should do it, at least for now, until the mirror issue is resolved. We should also file an INFRA issue in parallel. Anton, do you mind fixing it? On Mon, Jun 20, 2016 at 6:13 AM, Anton Vinogradov wrote: > We already provides "hard-coded links (without mirror) " to

Re: Ignite Download links broken

We already provides "hard-coded links (without mirror) " to previous versions. For example https://archive.apache.org/dist/ignite/1.4.0/apache-ignite-fabric-1.4.0-bin.zip I think we can do that for all releases. On Mon, Jun 20, 2016 at 4:08 PM, Dmitriy Setrakyan wrote: >

Re: Ignite Download links broken

Is it possible to provide hard-coded links (without mirror) in the mean time, while we are resolving this issue? Pavel, I think this issue should be reported to INFRA, not Ignite. I doubt Ignite community can do anything to fix it. D. On Mon, Jun 20, 2016 at 6:04 AM, Pavel Tupitsyn

Re: Ignite Download links broken

I have reported this issue 4 months ago, please see details there: https://issues.apache.org/jira/browse/IGNITE-2743 Christos, your link is missing .cgi suffix. Pavel. On Mon, Jun 20, 2016 at 3:53 PM, Vladisav Jelisavcic wrote: > Not working for me also, > but only 1.6.0

Re: Ignite Download links broken

Not working for me also, but only 1.6.0 (latest) and 1.5.0.final, the rest is working fine. On Mon, Jun 20, 2016 at 8:02 AM, Sergey Kozlov wrote: > Hi > > It's a known issue: apache site puts links to a nearest site for user (I > suppose it based on IP address) and does it

[jira] [Created] (IGNITE-3341) Hadoop: add ability to link native libraries to HadoopClassLoader if they were loaded by parent classloader.

Vladimir Ozerov created IGNITE-3341: --- Summary: Hadoop: add ability to link native libraries to HadoopClassLoader if they were loaded by parent classloader. Key: IGNITE-3341 URL:

[GitHub] ignite pull request #817: IGNITE-3339 - get() in explicit READ_COMMITTED tra...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/817 IGNITE-3339 - get() in explicit READ_COMMITTED transaction on OFFHEAP… …_TIERED cache copies data from offheap to onheap. Test. You can merge this pull request into a Git

[jira] [Created] (IGNITE-3339) get() in explicit READ_COMMITTED transaction on OFFHEAP_TIERED cache copies data from offheap to onheap.

Dmitry Karachentsev created IGNITE-3339: --- Summary: get() in explicit READ_COMMITTED transaction on OFFHEAP_TIERED cache copies data from offheap to onheap. Key: IGNITE-3339 URL:

Re: Add key type detection for REST HTTP GET command

Hi Alexey. It's a good idea! Now I'm facing the issue when load the data via java code (Long, Person) but REST Get/GetAll returns null for loaded keys. I suppose that the reason is wrong mapping of the key passed to REST command. On Mon, Jun 20, 2016 at 1:20 PM, Alexey Kuznetsov

Add key type detection for REST HTTP GET command

Hi, All! It seems that in current implementation ( https://apacheignite.readme.io/docs/rest-api#get) GET command could work only with String keys. How about to add optional parameter "keyType" and implement support for common built-in types such as Integer, Long, UUID,... and user classes that a

Re: IGNITE-3337

Hi Saikat and Alexey. I think that the solution suggested by Alexey is simple one. Actually null-named cache is widely used for now and we can't remove it (or at least we should re-think the approach for such caches). On the other hand the size of metadata returned by REST command even for dozen

Re: IGNITE-3337

Hi, Saikat I reviewed you PR and I think we should deprecate "cacheName" parameter in metadata command. In current implementation when "cacheName" was not specified that means to get "default" cache (with name=null) And now it will be impossible to take metadata for such cache. But I think for

[jira] [Created] (IGNITE-3338) CachePartialUpdateCheckedException: Failed to update keys during load test with eviction configured

Ksenia Rybakova created IGNITE-3338: --- Summary: CachePartialUpdateCheckedException: Failed to update keys during load test with eviction configured Key: IGNITE-3338 URL:

Re: Ignite Download links broken

Hi It's a known issue: apache site puts links to a nearest site for user (I suppose it based on IP address) and does it incorrect. On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan wrote: > Worked for me just now. Can you try again? > > On Sun, Jun 19, 2016 at 2:59 AM,