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

[dkarachentsev]

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 repository by running:

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

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

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


commit 4a620790f4c5c2e2f6dcb93fdc9bca9f7faf1f90
Author: dkarachentsev 
Date:   2016-06-20T10:33:50Z

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

Test.




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

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

[Sergey Kozlov]

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).
Moreover last pair of commands actually don't work (ticket
 has been filed by me a
year ago!).
Such commands helps to test Rest but they're away from real use cases.

I suppose they could be marked as deprecated for 1.7 and removed for 1.8.
Any such operation should be implemented via SQL level.

Thoughts?

-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite Download links broken

[Dmitriy Setrakyan]

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 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, 2016 at 6:42 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > Thanks Anton, works for me now.
> > >
> > > On Mon, Jun 20, 2016 at 4:29 PM, Anton Vinogradov <
> > > avinogra...@gridgain.com> wrote:
> > >
> > >> Download urls changed to https://archive.apache.org/dist/ignite/*
> > >>
> > >>
> > >> On Mon, Jun 20, 2016 at 4:14 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > >> > 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
> > >>> mind fixing it?
> > >>>
> > >>> On Mon, Jun 20, 2016 at 6:13 AM, Anton Vinogradov 
> > wrote:
> > >>>
> >  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 <
> >  dsetrak...@apache.org>
> >  wrote:
> > 
> >  > 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 <
> >  ptupit...@gridgain.com>
> >  > wrote:
> >  >
> >  >> 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 <
> >  vladis...@gmail.com
> >  >> > wrote:
> >  >>
> >  >>> 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 <
> >  skoz...@gridgain.com>
> >  >>> 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 incorrect.
> >  
> >   On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
> >   dsetrak...@apache.org>
> >   wrote:
> >  
> >   > Worked for me just now. Can you try again?
> >   >
> >   > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
> >   > chris...@gridgain.com> wrote:
> >   >
> >   >> Hey guys,
> >   >>
> >   >> The links on the website seem to be broken, can someone
> check
> >  this?
> >   >>
> >   >> https://ignite.apache.org/download.html#binaries <
> >   >> https://ignite.apache.org/download.html#binaries>
> >   >>
> >   >> Thanks,
> >   >>
> >   >> Christos
> >   >
> >   >
> >   >
> >  
> >  
> >   --
> >   Sergey Kozlov
> >   GridGain Systems
> >   www.gridgain.com
> >  
> >  >>>
> >  >>>
> >  >>
> >  >
> > 
> > >>>
> > >>>
> > >>
> > >
> >
>

Re: Ignite Download links broken

[Anton Vinogradov]

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, 2016 at 6:42 AM, Pavel Tupitsyn 
> wrote:
>
> > Thanks Anton, works for me now.
> >
> > On Mon, Jun 20, 2016 at 4:29 PM, Anton Vinogradov <
> > avinogra...@gridgain.com> wrote:
> >
> >> Download urls changed to https://archive.apache.org/dist/ignite/*
> >>
> >>
> >> On Mon, Jun 20, 2016 at 4:14 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> >> > 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
> >>> mind fixing it?
> >>>
> >>> On Mon, Jun 20, 2016 at 6:13 AM, Anton Vinogradov 
> wrote:
> >>>
>  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 <
>  dsetrak...@apache.org>
>  wrote:
> 
>  > 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 <
>  ptupit...@gridgain.com>
>  > wrote:
>  >
>  >> 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 <
>  vladis...@gmail.com
>  >> > wrote:
>  >>
>  >>> 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 <
>  skoz...@gridgain.com>
>  >>> 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 incorrect.
>  
>   On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
>   dsetrak...@apache.org>
>   wrote:
>  
>   > Worked for me just now. Can you try again?
>   >
>   > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
>   > chris...@gridgain.com> wrote:
>   >
>   >> Hey guys,
>   >>
>   >> The links on the website seem to be broken, can someone check
>  this?
>   >>
>   >> https://ignite.apache.org/download.html#binaries <
>   >> https://ignite.apache.org/download.html#binaries>
>   >>
>   >> Thanks,
>   >>
>   >> Christos
>   >
>   >
>   >
>  
>  
>   --
>   Sergey Kozlov
>   GridGain Systems
>   www.gridgain.com
>  
>  >>>
>  >>>
>  >>
>  >
> 
> >>>
> >>>
> >>
> >
>

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

[Vasilisa Sidorova (JIRA)]

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
  Issue Type: Bug
  Components: general
Affects Versions: 1.6
Reporter: Vasilisa  Sidorova


-
DESCRIPTION
-
Couldn't run Ignite docker container on the Google Compute due to missing 
ignite-google-image-1.0.0.tar.gz file
-
STEPS FOR REPRODUCE
-
# In accordance with the instruction 
https://apacheignite.readme.io/docs/docker-deployment run command 
{noformat}
 gcloud compute images  create   --source-uri 
gs://ignite-media/ignite-google-image-1.0.0.tar.gz
{noformat}
-
ACTUAL RESULT
-
The result is " - The resource 
'http://storage.googleapis.com/ignite-media/ignite-google-image-1.0.0.tar.gz' 
of type 'Google Cloud Storage object' was not found."
-
EXPECTED RESULT
-
The image should be created without any exceptions



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

Re: Ignite 3227

