You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by yucigou <yu...@gmail.com> on 2016/08/05 16:03:20 UTC

Cannot get cache through the REST API

I want to see the list of entries cached, so I'm trying the following REST
API. But it does not return anything.

http://ves-hx-40.ebi.ac.uk:8080/ignite?cmd=getorcreate&cacheName=session-cache

The response:

    {
        "error": "",
        "response": null,
        "sessionToken": "",
        "successStatus": 0
    }

Wonder if this is normal? Or is there any other way/tool to get the list of
cached entries as an administrator?

(I'm using Ignite 1.6.0, session-cache here is the cache to cluster web
sessions in my case.)



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by yucigou <yu...@gmail.com>.
Hi Val,

Thanks for the reply. But I found all cache related APIs (e.g., commands
getall, get) require a key parameter. The issue is how I would be able to
find out the keys in the first place? Is there any API that can list all the
keys of a particular cache?

By the way, I guess session IDs may be used as the keys, and so I tried
using a session ID as the key for command getall:

http://ves-hx-40.ebi.ac.uk:8574/ignite?cmd=getall&k1=C1B286441778888A7917C8841204F2D2&cacheName=session-cache

I got the response, but no value was returned:

{
  "affinityNodeId": "",
  "error": "",
  "response": {
    "C1B286441778888A7917C8841204F2D2": {}
  },
  "sessionToken": "",
  "successStatus": 0
}

Any comments please?

Cheers,
Yuci



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6874.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by vkulichenko <va...@gmail.com>.
Yuci,

All the setting provided in documentation are based on testing of
high-loaded applications. Small young size makes for on-heap caches where
most of the objects are long living.

However, there is no silver bullet and each use case can require its own
tuning.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p7157.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by yucigou <yu...@gmail.com>.
Hi Alexey,

As I wrote in another thread, you would be able to see the CPU and heap
activities there captured in JVisualVM:

http://apache-ignite-users.70518.x6.nabble.com/Puzzled-about-JVM-configuration-td7091.html

The cause of it is the JVM configuration:

-XX:NewSize=128m 
-XX:MaxNewSize=128m 
-XX:MaxTenuringThreshold=0 
-XX:SurvivorRatio=1024 

Two reasons:

(1) Small young gen space size 
(2) Tiny survivor space with max tenuring threshold set to zero (which means
no aging) 

As a result, a lot of minor GCs and also a large number of short-lifespan
objects are promoted to old gen unnecessarily.



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p7140.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by Alexey Kuznetsov <ak...@gridgain.com>.
Hi Yuci!

Could you please give more info about "Web Console monitoring
places too much overhead to the application, the CPU and memory wise
according to JVisualVM statistics" ?

Also, about "Wonder if there is any available tool like this?"

GridGain provide "In-Memory Computing Platform Built on Apache Ignite" and
it has Visor GUI - a monitoring tool.
See:
  http://www.gridgain.com/resources/download (30 days trial is available)
  and https://gridgain.readme.io/docs/visor-gui for more info about Visor
GUI.

Hope this help.


On Thu, Aug 11, 2016 at 6:15 PM, yucigou <yu...@gmail.com> wrote:

> Hi Val,
>
> As for the REST API, I don't have a particular favouritism towards it. I
> started to look at it because the Ignite Web Console agent uses it to
> collect statistics. It looks to me that the Ignite Web Console monitoring
> places too much overhead to the application, the CPU and memory wise
> according to JVisualVM statistics.
>
> Thanks for the suggestion. Yes, it is a good idea to create a client node
> for the management. Wonder if there is any available tool like this? I
> think
> this is a common use case, similar to what the Ignite Web Console
> monitoring
> does over the REST API.
>
> Thanks,
> Yuci
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6965.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Cannot get cache through the REST API

Posted by yucigou <yu...@gmail.com>.
Hi Val,

As for the REST API, I don't have a particular favouritism towards it. I
started to look at it because the Ignite Web Console agent uses it to
collect statistics. It looks to me that the Ignite Web Console monitoring
places too much overhead to the application, the CPU and memory wise
according to JVisualVM statistics.

Thanks for the suggestion. Yes, it is a good idea to create a client node
for the management. Wonder if there is any available tool like this? I think
this is a common use case, similar to what the Ignite Web Console monitoring
does over the REST API.

Thanks,
Yuci



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6965.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by vkulichenko <va...@gmail.com>.
Hi Yuci,

Any particular reason to use REST API? Maybe it's better to create an
application which will start a client node and implement all this management
functionality? It will be much easier this way, because you will have access
to all Ignite APIs. E.g., you will be able to iterate through all the
entries in cache and process accordingly.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6930.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by yucigou <yu...@gmail.com>.
Hi Val,

Our application has got a number of caches, one of which is for web session
clustering.

The reason I'm trying to get cached entries via the REST API, is that I
would like to find/purge/etc what is cached during the time of the
troubleshooting/debugging/etc. It is not essential in our business logic,
but would be very nice to have such kind of insight.

Cheers,
Yuci



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6923.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by vkulichenko <va...@gmail.com>.
Hi Yuci,

What's your use case? Trying to get data directly from cache when you're
using web session clustering sounds weird to me. What's the reason for that?

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6890.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by yucigou <yu...@gmail.com>.
Hi Saikat,

Thanks for your kind input. But there is no luck yet. I guess that in order
to runs sql fields query over cache, you need to make fields visible for sql
queries first. But in my case, the session objects are not annotated with
@QuerySqlField

Furthermore, I got the following error message:

{
  "error": "Indexing is disabled for cache: session-cache. Use
setIndexedTypes or setTypeMetadata methods on CacheConfiguration to
enable.",
  "response": null,
  "sessionToken": "",
  "successStatus": 1
}

Also not very sure of how setIndexedTypes works for Ignite web session
clustering.

Cheers,
Yuci



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6875.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Cannot get cache through the REST API

Posted by Saikat Maitra <sa...@gmail.com>.
Hi

If you know the type name you can use sql query field command.

For example :
http://ves-hx-40.ebi.ac.uk:8080
<http://ves-hx-40.ebi.ac.uk:8080/ignite?cmd=getorcreate&cacheName=session-cache>
/ignite?cmd=qryfldexe&pageSize=10&cacheName=session-cache
<http://ves-hx-40.ebi.ac.uk:8080/ignite?cmd=getorcreate&cacheName=session-cache>
&qry=select+*+from+<*session_object*>

exmaple 2 :
http://localhost:8080/ignite?cmd=qryfldexe&pageSize=10&cacheName=CacheQueryExamplePersons&qry=select+*+from+Person


This will return list of entries in the cache in items object inside json
response.

Regards
Saikat









On Sat, Aug 6, 2016 at 9:34 AM, vkulichenko <va...@gmail.com>
wrote:

> Hi,
>
> This commands only creates the cache and does not respond with any data.
> Refer to the whole list of available commands here:
> https://apacheignite.readme.io/docs/rest-api
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6820.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Cannot get cache through the REST API

Posted by vkulichenko <va...@gmail.com>.
Hi,

This commands only creates the cache and does not respond with any data.
Refer to the whole list of available commands here:
https://apacheignite.readme.io/docs/rest-api

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Cannot-get-cache-through-the-REST-API-tp6806p6820.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.