Menu
▾
▴
jboss-dev-forums
|
From: <man...@jb...> - 2006-06-11 21:53:40
|
"gal...@jb..." wrote : - Configuration changes will need to be backported to 1.2.x using the old | CacheLoader configuration style (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheCacheLoaders ) Is this necessary? The SingletonCacheLoader won't be available till JBC 2.x.x anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950327#3950327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950327 |
|
From: <man...@jb...> - 2006-06-11 21:55:22
|
Just so we don't destabilise the 1.4.0 release, I'd hold back on any implementations of this until I branch 1.4.0 (probably over the next few days, once I release .CR1). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950328#3950328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950328 |
|
From: <gal...@jb...> - 2006-06-11 22:00:15
|
"man...@jb..." wrote : "gal...@jb..." wrote : - Configuration changes will need to be backported to 1.2.x using the old | | CacheLoader configuration style (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheCacheLoaders ) | | Is this necessary? The SingletonCacheLoader won't be available till JBC 2.x.x anyway. As the affected versions included 1.2.x, I thought we might wanna back port it . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950330#3950330 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950330 |
|
From: <gal...@jb...> - 2006-06-11 22:00:53
|
"man...@jb..." wrote : Just so we don't destabilise the 1.4.0 release, I'd hold back on any implementations of this until I branch 1.4.0 (probably over the next few days, once I release .CR1). | no probs, I'm just starting to have a look to it :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950331#3950331 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950331 |
|
From: <man...@jb...> - 2006-06-11 22:13:52
|
-1 on backporting. People can upgrade if they need it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950332#3950332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950332 |
|
From: <gal...@jb...> - 2006-06-11 22:18:01
|
that's alright with me, it was just a misunderstanding View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950333#3950333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950333 |
|
From: <be...@jb...> - 2006-06-19 12:08:36
|
+1 from me. I guess this needs to be done on the 1.4 branch *and* 2.0 (CVS head) ? Also +1 on the name change to SingletonCacheLoader View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951633#3951633 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951633 |
|
From: <man...@jb...> - 2006-06-20 13:18:07
|
Just in HEAD (for 2.0.0). This is not targetted for the 1.4.0 release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951977#3951977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951977 |
|
From: <gal...@jb...> - 2006-06-22 17:24:20
|
I had a bit more look to this and I have this questions:
* Looking at SharedStoreCacheLoader, it seems like it's the cache loader itself that, given a org.jgroups.View and an org.jgroups.Address, decides whether that Address is the coordinator of the View. I don't think it should change now, but don't you think this operation should live in JGroups rather than in JBossCache? JGroups knows these two and I think it should be responsible of being able to determine whether an Address is the coordinator of a View:
Code in SharedStoreCacheLoader:
public void viewChange(View new_view) {
| boolean tmp=active;
| if(new_view != null && local_addr != null) {
| Vector mbrs=new_view.getMembers();
| if(mbrs != null && mbrs.size() > 0 && local_addr.equals(mbrs.firstElement())) {
| tmp=true;
| }
| else {
| tmp=false;
| }
| }
| if(active != tmp) {
| active=tmp;
| log.info("changed mode: active=" + active);
| }
| }
* Configuration wise, I had this two ideas, but I'm not sure which one is preferred, or if there's any other:
<singleton>true</singleton>
| <singleton>false</singleton> (default)
<singleton pushStateWhenCoordinator="true">true</singleton> (pushStateWhenCoordinator defaults to true)
| <singleton pushStateWhenCoordinator="false">true</singleton>
OR:
<singleton />
<singleton>
| <pushStateWhenCoordinator>true</pushStateWhenCoordinator>
| </singleton>
| <singleton>
| <pushStateWhenCoordinator>false</pushStateWhenCoordinator>
| </singleton>
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952752#3952752
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952752
|
|
From: <gal...@jb...> - 2006-06-22 17:25:19
|
"this questions" "this two ideas" I think i might need some spelling lessons! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952753#3952753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952753 |
|
From: <gal...@jb...> - 2006-06-22 17:26:50
|
Configuration wise, personally, I think pushStateWhenCoordinator should be an attribute of the singleton element. Opinions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952755#3952755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952755 |
|
From: <be...@jb...> - 2006-06-23 11:55:38
|
I think this should be done in JBossCache, you have a list of addresses, the coordinator is always the first member... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952960#3952960 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952960 |
|
From: <gal...@jb...> - 2006-06-23 13:34:14
|
I guess it'd be easier to do View.getVid().getCoordAddress()? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952983#3952983 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952983 |
|
From: <gal...@jb...> - 2006-06-25 14:24:56
|
I've been a bit productive this weekend and implemented the configuration side and unit tested the SingletonCacheLoader using a DummyCacheLoader as the delegated cache loader. The original code seems to working fine :-). Configuration wise, I've gone for the element/attribute pattern. In terms of validation, singleton should not be used neither with shared nor with evictions as it would not make sense at all. Therefore, I have added validations to check this on startup. Now, in order to get the pushStateWhenCoordinator feature done, the only method that I can use seems to be: TreeCache._getState(Fqn fqn, boolean fetchTransientState, boolean fetchPersistentState, long timeout, boolean force, boolean suppressErrors) fetchTransientState would be true and fetchPesistentState false, however, I am not sure what timeout should I use. Should I used a hardcoded value or should I add to the configuration? Also, I guess force should be hardcoded to false. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953279#3953279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953279 |
|
From: <bst...@jb...> - 2006-06-26 16:59:19
|
I'm confused about what pushStateWhenCoordinator does -- doesn't it mean taking all in-memory state and doing a write-through to the cache loader? _getState doesn't provide that kind of behavior. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953495#3953495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953495 |
|
From: <gal...@jb...> - 2006-06-26 17:29:51
|
Basically, when a node which has control over the singleton cache loader dies or leaves the cluster, another node needs to take the responsability for updating this cache loader. Now, this cache loader could be in a different machine or there could be updates in between the old node crashing and the new node taking over the role of the coordinator. pushStateWhenCoordinator makes the new coordinator dump the entire in-memory state into the cache store so that it contains a true reflection of what's in memory. Looking at the code, it seems like _getState can actually return all the in-memory state. The cache loader would then call storeEntireState(byte[] state) on the underlying cache loader. However, I'm not sure whether about _getState and some of the parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953502#3953502 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953502 |
|
From: <bst...@jb...> - 2006-06-26 19:15:19
|
No, this won't work. The byte[] returned by _getState() is made up of subsidiary byte[]s for the in-memory state and the persistent state. The _setState method is responsible for parsing these out and doing the appropriate stuff with each, including passing the *persistent* state to the cache loader. But CacheLoader.storeEntireState() only knows how to handle the persistent state. Actually, as I wrote this I realized that for 1.2.4 I did work to make the data format of the in-memory transfer and the persistent transfer consistent. So *maybe* it will work -- you parse out the the in-memory state and pass it to the cache loader. This is bad though -- the fact that the data structure of the persistent state and the in-memory state is the same is 1) not part of any interface contract, and therefore 2) if true for the cache loaders we ship with, it's only because *we* wrote them that way. Other custom implementations may be different. Re: the timeout and force parameters. I've no opinion on whether the timeout should be configurable, or whether you should just use StateTransferTimeout. The combination of "timeout" and "force" was meant to allow the calling code to loop with a successively longer timeout; on the final iteration of the loop, "force" would be set to true, and at that point _getState would force the breakage of any locks in order to ensure the transfer goes through. Perhaps you should follow a similar approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953532#3953532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953532 |
|
From: <gal...@jb...> - 2006-06-27 18:25:16
|
Or alternatively, avoid byte[] states and use navigation methods that would not trigger the cache loader. However, this is likely to be slower. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953799#3953799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953799 |
|
From: <gal...@jb...> - 2006-06-27 18:50:06
|
Brian, is there anything you would suggest then? I can't see an easy solution to the problem you are stating. I will need to look at the exact details of those methods to see what I can do. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953797#3953797 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953797 |
|
From: <bst...@jb...> - 2006-06-28 05:21:03
|
Well, one thought is that going to 2.0 gives us the freedom to specify in the CacheLoader contract what the format of the data passed to storeEntireState has to be. So, we theoretically could take the in-memory state and pass it to storeEntireState. But we'd all have to think very long and very hard about doing that, as we'd have to live by the contract as much as anyone. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953870#3953870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953870 |
|
From: <gal...@jb...> - 2006-07-02 17:55:55
|
Brian, you're right. Looking at the code in _setState, it seems like that: - The persistent state actually comes from calling CacheLoader.loadEntireState() or CacheLoader.loadState(). So the origing of the persistent state is the CacheLoader. - The transient(in-memory) state comes from marshalling the transient state (or marshall the associated state for PojoCache) generated inside the StateTransferGenerators. Therefore, we can control the in-memory state but we are can't really control the persistent state (with the current rules). In my opinion, rather than making both states consistent, the CacheLoader should be able to generate a persistent state given the in-memory state. However, in order for this to work, the structure of the in-memory state would need to be made public so that potential CacheLoader implementors could transform it into the persistent state that we're after. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954901#3954901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954901 |
|
From: <man...@jb...> - 2006-07-03 09:26:35
|
Hmm, that would involve rewriting the current set of cache loaders. I'm concerned about feasibility wrt. timescales here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954998#3954998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954998 |
|
From: <gal...@jb...> - 2006-07-03 12:22:56
|
That is indeed true. However, let's say the method looked something like this: | public byte[] createPersistentState(byte[] inMemoryState, FQN root) | The current CacheLoaders would just need to return the result of loadState(root) or loadEntireState() depending on the number of elements in the root node. The main problem I see is that even if you only wanted to generate the persistent state, you'd require to parse the in-memory state as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955026#3955026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955026 |
|
From: <gal...@jb...> - 2006-07-03 12:46:24
|
If we wanna add a new method to CacheLoader, this is going to be the last chance before 3.x I guess? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3955028#3955028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3955028 |
Thanks for helping keep SourceForge clean.
X