[Saikat Maitra]

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, CachePeekMode[] peekModes)
> method.
>
> On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra 
> wrote:
>
> > Hi
> >
> > I have raised the PR[1] for the jira ticket Ignite 3227 [2] and wanted to
> > discuss further on this issue.
> >
> > 1. I am running 2 nodes cluster and running in client mode another node
> for
> > functional test. I added 20 keys and keys are distributed in 2 nodes as
> 11
> > keys in node 1 and 9 keys in node 2. When I am printing partition 1 size
> > and partition 2 size I can get correct values but incase I provide some
> > other partition like 5 I am observing that I am getting 11 as value.
> >
> > 2. I have added unit test testpartitionsize() similar to testSize() but
> > similar tests are failing for both the tests. Need further investigation
> on
> > the same.
> >
> >
> > Regards
> > Saikat
> >
> > [1] https://github.com/apache/ignite/pull/815
> > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> >
>
>
>
> --
> Best regards,
> Ilya
>

Re: Ignite REST API is not actually RESTful

[Vladimir Ozerov]

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 20, 2016 at 5:55 PM, Anton Vinogradov 
wrote:

> 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 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
> LIMIT/OFFSET
> > in SQL).
> > In this case we will force users to implement complex solutions.
> > IMHO in some cases we could have state.
> >
> >
> > On Mon, Jun 20, 2016 at 9:37 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > 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 query that could be fetched page by page
> > > REST is stateless. This should be handled by the user (with
> LIMIT/OFFSET
> > in
> > > SQL).
> > >
> > > Pavel.
> > >
> > > On Mon, Jun 20, 2016 at 5:20 PM, Sergey Kozlov 
> > > wrote:
> > >
> > > > 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 <
> > > akuznet...@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > 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 example large SQL query that
> > > could
> > > > > be fetched page by page
> > > > > 3) It will be "nice  to have" to be able to run all command from
> > > browser
> > > > > address line.
> > > > >
> > > > >
> > > > > On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn <
> > ptupit...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > 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, instead of
> > > > > > GET /ignite?cmd=get=myKey=partionedCache
> > > > > > it should be
> > > > > > GET /ignite/caches/partitionedCache/keys/myKey/
> > > > > >
> > > > > > Modify cache key:
> > > > > > PUT /ignite/caches/partitionedCache/keys/myKey/
> > > > > > DELETE /ignite/caches/partitionedCache/keys/myKey/
> > > > > >
> > > > > >
> > > > > > I think we should deprecate current API and provide a new one
> that
> > > > > follows
> > > > > > the guidelines.
> > > > > > A good writeup on a proper REST API design can be found there:
> > > > > > https://zalando.github.io/restful-api-guidelines/
> > > > > >
> > > > > >
> > > > > > Thoughts, comments?
> > > > > >
> > > > > > Pavel.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>

Re: Ignite Download links broken

[Sergey Kozlov]

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, Christos Erotocritou <
> chris...@gridgain.com> wrote:
>
>> Hey guys,
>>
>> The links on the website seem to be broken, can someone check this?
>>
>> https://ignite.apache.org/download.html#binaries <
>> https://ignite.apache.org/download.html#binaries>
>>
>> Thanks,
>>
>> Christos
>
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite Download links broken

[Pavel Tupitsyn]

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 (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 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, Christos Erotocritou <
>> > chris...@gridgain.com> wrote:
>> >
>> >> Hey guys,
>> >>
>> >> The links on the website seem to be broken, can someone check this?
>> >>
>> >> https://ignite.apache.org/download.html#binaries <
>> >> https://ignite.apache.org/download.html#binaries>
>> >>
>> >> Thanks,
>> >>
>> >> Christos
>> >
>> >
>> >
>>
>>
>> --
>> Sergey Kozlov
>> GridGain Systems
>> www.gridgain.com
>>
>
>

Re: Ignite REST API is not actually RESTful

[Alexey Kuznetsov]

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 LIMIT/OFFSET
in SQL).
In this case we will force users to implement complex solutions.
IMHO in some cases we could have state.


On Mon, Jun 20, 2016 at 9:37 PM, Pavel Tupitsyn 
wrote:

> 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 query that could be fetched page by page
> REST is stateless. This should be handled by the user (with LIMIT/OFFSET in
> SQL).
>
> Pavel.
>
> On Mon, Jun 20, 2016 at 5:20 PM, Sergey Kozlov 
> wrote:
>
> > 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 <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > 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 example large SQL query that
> could
> > > be fetched page by page
> > > 3) It will be "nice  to have" to be able to run all command from
> browser
> > > address line.
> > >
> > >
> > > On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn 
> > > wrote:
> > >
> > > > 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, instead of
> > > > GET /ignite?cmd=get=myKey=partionedCache
> > > > it should be
> > > > GET /ignite/caches/partitionedCache/keys/myKey/
> > > >
> > > > Modify cache key:
> > > > PUT /ignite/caches/partitionedCache/keys/myKey/
> > > > DELETE /ignite/caches/partitionedCache/keys/myKey/
> > > >
> > > >
> > > > I think we should deprecate current API and provide a new one that
> > > follows
> > > > the guidelines.
> > > > A good writeup on a proper REST API design can be found there:
> > > > https://zalando.github.io/restful-api-guidelines/
> > > >
> > > >
> > > > Thoughts, comments?
> > > >
> > > > Pavel.
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Ignite REST API is not actually RESTful

[Pavel Tupitsyn]

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, instead of
GET /ignite?cmd=get=myKey=partionedCache
it should be
GET /ignite/caches/partitionedCache/keys/myKey/

Modify cache key:
PUT /ignite/caches/partitionedCache/keys/myKey/
DELETE /ignite/caches/partitionedCache/keys/myKey/


I think we should deprecate current API and provide a new one that follows
the guidelines.
A good writeup on a proper REST API design can be found there:
https://zalando.github.io/restful-api-guidelines/


