Near Cache Support For Thin Clients

classic Classic list List threaded Threaded
10 messages Options
martybjones@gmail.com martybjones@gmail.com
Reply | Threaded
Open this post in threaded view
|

Near Cache Support For Thin Clients

I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
martybjones@gmail.com martybjones@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Alex Plehanov Alex Plehanov
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Alex,

I've recently implemented .NET Native Near Cache [1].
It is a very similar concept, because caching is performed on platform side.

We had requests for this from different users for quite some time.
Users were implementing this on their own with Continuous Queries.
Yes, it is not transactional, but it still provides a huge speedup in many cases.

Thin Client Near Cache can be based on the same mechanism.
Yes, it is not a trivial feature, but neither is Partition Awareness, for example.
Performance is a feature.


On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <[hidden email]> wrote:
Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
martybjones@gmail.com martybjones@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Honestly near cache for the thin client is a must for me.  Implementing this is a huge performance gain.

On Thu, May 21, 2020 at 5:47 AM Pavel Tupitsyn <[hidden email]> wrote:
Alex,

I've recently implemented .NET Native Near Cache [1].
It is a very similar concept, because caching is performed on platform side.

We had requests for this from different users for quite some time.
Users were implementing this on their own with Continuous Queries.
Yes, it is not transactional, but it still provides a huge speedup in many cases.

Thin Client Near Cache can be based on the same mechanism.
Yes, it is not a trivial feature, but neither is Partition Awareness, for example.
Performance is a feature.


On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <[hidden email]> wrote:
Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
martybjones@gmail.com martybjones@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Has there been a request for event listeners for the thin clients?  I am happy to roll my own implementation of the nearcache if I can get the events of when cache items within the cluster are added, modified, or deleted.

On Thu, May 21, 2020 at 2:29 PM Marty Jones <[hidden email]> wrote:
Honestly near cache for the thin client is a must for me.  Implementing this is a huge performance gain.

On Thu, May 21, 2020 at 5:47 AM Pavel Tupitsyn <[hidden email]> wrote:
Alex,

I've recently implemented .NET Native Near Cache [1].
It is a very similar concept, because caching is performed on platform side.

We had requests for this from different users for quite some time.
Users were implementing this on their own with Continuous Queries.
Yes, it is not transactional, but it still provides a huge speedup in many cases.

Thin Client Near Cache can be based on the same mechanism.
Yes, it is not a trivial feature, but neither is Partition Awareness, for example.
Performance is a feature.


On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <[hidden email]> wrote:
Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

Marty,

Continuous queries are certainly planned for thin clients,
and that is the best way to get cache update notifications.

On Fri, May 22, 2020 at 8:32 PM Marty Jones <[hidden email]> wrote:
Has there been a request for event listeners for the thin clients?  I am happy to roll my own implementation of the nearcache if I can get the events of when cache items within the cluster are added, modified, or deleted.

On Thu, May 21, 2020 at 2:29 PM Marty Jones <[hidden email]> wrote:
Honestly near cache for the thin client is a must for me.  Implementing this is a huge performance gain.

On Thu, May 21, 2020 at 5:47 AM Pavel Tupitsyn <[hidden email]> wrote:
Alex,

I've recently implemented .NET Native Near Cache [1].
It is a very similar concept, because caching is performed on platform side.

We had requests for this from different users for quite some time.
Users were implementing this on their own with Continuous Queries.
Yes, it is not transactional, but it still provides a huge speedup in many cases.

Thin Client Near Cache can be based on the same mechanism.
Yes, it is not a trivial feature, but neither is Partition Awareness, for example.
Performance is a feature.


On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <[hidden email]> wrote:
Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Igor Sapego-1 Igor Sapego-1
Reply | Threaded
Open this post in threaded view
|

Re: Near Cache Support For Thin Clients

I personally think that this feature should be implemented in Ignite,
though maybe we should first start from Continuous Queries for thin
clients.
 
Best Regards,
Igor


On Mon, May 25, 2020 at 6:15 PM Pavel Tupitsyn <[hidden email]> wrote:
Marty,

Continuous queries are certainly planned for thin clients,
and that is the best way to get cache update notifications.

On Fri, May 22, 2020 at 8:32 PM Marty Jones <[hidden email]> wrote:
Has there been a request for event listeners for the thin clients?  I am happy to roll my own implementation of the nearcache if I can get the events of when cache items within the cluster are added, modified, or deleted.

On Thu, May 21, 2020 at 2:29 PM Marty Jones <[hidden email]> wrote:
Honestly near cache for the thin client is a must for me.  Implementing this is a huge performance gain.

On Thu, May 21, 2020 at 5:47 AM Pavel Tupitsyn <[hidden email]> wrote:
Alex,

I've recently implemented .NET Native Near Cache [1].
It is a very similar concept, because caching is performed on platform side.

We had requests for this from different users for quite some time.
Users were implementing this on their own with Continuous Queries.
Yes, it is not transactional, but it still provides a huge speedup in many cases.

Thin Client Near Cache can be based on the same mechanism.
Yes, it is not a trivial feature, but neither is Partition Awareness, for example.
Performance is a feature.


On Thu, May 21, 2020 at 11:35 AM Alex Plehanov <[hidden email]> wrote:
Hello,

I don't think that near cache for thin client on Ignite level it's a good idea. 

Expiration is not the only case here. For thick clients near caches are transactionally consistent. For thin clients such a guarantee never can be provided.
Near cache for thin clients will be either too heavy (and this contradicts thin clients paradigm) or highly specialized (in this case it's better to implement it on user level). 

Also, sometimes many thin clients are used inside one application (inside one JVM for java thin client). I know deployments where thin client pool approach or client per thread approach is used. In these cases, it's better to have one near cache for all clients than have it inside each client.

I think it's better to provide mechanisms like event listeners or continuous queries to make it possible to implement near caches on user level with guarantees that best fit user's requirements.

вт, 19 мая 2020 г. в 15:47, Pavel Tupitsyn <[hidden email]>:
Ok, thanks for the explanation.
Yes, this is a good feature, and I've had this in mind for some time.

There are no immediate plans, but I think there is a possibility to achieve this by the end of the year.

On Tue, May 19, 2020 at 2:52 PM Marty Jones <[hidden email]> wrote:
The use case is having a local cache that stores most widely used cache items in memory on server instead of having the network expense of pulling them down every time they are requested.  The main thing is the near cache has to support removing cache items that have expired on the server.

The best use case I have is a web application that needs a cache item per request.  we would not want to pull the cache item from the cluster every request.   It would be way more efficient for the thin client to have a near cache that would hold "hot" cache items that are requested frequently.

On Tue, May 19, 2020 at 3:43 AM Pavel Tupitsyn <[hidden email]> wrote:
Can you please describe the use case in more detail?
What do you expect from such a feature?

On Tue, May 19, 2020 at 2:01 AM [hidden email] <[hidden email]> wrote:
I wanted to see if there are any plans to support near caches for thin clients? I think it would be a great feature. I know I could use it right now.

Sent from the Apache Ignite Users mailing list archive at Nabble.com.