[JBoss Cache: Core Edition] - LRUPolicy eviction policy
by lovelyliatroim
Just something i found confusing when reading the documents.
In the documentation it states maxNodes as follows for LRUPolicy
anonymous wrote :
| # maxNodes - This is the maximum number of nodes allowed in this region. 0 denotes no limit.
|
So if i have something like configured
| <region name="evictiontest/LRU" policyClass="org.jboss.cache.eviction.LRUPolicy">
| <attribute name="maxNodes">3</attribute>
| <attribute name="timeToLiveSeconds">0</attribute>
| <attribute name="maxAgeSeconds">10</attribute>
| </region>
|
Now if I add 10 elements like so to the cache
evictiontest/LRU/a/b/c1(1)
evictiontest/LRU/a/b/c2(1)
evictiontest/LRU/a/b/c3(1)
evictiontest/LRU/a/b/c4(1)
etc
After eviction i would have expected to see just one record in the cache
evictiontest/LRU/a/b/c*(1)
however I see 3 records
evictiontest/LRU/a/b/c1(1)
evictiontest/LRU/a/b/c2(1)
evictiontest/LRU/a/b/c3(1)
So when i have set maxNodes to 3, does it actually mean 3 nodes which have a data item attached to the node?? I was thinking it was 3 nodes in total allowed from the region base hence why i thought one record would be allowed.
So breakdown of
evictiontest/LRU/a/b/c1(1)
a = 1 node
b = 2 nodes
c1 = 3 nodes so no more nodes should be allowed in this region!!
I have done the test on it and looks to me like its based on nodes with data attached, could someone just confirm this for me on how it works.
Thanks,
LL
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184848#4184848
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184848
17 years, 6 months
[Remoting] - Re: NPE from one way message dispatch
by adinn
Hi Ron.
I reran the app using your patched remoting build and it fixes the problem as I diagnosed it but this has raised some related issues with JBossWS which I need to check with Alessio Soldano.
The problem occurs when I use WS-Addressing to redirect a fault. This is appropriate with either a one way message or a request reply exchange. In either of these cases when a fault occurs the invoker ends up with a null input stream.
For one way messages WS employs (defaults to) an HTTPUnmarshaller which barfs on a null input stream. Your fix resolves this by not calling the unmarshaller.
For request-reply messages WS sets a SOAP HTTP Unmarshaller. This detects a null input stream and constructs an empty SOAP message. So, in this case your fix causes a problem for WS. SInce the unmarshaller no longer gets called the invoker returns null instead of an empty message. The current WS code does nto expect a null pointer here and falls over when it tries to run SOAP handlers.
Clearly there is a problem with WS here whichever way you look at it. Having looked at how the client ends up calling the HTTP invoker I suspect WS needs the unmarshaller to be called in both cases even when the stream is null i.e. we may need to back out this fix. Ho wsensible this is as regards any other remoting clients I am not in a position to say. Perhaps you could comment?
I'll point Alessio at this discussion to see what he says. Sorry, for the previous misdiagnosis -- it was hard to see the wood for the trees without the patch.
regards,
Andrew Dinn
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184841#4184841
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184841
17 years, 6 months