Thoughts, comments?

Pavel.

Re: Ignite REST API is not actually RESTful

[Pavel Tupitsyn]

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 query that could be fetched page by page
REST is stateless. This should be handled by the user (with LIMIT/OFFSET in
SQL).

Pavel.

On Mon, Jun 20, 2016 at 5:20 PM, Sergey Kozlov  wrote:

> 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 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 example large SQL query that could
> > be fetched page by page
> > 3) It will be "nice  to have" to be able to run all command from browser
> > address line.
> >
> >
> > On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn 
> > wrote:
> >
> > > 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, instead of
> > > GET /ignite?cmd=get=myKey=partionedCache
> > > it should be
> > > GET /ignite/caches/partitionedCache/keys/myKey/
> > >
> > > Modify cache key:
> > > PUT /ignite/caches/partitionedCache/keys/myKey/
> > > DELETE /ignite/caches/partitionedCache/keys/myKey/
> > >
> > >
> > > I think we should deprecate current API and provide a new one that
> > follows
> > > the guidelines.
> > > A good writeup on a proper REST API design can be found there:
> > > https://zalando.github.io/restful-api-guidelines/
> > >
> > >
> > > Thoughts, comments?
> > >
> > > Pavel.
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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

[Vladimir Ozerov (JIRA)]

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 Type: Improvement
  Components: documentation, hadoop
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.7


1) Mentioned library path;
2) CMS garbage collector with class unloading options;
3) PermGetn/MetaSpace
4) Code cache

Examples:

*Java 8*
{{-J-XX:MaxMetaspaceSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
-J-XX:+CMSPermGenSweepingEnabled 
-J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}

*Java 7*
{{-J-XX:MaxPermSize=[VALUE] -J-XX:ReservedCodeCacheSize=768m 
-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled 
-J-XX:+CMSPermGenSweepingEnabled 
-J-Djava.library.path=/usr/iop/current/hadoop/lib/native/}}



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

Re: Ignite REST API is not actually RESTful

[Sergey Kozlov]

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 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 example large SQL query that could
> be fetched page by page
> 3) It will be "nice  to have" to be able to run all command from browser
> address line.
>
>
> On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn 
> wrote:
>
> > 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, instead of
> > GET /ignite?cmd=get=myKey=partionedCache
> > it should be
> > GET /ignite/caches/partitionedCache/keys/myKey/
> >
> > Modify cache key:
> > PUT /ignite/caches/partitionedCache/keys/myKey/
> > DELETE /ignite/caches/partitionedCache/keys/myKey/
> >
> >
> > I think we should deprecate current API and provide a new one that
> follows
> > the guidelines.
> > A good writeup on a proper REST API design can be found there:
> > https://zalando.github.io/restful-api-guidelines/
> >
> >
> > Thoughts, comments?
> >
> > Pavel.
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Re: Ignite REST API is not actually RESTful

[Anton Vinogradov]

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 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 LIMIT/OFFSET
> in SQL).
> In this case we will force users to implement complex solutions.
> IMHO in some cases we could have state.
>
>
> On Mon, Jun 20, 2016 at 9:37 PM, Pavel Tupitsyn 
> wrote:
>
> > 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 query that could be fetched page by page
> > REST is stateless. This should be handled by the user (with LIMIT/OFFSET
> in
> > SQL).
> >
> > Pavel.
> >
> > On Mon, Jun 20, 2016 at 5:20 PM, Sergey Kozlov 
> > wrote:
> >
> > > 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 <
> > akuznet...@gridgain.com
> > > >
> > > wrote:
> > >
> > > > 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 example large SQL query that
> > could
> > > > be fetched page by page
> > > > 3) It will be "nice  to have" to be able to run all command from
> > browser
> > > > address line.
> > > >
> > > >
> > > > On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > wrote:
> > > >
> > > > > 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, instead of
> > > > > GET /ignite?cmd=get=myKey=partionedCache
> > > > > it should be
> > > > > GET /ignite/caches/partitionedCache/keys/myKey/
> > > > >
> > > > > Modify cache key:
> > > > > PUT /ignite/caches/partitionedCache/keys/myKey/
> > > > > DELETE /ignite/caches/partitionedCache/keys/myKey/
> > > > >
> > > > >
> > > > > I think we should deprecate current API and provide a new one that
> > > > follows
> > > > > the guidelines.
> > > > > A good writeup on a proper REST API design can be found there:
> > > > > https://zalando.github.io/restful-api-guidelines/
> > > > >
> > > > >
> > > > > Thoughts, comments?
> > > > >
> > > > > Pavel.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite REST API is not actually RESTful

[Anton Vinogradov]

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 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 example large SQL query that could
> be fetched page by page
> 3) It will be "nice  to have" to be able to run all command from browser
> address line.
>
>
> On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn 
> wrote:
>
> > 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, instead of
> > GET /ignite?cmd=get=myKey=partionedCache
> > it should be
> > GET /ignite/caches/partitionedCache/keys/myKey/
> >
> > Modify cache key:
> > PUT /ignite/caches/partitionedCache/keys/myKey/
> > DELETE /ignite/caches/partitionedCache/keys/myKey/
> >
> >
> > I think we should deprecate current API and provide a new one that
> follows
> > the guidelines.
> > A good writeup on a proper REST API design can be found there:
> > https://zalando.github.io/restful-api-guidelines/
> >
> >
> > Thoughts, comments?
> >
> > Pavel.
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite REST API is not actually RESTful

[Alexey Kuznetsov]

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 example large SQL query that could
be fetched page by page
3) It will be "nice  to have" to be able to run all command from browser
address line.


