You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Jean-Marc Spaggiari <je...@spaggiari.org> on 2013/02/06 15:15:40 UTC
JCS Lateral Cache
Hi,
I have 3 questions about JCS Lateral Cache.
First, here is my usecase.
I have 3 servers running processes to agregate data. They sometime
need to get external information for this agregation, but this
extrenal request is slow. And they might need the same external
information, but not necessary.
The 3 servers are running the same application, and this external
information is already cached localy on each server using JCS.
Now, I would like those servers to share this information, because it
will be way faster for them to share that on a 1GB network than going
outside to get it.
My first question is: Can JCS to that? I think Lateral cache can do
it, but when I use it and I look at the cache statistics, I see only
one lateral with Get Count != 0. all others are 0. So I'm not sure if
it's really use.
My second question is, when I stop one of those servers, the 2 others
are constently showing errors in the logs until I bring the server
back ip. Is there a way to ask JCS to simply drop the socket and just
wait for the discover to add it back if required?
And my last question is, on one server, I have KeyMapSize = 26286. On
another one I have 22031 and on the last one I have 20679. Should they
not all have the same size since each put is supposed to go to the
other servers too?
Thanks,
JM
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: JCS Lateral Cache
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Jean-Marc,
On 25.02.13 04:18, Jean-Marc Spaggiari wrote:
> Regarding DC + LTCP vs LTCP, is that an issue? Becaue if I stop all the
> nodes, I don't want them to have to re-query everything.
No, actually, it should not be an issue. However, if you want to clarify
the behavior of the LTCP cache I'd suggest to first make sure it does
what it should do. Only after you are satisfied with the results,
re-introduce the disk cache.
> If I stop a node, then I restart it, other servers will see that and will
> display the message above. Are they really disabling totally the lateral
> cache because of that? If yes, then it's an issue for my needs.
Normally, JCS constantly tries to "fix" broken caches. So I'd expect the
connection to be re-established. LateralCacheMonitor is responsible for
this. You should see the log outputs of that class later in the log.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: JCS Lateral Cache
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
Hi Thomas,
Thanks for your hints/advices.
I will open a JIRA about the excessive logging.
Regarding DC + LTCP vs LTCP, is that an issue? Becaue if I stop all the
nodes, I don't want them to have to re-query everything.
I will try to modify the AllowGet attribut.
Also, I will add some mecanisme in my application to be able to manually
put some data in the cache, and query the cache too. So that way I will be
able to test and validate that it's well transfered between all the node.
One last think which is worring me is that:
2013-02-24 22:11:57,117 [CacheEventQueue.QProcessor-robotCache] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender - Detected
problem with connection: java.net.SocketException: Relais brisé (pipe)
2013-02-24 22:11:57,123 [CacheEventQueue.QProcessor-robotCache] ERROR
org.apache.jcs.auxiliary.lateral.LateralCache - Disabling lateral cache due
to error Failed to put [value] to robotCache
java.net.SocketException: Relais brisé (pipe)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at
java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
at
java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1857)
at
java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1766)
at
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1273)
at
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1227)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1411)
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
at
java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1557)
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:349)
at
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender.send(LateralTCPSender.java:222)
at
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService.update(LateralTCPService.java:127)
at
org.apache.jcs.auxiliary.lateral.LateralCache.update(LateralCache.java:100)
at
org.apache.jcs.engine.CacheAdaptor.handlePut(CacheAdaptor.java:91)
at
org.apache.jcs.engine.CacheEventQueue$PutEvent.doRun(CacheEventQueue.java:688)
at
org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent.run(CacheEventQueue.java:607)
at
org.apache.jcs.engine.CacheEventQueue$QProcessor.run(CacheEventQueue.java:575)
If I stop a node, then I restart it, other servers will see that and will
display the message above. Are they really disabling totally the lateral
cache because of that? If yes, then it's an issue for my needs.
So I will do more testing and keep you posted.
Thanks,
JM
2013/2/8 Thomas Vandahl <tv...@apache.org>
> On 08.02.13 14:06, Jean-Marc Spaggiari wrote:
> > Thanks for jumping in.
>
> JCS became my playground by accident, after all. :-)
>
> > props.put("jcs.region.robotCache", "DC, LTCP");
>
> I'm not sure if it makes sense to have two auxiliaries for the region.
> I'd try to get the lateral thing working first.
>
> >
> props.put("jcs.auxiliary.LTCP.attributes.AllowGet", "true");
>
> Try to set this to false. The idea is that if some member of the lateral
> cache puts an item, it will be distributed to all the others. So there
> is actually no need to allow gets throughout the group.
>
> > 2013-02-08 07:41:27,243 [CacheEventQueue.QProcessor-robotCache] ERROR
> > org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender -
> ...
>
>
> There is not much we can do about this in 1.3 Would you please open a
> JIRA issue talking about "excessive logging" and I'll try to consider
> this for 2.0. You may try to configure this specific class logger to be
> silent.
>
> > As you can see, the map sizes are very different on the 2 servers when
> > I will have expected hem to be pretty identicals... and it's the same
> > on all the servers. all have different map size.
>
> Your stats look a bit strange to me. However I wouldn't care too much
> for them. Remember that the cache is not guaranteed to be consistent.
> JCS is a cache, not a key-value-store.
>
> > So I'm wondering if the lateral cache is really used. I will say yes
> > because I'm getting the exceptions when one server is going down, but
> > I'm not seeing the benefits yet.
>
> Well, benefits should be there, even if its difficult to see them from
> the statistics. You would be able to see this on an application level,
> that is, if an item available in one cache actually saves the expensive
> get operation from the original source in another. This would need some
> debugging, I'm afraid.
>
> HTH
> Bye, Thomas.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
Re: JCS Lateral Cache
Posted by Thomas Vandahl <tv...@apache.org>.
On 08.02.13 14:06, Jean-Marc Spaggiari wrote:
> Thanks for jumping in.
JCS became my playground by accident, after all. :-)
> props.put("jcs.region.robotCache", "DC, LTCP");
I'm not sure if it makes sense to have two auxiliaries for the region.
I'd try to get the lateral thing working first.
> props.put("jcs.auxiliary.LTCP.attributes.AllowGet", "true");
Try to set this to false. The idea is that if some member of the lateral
cache puts an item, it will be distributed to all the others. So there
is actually no need to allow gets throughout the group.
> 2013-02-08 07:41:27,243 [CacheEventQueue.QProcessor-robotCache] ERROR
> org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender -
...
There is not much we can do about this in 1.3 Would you please open a
JIRA issue talking about "excessive logging" and I'll try to consider
this for 2.0. You may try to configure this specific class logger to be
silent.
> As you can see, the map sizes are very different on the 2 servers when
> I will have expected hem to be pretty identicals... and it's the same
> on all the servers. all have different map size.
Your stats look a bit strange to me. However I wouldn't care too much
for them. Remember that the cache is not guaranteed to be consistent.
JCS is a cache, not a key-value-store.
> So I'm wondering if the lateral cache is really used. I will say yes
> because I'm getting the exceptions when one server is going down, but
> I'm not seeing the benefits yet.
Well, benefits should be there, even if its difficult to see them from
the statistics. You would be able to see this on an application level,
that is, if an item available in one cache actually saves the expensive
get operation from the original source in another. This would need some
debugging, I'm afraid.
HTH
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: JCS Lateral Cache
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
Hi Thomas,
Thanks for jumping in.
Here is how I setup the cache:
Properties props = new Properties();
//# DEFAULT CACHE REGION
//# sets the default aux value for any non configured caches
props.put("jcs.default", "");
props.put("jcs.default.cacheattributes",
"org.apache.jcs.engine.CompositeCacheAttributes");
props.put("jcs.default.cacheattributes.MaxObjects", "10000");
props.put("jcs.default.cacheattributes.MemoryCacheName",
"org.apache.jcs.engine.memory.lru.LRUMemoryCache");
props.put("jcs.default.elementattributes.IsEternal", "false");
props.put("jcs.default.elementattributes.MaxLifeSeconds", "86400");
props.put("jcs.default.elementattributes.IdleTime", "1800");
//# CACHE REGIONS AVAILABLE
//# Regions preconfigured for caching
props.put("jcs.region.robotCache", "DC, LTCP");
props.put("jcs.region.robotCache.cacheattributes",
"org.apache.jcs.engine.CompositeCacheAttributes");
props.put("jcs.region.robotCache.cacheattributes.MaxObjects", "131072");
props.put("jcs.region.robotCache.cacheattributes.MemoryCacheName",
"org.apache.jcs.engine.memory.lru.LRUMemoryCache");
props.put("jcs.region.robotCache.cacheattributes.UseMemoryShrinker", "true");
props.put("jcs.region.robotCache.elementattributes.IsEternal", "false");
props.put("jcs.region.robotCache.elementattributes.MaxLifeSeconds",
"604800");
props.put("jcs.region.robotCache.elementattributes.IdleTime", "1800");
props.put("jcs.region.robotCache.elementattributes.IsSpool", "true");
props.put("jcs.region.robotCache.elementattributes.IsRemote", "false");
props.put("jcs.region.robotCache.elementattributes.IsLateral", "true");
//# AUXILIARY CACHES AVAILABLE
//# Primary Disk Cache -- faster than the rest because of memory key storage
props.put("jcs.auxiliary.DC",
"org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory");
props.put("jcs.auxiliary.DC.attributes",
"org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes");
props.put("jcs.auxiliary.DC.attributes.DiskPath", "robotCache");
props.put("jcs.auxiliary.DC.attributes.MaxPurgatorySize", "131072");
props.put("jcs.auxiliary.DC.attributes.MaxKeySize", "131072");
props.put("jcs.auxiliary.DC.attributes.OptimizeAtRemoveCount", "32768");
props.put("jcs.auxiliary.DC.attributes.MaxRecycleBinSize", "32768");
props.put("jcs.auxiliary.DC.attributes.OptimizeOnShutdown", "true");
props.put("jcs.auxiliary.LTCP",
"org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory");
props.put("jcs.auxiliary.LTCP.attributes",
"org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes");
props.put("jcs.auxiliary.LTCP.attributes.TcpListenerPort", "1110");
props.put("jcs.auxiliary.LTCP.attributes.AllowGet", "true");
props.put("jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr", "224.168.23.0");
props.put("jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort", "6780");
props.put("jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled", "true");
CompositeCacheManager.getUnconfiguredInstance().configure(props);
When I stop one of the servers, I'm getting this on all the others:
2013-02-08 07:41:27,243 [CacheEventQueue.QProcessor-robotCache] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender -
Detected problem with connection: java.net.SocketException: Software
caused connection abort: socket write error
2013-02-08 07:41:27,244 [CacheEventQueue.QProcessor-robotCache] ERROR
org.apache.jcs.auxiliary.lateral.LateralCache - Disabling lateral
cache due to error Failed to put
[E23498752609834581] to robotCache
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1847)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1756)
at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1257)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1211)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1395)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1547)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:333)
at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPSender.send(LateralTCPSender.java:222)
at org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService.update(LateralTCPService.java:127)
at org.apache.jcs.auxiliary.lateral.LateralCache.update(LateralCache.java:100)
at org.apache.jcs.engine.CacheAdaptor.handlePut(CacheAdaptor.java:91)
at org.apache.jcs.engine.CacheEventQueue$PutEvent.doRun(CacheEventQueue.java:688)
at org.apache.jcs.engine.CacheEventQueue$AbstractCacheEvent.run(CacheEventQueue.java:607)
at org.apache.jcs.engine.CacheEventQueue$QProcessor.run(CacheEventQueue.java:575)
2013-02-08 07:41:28,277 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService - Could
not create sender to [192.168.23.4:1110] -- Socket is null, cannot
connect to 192.168.23.4:1110
2013-02-08 07:41:28,277 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager -
Can't fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:41:28,278 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.LateralCacheRestore - Can't fix Can't
fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:41:49,288 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService - Could
not create sender to [192.168.23.4:1110] -- Socket is null, cannot
connect to 192.168.23.4:1110
2013-02-08 07:41:49,288 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager -
Can't fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:41:49,288 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.LateralCacheRestore - Can't fix Can't
fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:42:10,389 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService - Could
not create sender to [192.168.23.4:1110] -- Socket is null, cannot
connect to 192.168.23.4:1110
2013-02-08 07:42:10,390 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager -
Can't fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:42:10,390 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.LateralCacheRestore - Can't fix Can't
fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:42:31,477 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService - Could
not create sender to [192.168.23.4:1110] -- Socket is null, cannot
connect to 192.168.23.4:1110
2013-02-08 07:42:31,477 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheManager -
Can't fix Socket is null, cannot connect to 192.168.23.4:1110
2013-02-08 07:42:31,478 [Thread-11] ERROR
org.apache.jcs.auxiliary.lateral.LateralCacheRestore - Can't fix Can't
fix Socket is null, cannot connect to 192.168.23.4:1110
And the last lines are displayed every 20 seconds... I can adjust the
loglevel to not display that, but if I do so I will miss the other
errors.
Here is the cache stats from one of the servers:
HitCountRam = 76351
HitCountAux = 0
---------------------------LRU Memory Cache
List Size = 15035
Map Size = 15035
Put Count = 16152
Hit Count = 76351
Miss Count = 1674
---------------------------Indexed Disk Cache
Is Alive = true
Key Map Size = 11988
Data File Length = 24953700
Hit Count = 460
Bytes Free = 3434776
Optimize Operation Count = 1313
Times Optimized = 0
Recycle Count = 0
Recycle Bin Size = 1312
Startup Size = 13300
Purgatory Hits = 0
Purgatory Size = 0
Working = true
Alive = false
Empty = true
Size = 0
---------------------------Lateral Cache No Wait Facade
Number of No Waits = 4
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 1214
Remove Count = 460
Put Count = 1606
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 460
Put Count = 1606
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 460
Put Count = 1606
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 287
Put Count = 1374
######################################################
And here is for another one:
HitCountRam = 89305
HitCountAux = 0
---------------------------LRU Memory Cache
List Size = 14203
Map Size = 14203
Put Count = 15110
Hit Count = 89305
Miss Count = 2561
---------------------------Indexed Disk Cache
Is Alive = true
Key Map Size = 20761
Data File Length = 50181144
Hit Count = 1028
Bytes Free = 7610240
Optimize Operation Count = 2075
Times Optimized = 0
Recycle Count = 0
Recycle Bin Size = 2074
Startup Size = 22835
Purgatory Hits = 0
Purgatory Size = 0
Working = true
Alive = false
Empty = true
Size = 0
---------------------------Lateral Cache No Wait Facade
Number of No Waits = 4
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 1533
Remove Count = 1028
Put Count = 2469
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 1028
Put Count = 2469
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 1028
Put Count = 2469
Working = true
Alive = true
Empty = true
Size = 0
Get Count = 0
Remove Count = 1028
Put Count = 2469
As you can see, the map sizes are very different on the 2 servers when
I will have expected hem to be pretty identicals... and it's the same
on all the servers. all have different map size.
So I'm wondering if the lateral cache is really used. I will say yes
because I'm getting the exceptions when one server is going down, but
I'm not seeing the benefits yet.
I'm using JCS 1.3.
Thanks,
JM
PS: If it's not readable, I can paste the logs on PasteBin...
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: JCS Lateral Cache
Posted by Thomas Vandahl <tv...@apache.org>.
On 06.02.13 15:15, Jean-Marc Spaggiari wrote:
> My first question is: Can JCS to that? I think Lateral cache can do
> it, but when I use it and I look at the cache statistics, I see only
> one lateral with Get Count != 0. all others are 0. So I'm not sure if
> it's really use.
Yes, JCS can do that. It would be helpful to see your configuration.
> My second question is, when I stop one of those servers, the 2 others
> are constently showing errors in the logs until I bring the server
> back ip. Is there a way to ask JCS to simply drop the socket and just
> wait for the discover to add it back if required?
I'd recommend to try UDP discovery as described here:
http://commons.apache.org/jcs/LateralUDPDiscovery.html
> And my last question is, on one server, I have KeyMapSize = 26286. On
> another one I have 22031 and on the last one I have 20679. Should they
> not all have the same size since each put is supposed to go to the
> other servers too?
Again, I'd need to see the configuration to answer that.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org