On Mon, Jun 20, 2016 at 8:59 PM, Pavel Tupitsyn 
wrote:

> 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, instead of
> GET /ignite?cmd=get=myKey=partionedCache
> it should be
> GET /ignite/caches/partitionedCache/keys/myKey/
>
> Modify cache key:
> PUT /ignite/caches/partitionedCache/keys/myKey/
> DELETE /ignite/caches/partitionedCache/keys/myKey/
>
>
> I think we should deprecate current API and provide a new one that follows
> the guidelines.
> A good writeup on a proper REST API design can be found there:
> https://zalando.github.io/restful-api-guidelines/
>
>
> Thoughts, comments?
>
> Pavel.
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Add key type detection for REST HTTP GET command

[Sergey Kozlov]

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 
wrote:

> 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 valid JavaBeans?
>
> Sample: http://host:port
> /ignite?cmd=get=1=myCache=Long
>
> Thoughts?
>
> --
> Alexey Kuznetsov
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

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

[Vladimir Ozerov (JIRA)]

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: https://issues.apache.org/jira/browse/IGNITE-3341
 Project: Ignite
  Issue Type: Task
  Components: hadoop
Affects Versions: 1.6
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 1.7






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

Re: Ignite Download links broken

[Dmitriy Setrakyan]

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 
wrote:

> 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 (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 incorrect.
>>>
>>> On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org>
>>> wrote:
>>>
>>> > Worked for me just now. Can you try again?
>>> >
>>> > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
>>> > chris...@gridgain.com> wrote:
>>> >
>>> >> Hey guys,
>>> >>
>>> >> The links on the website seem to be broken, can someone check this?
>>> >>
>>> >> https://ignite.apache.org/download.html#binaries <
>>> >> https://ignite.apache.org/download.html#binaries>
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Christos
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Sergey Kozlov
>>> GridGain Systems
>>> www.gridgain.com
>>>
>>
>>
>

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

[Dmitry Karachentsev (JIRA)]

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: https://issues.apache.org/jira/browse/IGNITE-3339
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Dmitry Karachentsev
 Fix For: 1.7






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

Add key type detection for REST HTTP GET command

[Alexey Kuznetsov]

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 valid JavaBeans?

Sample: http://host:port/ignite?cmd=get=1=myCache=Long

Thoughts?

-- 
Alexey Kuznetsov

Re: Ignite Download links broken

[Vladisav Jelisavcic]

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 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, Christos Erotocritou <
> > chris...@gridgain.com> wrote:
> >
> >> Hey guys,
> >>
> >> The links on the website seem to be broken, can someone check this?
> >>
> >> https://ignite.apache.org/download.html#binaries <
> >> https://ignite.apache.org/download.html#binaries>
> >>
> >> Thanks,
> >>
> >> Christos
> >
> >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite Download links broken

[Anton Vinogradov]

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:

> 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 
> wrote:
>
>> 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 (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 incorrect.

 On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
 dsetrak...@apache.org>
 wrote:

 > Worked for me just now. Can you try again?
 >
 > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
 > chris...@gridgain.com> wrote:
 >
 >> Hey guys,
 >>
 >> The links on the website seem to be broken, can someone check this?
 >>
 >> https://ignite.apache.org/download.html#binaries <
 >> https://ignite.apache.org/download.html#binaries>
 >>
 >> Thanks,
 >>
 >> Christos
 >
 >
 >


 --
 Sergey Kozlov
 GridGain Systems
 www.gridgain.com

>>>
>>>
>>
>

Re: Ignite Download links broken

[Dmitriy Setrakyan]

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 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:
>
> > 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 
> > wrote:
> >
> >> 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 <
> vladis...@gmail.com
> >> > wrote:
> >>
> >>> 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 incorrect.
> 
>  On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
>  dsetrak...@apache.org>
>  wrote:
> 
>  > Worked for me just now. Can you try again?
>  >
>  > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
>  > chris...@gridgain.com> wrote:
>  >
>  >> Hey guys,
>  >>
>  >> The links on the website seem to be broken, can someone check this?
>  >>
>  >> https://ignite.apache.org/download.html#binaries <
>  >> https://ignite.apache.org/download.html#binaries>
>  >>
>  >> Thanks,
>  >>
>  >> Christos
>  >
>  >
>  >
> 
> 
>  --
>  Sergey Kozlov
>  GridGain Systems
>  www.gridgain.com
> 
> >>>
> >>>
> >>
> >
>

Re: Ignite Download links broken

[Anton Vinogradov]

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
> mind fixing it?
>
> On Mon, Jun 20, 2016 at 6:13 AM, Anton Vinogradov  wrote:
>
>> 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:
>>
>> > 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 > >
>> > wrote:
>> >
>> >> 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 <
>> vladis...@gmail.com
>> >> > wrote:
>> >>
>> >>> 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 incorrect.
>> 
>>  On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
>>  dsetrak...@apache.org>
>>  wrote:
>> 
>>  > Worked for me just now. Can you try again?
>>  >
>>  > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
>>  > chris...@gridgain.com> wrote:
>>  >
>>  >> Hey guys,
>>  >>
>>  >> The links on the website seem to be broken, can someone check
>> this?
>>  >>
>>  >> https://ignite.apache.org/download.html#binaries <
>>  >> https://ignite.apache.org/download.html#binaries>
>>  >>
>>  >> Thanks,
>>  >>
>>  >> Christos
>>  >
>>  >
>>  >
>> 
>> 
>>  --
>>  Sergey Kozlov
>>  GridGain Systems
>>  www.gridgain.com
>> 
>> >>>
>> >>>
>> >>
>> >
>>
>
>

Re: Ignite Download links broken

[Pavel Tupitsyn]

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 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 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 <
>>> dsetrak...@apache.org>
>>> wrote:
>>>
>>> > 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 <
>>> ptupit...@gridgain.com>
>>> > wrote:
>>> >
>>> >> 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 <
>>> vladis...@gmail.com
>>> >> > wrote:
>>> >>
>>> >>> 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 incorrect.
>>> 
>>>  On Mon, Jun 20, 2016 at 8:37 AM, Dmitriy Setrakyan <
>>>  dsetrak...@apache.org>
>>>  wrote:
>>> 
>>>  > Worked for me just now. Can you try again?
>>>  >
>>>  > On Sun, Jun 19, 2016 at 2:59 AM, Christos Erotocritou <
>>>  > chris...@gridgain.com> wrote:
>>>  >
>>>  >> Hey guys,
>>>  >>
>>>  >> The links on the website seem to be broken, can someone check
>>> this?
>>>  >>
>>>  >> https://ignite.apache.org/download.html#binaries <
>>>  >> https://ignite.apache.org/download.html#binaries>
>>>  >>
>>>  >> Thanks,
>>>  >>
>>>  >> Christos
>>>  >
>>>  >
>>>  >
>>> 
>>> 
>>>  --
>>>  Sergey Kozlov
>>>  GridGain Systems
>>>  www.gridgain.com
>>> 
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>

Re: Ignite 3227

[Saikat Maitra]

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 a comment to the ticket).
>
> 2016-06-20 9:17 GMT-07:00 Saikat Maitra :
>
> > 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, CachePeekMode[]
> peekModes)
> > > method.
> > >
> > > On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra <
> saikat.mai...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi
> > > >
> > > > I have raised the PR[1] for the jira ticket Ignite 3227 [2] and
> wanted
> > to
> > > > discuss further on this issue.
> > > >
> > > > 1. I am running 2 nodes cluster and running in client mode another
> node
> > > for
> > > > functional test. I added 20 keys and keys are distributed in 2 nodes
> as
> > > 11
> > > > keys in node 1 and 9 keys in node 2. When I am printing partition 1
> > size
> > > > and partition 2 size I can get correct values but incase I provide
> some
> > > > other partition like 5 I am observing that I am getting 11 as value.
> > > >
> > > > 2. I have added unit test testpartitionsize() similar to testSize()
> but
> > > > similar tests are failing for both the tests. Need further
> > investigation
> > > on
> > > > the same.
> > > >
> > > >
> > > > Regards
> > > > Saikat
> > > >
> > > > [1] https://github.com/apache/ignite/pull/815
> > > > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ilya
> > >
> >
>

Re: Ignite 3227

[Alexey Goncharuk]

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 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, CachePeekMode[] peekModes)
> > method.
> >
> > On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra  >
> > wrote:
> >
> > > Hi
> > >
> > > I have raised the PR[1] for the jira ticket Ignite 3227 [2] and wanted
> to
> > > discuss further on this issue.
> > >
> > > 1. I am running 2 nodes cluster and running in client mode another node
> > for
> > > functional test. I added 20 keys and keys are distributed in 2 nodes as
> > 11
> > > keys in node 1 and 9 keys in node 2. When I am printing partition 1
> size
> > > and partition 2 size I can get correct values but incase I provide some
> > > other partition like 5 I am observing that I am getting 11 as value.
> > >
> > > 2. I have added unit test testpartitionsize() similar to testSize() but
> > > similar tests are failing for both the tests. Need further
> investigation
> > on
> > > the same.
> > >
> > >
> > > Regards
> > > Saikat
> > >
> > > [1] https://github.com/apache/ignite/pull/815
> > > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> > >
> >
> >
> >
> > --
> > Best regards,
> > Ilya
> >
>

[GitHub] ignite pull request #818: Ignite 3184

[iveselovskiy]

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 these changes as the patch at:

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


commit 2d67524cfd75f4e2f4bb5e258732127cfeb85b43
Author: Ignite Teamcity 
Date:   2016-02-25T12:06:11Z

1.6.0-SNAPSHOT

commit 1a3ec645cf87d2c301810c93248aeef4c09ed04f
Author: Alexey Goncharuk 
Date:   2016-02-25T02:43:35Z

IGNITE-2707 - Fixed skipStore flag handling - Fixes #508.

Signed-off-by: Alexey Goncharuk 

commit 99bbc72383375c41c980a40bb23461e0b4ec8b7e
Author: Alexey Goncharuk 
Date:   2016-02-25T02:45:00Z

IGNITE-2709 - Fixed potential SOE on high-contented cache locks - Fixes 
#509.

Signed-off-by: Alexey Goncharuk 

commit b6f7e63af572c385f280532d9400c60c2827603d
Author: Valentin Kulichenko 
Date:   2016-02-23T00:21:15Z

IGNITE-2706 - Fixed GridHandleTable.lookup()

commit fbff90e521c3b82783b6d442d684620e30dd55f5
Author: Valentin Kulichenko 
Date:   2016-02-26T00:34:03Z

IGNITE-2450 - More fixes for Proxy serialization

commit aad672b591d87c04774bf4787468398feb1b
Author: sboikov 
Date:   2016-02-24T16:32:57Z

Compatibility fix for CacheContinuousQueryBatchAck message.
(cherry picked from commit faa77e2)

commit 3da257f2d2f191649d0213524644d9e67b03d8d2
Author: sboikov 
Date:   2016-02-25T10:54:11Z

Continuous query compatibility fix (topVer can be null for old 
CacheContinuousQueryEntry).
(cherry picked from commit dee6190)

commit 9c9129f1f81ce59715c7eb536c6637ae26ec1dee
Author: sboikov 
Date:   2016-02-26T07:46:50Z

Set serialVersionUID for CacheEntryPredicateAdapter for backward 
compatibility.
(cherry picked from commit 7d65ec9)

commit c951fc06be5fd731fe192456c6547fa116a64485
Author: sboikov 
Date:   2016-02-26T12:49:37Z

ignite-2720 Need call 'initializeLocalAddresses' before starting client 
message worker.

commit dc8630b6e6afc95fdfa7dda21d3fa747e95347b1
Author: AKuznetsov 
Date:   2016-02-29T04:26:32Z

IGNITE-2726 Added missing off heap metrics for Visor Console.

commit 26bd1dfb424c57eba368bc243dc390e3dff5e805
Author: iveselovskiy 
Date:   2016-02-25T11:38:22Z

IGNITE-2352: IGFS: Correct access time and modification time propagation 
from secondary file system. This closes #501.

commit dff4015b8291ebc9aafc47e1dfa5fcd733956349
Author: iveselovskiy 
Date:   2016-02-10T12:45:58Z

IGNITE-2195: Implemented Hadoop FileSystem factory capable of working with 
kerberized file systems. This closes #464.

commit 1af09d44716b61b42f8df08d75ff25e322260b70
Author: vozerov-gridgain 
Date:   2016-02-10T13:57:16Z

Improved KerberosHadoopFileSystemFactory JavaDocs.

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

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

Signed-off-by: Anton Vinogradov 

commit bbe9983b2ca7da969f7f3d2008c2a04f698ab223
Author: vozerov-gridgain 
Date:   2016-02-26T11:45:30Z

IGNITE-2715: No more spam from within GridQueryProcessor about missing 
field for BinaryProperty. This closes #514.

commit 7d26ba8f424402e2e7e826c5770ce2273955
Author: vozerov-gridgain 
Date:   2016-02-26T11:19:44Z

IGNITE-2681: Binary serialization warning is no longer printed to the log.

commit 91edd7e04d7e90829d9ad176d1f3b31d7a8ebadf
Author: vozerov-gridgain 
Date:   2016-02-26T11:28:02Z

IGNITE-2681: Binary serialization warning is no longer printed to the log 
(part 2).

commit 77d67892441059bfcf00b66b777ef2cdfddbae43
Author: vozerov-gridgain 
Date:   2016-03-02T11:26:11Z

IGNITE-2681: Suppress warnings from org.jsr166 package as well.

commit 79815b70b5ce4c7441773becae18fbb22782b4a6
Author: Anton Vinogradov 
Date:   2016-03-04T11:17:30Z

IGNITE-2758 IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't 
contain any classes

commit 75ed3f0a4245b77e9b0fa252255a9ba1c7cf6241
Author: Alexey Kuznetsov 
Date:   2016-03-09T08:09:18Z

Minor Visor fixes.

commit bbd189cac828b2724eafccc405c453552d3479e4
Author: agura 

Re: IGNITE-3337

[Saikat Maitra]

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

On Mon, Jun 20, 2016 at 3:08 PM, Sergey Kozlov  wrote:

> 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 caches is not
> large and can be filtered (iterated) on the client side. So I suppose the
> ticket should be updated according suggested approach.
>
>
>
>
> On Mon, Jun 20, 2016 at 12:28 PM, Alexey Kuznetsov <
> akuznet...@gridgain.com>
> wrote:
>
> > 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 this command there is a little sense to extract metadata
> > for single cache,
> >  because any way on server side they will be extracted for all caches.
> > See:
> >
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager#sqlMetadata
> > line 999.
> >
> > Also for performance reason it is much faster to get all metadata at
> once.
> >
> > So, I suggest - to deprecate "cacheName" parameter and fix documentation.
> >
> > Thoughts?
> >
> >
> > On Sun, Jun 19, 2016 at 10:42 PM, Saikat Maitra  >
> > wrote:
> >
> > > Hello,
> > >
> > > I have raised the PR[1] for the following Jira ticket[2].
> > >
> > > Please review and let me know any feedback
> > >
> > > Regards
> > > Saikat
> > >
> > > [1] https://github.com/apache/ignite/pull/816
> > > [2] https://issues.apache.org/jira/browse/IGNITE-3337
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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

[Alexey Kuznetsov (JIRA)]

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: Ignite
  Issue Type: Task
  Components: cache
Affects Versions: 1.6
Reporter: Alexey Kuznetsov
 Fix For: 1.7


It seems that in current implementation 
(https://apacheignite.readme.io/docs/rest-api#get)
GET command could work only with String keys.

We can add optional parameter "keyType" and implement support for common 
built-in types such as Integer, Long, UUID,... and user classes that a valid 
JavaBeans.

Sample: http://host:port/ignite?cmd=get=1=myCache=Long



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

Re: IGNITE-3337

[Alexey Kuznetsov]

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 this command there is a little sense to extract metadata
for single cache,
 because any way on server side they will be extracted for all caches.
See: 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager#sqlMetadata
line 999.

Also for performance reason it is much faster to get all metadata at once.

So, I suggest - to deprecate "cacheName" parameter and fix documentation.

Thoughts?


On Sun, Jun 19, 2016 at 10:42 PM, Saikat Maitra 
wrote:

> Hello,
>
> I have raised the PR[1] for the following Jira ticket[2].
>
> Please review and let me know any feedback
>
> Regards
> Saikat
>
> [1] https://github.com/apache/ignite/pull/816
> [2] https://issues.apache.org/jira/browse/IGNITE-3337
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: IGNITE-3337

[Sergey Kozlov]

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 caches is not
large and can be filtered (iterated) on the client side. So I suppose the
ticket should be updated according suggested approach.




On Mon, Jun 20, 2016 at 12:28 PM, Alexey Kuznetsov 
wrote:

> 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 this command there is a little sense to extract metadata
> for single cache,
>  because any way on server side they will be extracted for all caches.
> See:
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager#sqlMetadata
> line 999.
>
> Also for performance reason it is much faster to get all metadata at once.
>
> So, I suggest - to deprecate "cacheName" parameter and fix documentation.
>
> Thoughts?
>
>
> On Sun, Jun 19, 2016 at 10:42 PM, Saikat Maitra 
> wrote:
>
> > Hello,
> >
> > I have raised the PR[1] for the following Jira ticket[2].
> >
> > Please review and let me know any feedback
> >
> > Regards
> > Saikat
> >
> > [1] https://github.com/apache/ignite/pull/816
> > [2] https://issues.apache.org/jira/browse/IGNITE-3337
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

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

[isapego]

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 can review and apply these changes as the patch at:

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


commit 2ccbad0ca93cdb0987bd4fabe9f0ea3f78bc5aff
Author: isapego 
Date:   2015-10-26T14:16:26Z

First approach for the IGNITE-1680

commit e65abb09199c39cb337ec16c06985e4b3171ec99
Author: isapego 
Date:   2016-06-15T12:33:54Z

Merge branch 'master' into ignite-1680

commit d2b2db67ba2e7a25e3e7b787b6b10ff77ffba72e
Author: isapego 
Date:   2016-06-15T15:56:07Z

IGNITE-1680: Merge-related fixes.

commit c7bddfe9b407a153a0b82607a53ddd47414e1532
Author: isapego 
Date:   2016-06-16T18:17:54Z

IGNITE-1680: Fix for reading of the NULL values.

commit a3b6b5c4d384526d8375a30b7910d3fe34e57a76
Author: isapego 
Date:   2016-06-17T17:36:50Z

IGNITE-1680: Invoke implemented.

commit 52d02e4fa67b55f5f0fd3b0a3831d6914110f761
Author: isapego 
Date:   2016-06-20T15:00:04Z

IGNITE-1680: Documentation fixed.

commit 1e4fb50839d759d68d3e7b4c3991f9e5127cb51f
Author: isapego 
Date:   2016-06-20T15:19:58Z

IGNITE-1680: Refactoring.

commit 4d9717e699c4a8c888224e1802f909628204d75a
Author: isapego 
Date:   2016-06-20T15:55:42Z

IGNITE-1680: Documentation improvements.

commit 2f1c8b9ed60d5bbab0184aefb313500c4805fb4e
Author: isapego 
Date:   2016-06-20T17:57:38Z

IGNTIE-1680: Added rethrowing exceptions to Java at the top level of
callbacks.

commit 730dc68afeb7133dd6426dad46362c26ca854b45
Author: isapego 
Date:   2016-06-20T18:44:07Z

IGNITE-1680: Added some more tests.

commit d66b134cb77e82183410a22a13c490afee149c44
Author: isapego 
Date:   2016-06-20T18:47:57Z

IGNITE-1680: Minor 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.
---

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

[asfgit]

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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Add key type detection for REST HTTP GET command

[Dmitriy Setrakyan]

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
> that the reason is wrong mapping of the key passed to REST command.
>
> On Mon, Jun 20, 2016 at 1:20 PM, Alexey Kuznetsov  >
> wrote:
>
> > 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 valid JavaBeans?
> >
> > Sample: http://host:port
> > /ignite?cmd=get=1=myCache=Long
> >
> > Thoughts?
> >
> > --
> > Alexey Kuznetsov
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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

[Saikat Maitra]

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 IGNITE-945
> ? Does not look like a
> complicated fix.
>
> Thanks,
> D.
>
> On Mon, Jun 20, 2016 at 6:23 AM, Sergey Kozlov 
> wrote:
>
> > 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).
> > Moreover last pair of commands actually don't work (ticket
> >  has been filed by me
> a
> > year ago!).
> > Such commands helps to test Rest but they're away from real use cases.
> >
> > I suppose they could be marked as deprecated for 1.7 and removed for 1.8.
> > Any such operation should be implemented via SQL level.
> >
> > Thoughts?
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>

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

[Dmitriy Setrakyan]

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 AM, Sergey Kozlov  wrote:

> 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).
> Moreover last pair of commands actually don't work (ticket
>  has been filed by me a
> year ago!).
> Such commands helps to test Rest but they're away from real use cases.
>
> I suppose they could be marked as deprecated for 1.7 and removed for 1.8.
> Any such operation should be implemented via SQL level.
>
> Thoughts?
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

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

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-3338:
---

 Summary: CachePartialUpdateCheckedException: Failed to update keys 
during load test with eviction configured
 Key: IGNITE-3338
 URL: https://issues.apache.org/jira/browse/IGNITE-3338
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Ksenia Rybakova
 Fix For: 1.7


The following exceptions occur during load test with eviction configured:

{noformat}
ERROR: The benchmark of random operation failed.
Type '--help' for usage.
Finishing main test [ts=1466178657166, date=Fri Jun 17 08:50:57 PDT 2016]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys 
(retry update if possible).: [26, 1872066, 1945790, 2405741, 3845651, 
4830233, 7284502, 8555643]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1467)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1972)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.removeAll(IgniteCacheProxy.java:1416)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.doRemoveAll(IgniteCacheRandomOperationBenchmark.java:809)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeRandomOperation(IgniteCacheRandomOperationBenchmark.java:551)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeOutOfTx(IgniteCacheRandomOperationBenchmark.java:509)
at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.test(IgniteCacheRandomOperationBenchmark.java:156)
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:176)
at java.lang.Thread.run(Thread.java:745)
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [26, 1872066, 1945790, 
2405741, 3845651, 4830233, 7284502, 8555643]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onResult(GridNearAtomicUpdateFuture.java:311)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:2958)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$700(GridDhtAtomicCache.java:129)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:266)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:264)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:624)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:322)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:246)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:83)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:205)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
... 1 more
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:369)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1711)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1482)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:2937)
at 

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

[sboikov]

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 changes as the patch at:

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


commit b6f7e63af572c385f280532d9400c60c2827603d
Author: Valentin Kulichenko 
Date:   2016-02-23T00:21:15Z

IGNITE-2706 - Fixed GridHandleTable.lookup()

commit fbff90e521c3b82783b6d442d684620e30dd55f5
Author: Valentin Kulichenko 
Date:   2016-02-26T00:34:03Z

IGNITE-2450 - More fixes for Proxy serialization

commit aad672b591d87c04774bf4787468398feb1b
Author: sboikov 
Date:   2016-02-24T16:32:57Z

Compatibility fix for CacheContinuousQueryBatchAck message.
(cherry picked from commit faa77e2)

commit 3da257f2d2f191649d0213524644d9e67b03d8d2
Author: sboikov 
Date:   2016-02-25T10:54:11Z

Continuous query compatibility fix (topVer can be null for old 
CacheContinuousQueryEntry).
(cherry picked from commit dee6190)

commit 9c9129f1f81ce59715c7eb536c6637ae26ec1dee
Author: sboikov 
Date:   2016-02-26T07:46:50Z

Set serialVersionUID for CacheEntryPredicateAdapter for backward 
compatibility.
(cherry picked from commit 7d65ec9)

commit c951fc06be5fd731fe192456c6547fa116a64485
Author: sboikov 
Date:   2016-02-26T12:49:37Z

ignite-2720 Need call 'initializeLocalAddresses' before starting client 
message worker.

commit dc8630b6e6afc95fdfa7dda21d3fa747e95347b1
Author: AKuznetsov 
Date:   2016-02-29T04:26:32Z

IGNITE-2726 Added missing off heap metrics for Visor Console.

commit 26bd1dfb424c57eba368bc243dc390e3dff5e805
Author: iveselovskiy 
Date:   2016-02-25T11:38:22Z

IGNITE-2352: IGFS: Correct access time and modification time propagation 
from secondary file system. This closes #501.

commit dff4015b8291ebc9aafc47e1dfa5fcd733956349
Author: iveselovskiy 
Date:   2016-02-10T12:45:58Z

IGNITE-2195: Implemented Hadoop FileSystem factory capable of working with 
kerberized file systems. This closes #464.

commit 1af09d44716b61b42f8df08d75ff25e322260b70
Author: vozerov-gridgain 
Date:   2016-02-10T13:57:16Z

Improved KerberosHadoopFileSystemFactory JavaDocs.

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

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

Signed-off-by: Anton Vinogradov 

commit bbe9983b2ca7da969f7f3d2008c2a04f698ab223
Author: vozerov-gridgain 
Date:   2016-02-26T11:45:30Z

IGNITE-2715: No more spam from within GridQueryProcessor about missing 
field for BinaryProperty. This closes #514.

commit 7d26ba8f424402e2e7e826c5770ce2273955
Author: vozerov-gridgain 
Date:   2016-02-26T11:19:44Z

IGNITE-2681: Binary serialization warning is no longer printed to the log.

commit 91edd7e04d7e90829d9ad176d1f3b31d7a8ebadf
Author: vozerov-gridgain 
Date:   2016-02-26T11:28:02Z

IGNITE-2681: Binary serialization warning is no longer printed to the log 
(part 2).

commit 77d67892441059bfcf00b66b777ef2cdfddbae43
Author: vozerov-gridgain 
Date:   2016-03-02T11:26:11Z

IGNITE-2681: Suppress warnings from org.jsr166 package as well.

commit 79815b70b5ce4c7441773becae18fbb22782b4a6
Author: Anton Vinogradov 
Date:   2016-03-04T11:17:30Z

IGNITE-2758 IGNITE_HOME/libs/ignite-aws/aws-java-sdk-1.10.29.jar doesn't 
contain any classes

commit 75ed3f0a4245b77e9b0fa252255a9ba1c7cf6241
Author: Alexey Kuznetsov 
Date:   2016-03-09T08:09:18Z

Minor Visor fixes.

commit bbd189cac828b2724eafccc405c453552d3479e4
Author: agura 
Date:   2016-02-28T16:43:58Z

ignite-2719 Value is not copied in entry processor

commit 7c150feed6282e8fd8802f0b066d39eb4cafc677
Author: nikolay_tikhonov 
Date:   2016-03-03T13:21:53Z

Fixed  IGNITE-1186 "Filter is sent instead of factory when continuous query 
is created".
(cherry picked from commit baa1312)

commit a395023046fd86c016a20cc654eeab7162a2ebf6
Author: Valentin Kulichenko 
Date:   2016-03-02T23:39:04Z

IGNITE-2748 - Do not make a remote call when java.lang.Object method is 
called on service proxy

commit 8d976043df92acc3fb036789e7a12919806037ce
Author: Valentin Kulichenko