do infinispan configurations need to be synced in cluster ?
by Michal Linhard
Hi all,
Do infinispan configurations have to be synced in cluster members ?
If yes they have to be identical then <goto end>.
If not completely, then what is allowed to be different?
I mean e.g. it probably makes sense to have different LOCAL mode named
caches in every node,
at least I can predict how such configuration would behave.
But it doesn't make sense to have a clustered cache with different
settings on each side.
e.g. on host1 the config would be
<namedCache name="AAA">
<clustering mode="distribution">
</namedCache>
and on host2 it would be:
<namedCache name="AAA">
<clustering mode="replication">
</namedCache>
I am about to play with different configurations during testing and of
course want to try all the weird combinations,
but I'd like to eliminate some of them in advance.
It would be nice to have this documented.
(If it is please point me to the document)
I imagine something like: when in cluster, infinispan configurations
must be kept in sync with these minor exceptions: 1. .... 2. ...
Michal.
--
Michal Linhard
Quality Assurance Engineer
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
15 years, 1 month
Still confused with the merge messages in Infinispan Git repo
by Galder Zamarreño
Hi,
I'm confused by this now. Why did Trustin had to merge my ISPN-774 in master?
https://github.com/infinispan/infinispan/commits/master
Here's what I did:
1. Branch for ISPN-779 of master (last commit=X)
2. Do work, commit (commit=Y).
3. sync + rebase with master (everything looks good)
4. push ISPN-779 with -f
5. Branch for ISPN-774 of master (last commit=X)
// Master here has no ISPN-779 yet - previously, in svn, it would have had but here it does not - is this why the merge has to happen when pulled?
6. Do work, commit (commit=Z)
7. sync + rebase with master (up to date already)
8. push ISPN-774 with -f
This is a very common case where you finish a JIRA and you get on with another one immediately. What is the best practice to keep history linear here? I can't just wait for my pull to be dealt with.
Maybe when I branched for ISPN-774 in master, I should have rebased of master *and* ispn779_master to keep history linear? But if I did so and then I had to change ISPN-779 for whatever reason, wouldn't it get messy?
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 1 month
Why does GlobalComponentRegistry have a shutdown hook?
by Galder Zamarreño
Why does GlobalComponentRegistry have a shutdown hook? It's not runnable on its own, like Infinispan servers are, so I don't see the point of a shutdown hook there. Any cleanup, which should be done within stop() is already called via DCM.stop().
This, together with the changes introduced by https://jira.jboss.org/browse/ISPN-771 are causing issues in standalone environments where other shutdown hooks run, i.e. when you do kill -3 on an Infinispan server
See https://jira.jboss.org/browse/ISPN-779
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 1 month
Configuration hash
by Vladimir Blagojevic
Some Infinispan users are configuring certain nodes with one
configuration and other nodes with another. Should we calculate a
configuration hash and allow cluster joins for nodes that have the same
hash only? Should reduce the noise as the user base continues to expand....
Cheers,
Vladimir
15 years, 1 month
Stashed changes could be dropped when running git sync script
by Galder Zamarreño
Hmmm, I was working on a topic branch for https://jira.jboss.org/browse/ISPN-770 and tried to run https://gist.github.com/667673 but now my local, uncommitted, changes were gone.
Judging from log (see attached), it appears that the stash was popped on 4.0.x branch but after checking out 4.0.x, the changes are not there either.
I've tried to list stashes that were dropped erroneously and I see:
[z@dhcp-144-240:~/Go/code/galder.infinispan.git]% git fsck --unreachable | grep commit | cut -d\ -f3 | xargs git log --merges --no-walk --grep=WIP
commit a45be8ad3c1acbb74e7d66eba1696880c6844bc2
Merge: 03c776a 7e7b664
Author: Galder Zamarreño <galder(a)jboss.org>
Date: Mon Nov 15 10:47:20 2010 +0100
WIP on ispn770_master: 03c776a ISPN-731 - make rehashing state and tx log draining serial addendum to dd3e7e6 commit
Once I had do that, I was able to apply that stash via: git stash apply a45be8ad3c1acbb74e7d66eba1696880c6844bc2
Looking at the script again, it appears that the changes were popped in the pop call within sync(). I think the reason this happened is cos 'git status --porcelain' is not empty for 4.0.x or 4.1.x due to having untracked files (ignores have not been updated there).
So, a way to solve this might be to update ignores in those branches as well. That way we avoid untracked files being mistakenly being detected.
However, this might still break in the future. Another possibility I see would be for the script to safe the git stash ref and to actually pop/apply that stash? That way the pop in sync() would not pop the initial stash, but the stash at the top of sync(). I don't see an easy way to do this though.
Maybe we need a different way to detect whether stashing is needed or not. For example, if only untracked files appear, 'git status --porcelain' is not empty, but 'git stash' won't have anything save. What about using the following?:
git status --porcelain --untracked-files=no
This might work better cos untracked files are not taken into account and hence we'd solve git ignore updates that are not ported over to old branches. I've just run this change locally and it worked fine for me, with my changes being properly stashed and restored.
Manik, thoughts? I've forked your script and applied the change in https://gist.github.com/700256
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 1 month
4.2.x CR1 - when?
by Mircea Markus
Hi*,
The back log for 4.2.x is almost empty now so I'm thinking to release CR1 mid next week - Tue/Wen. How does that sound?
Cheers,
Mircea
15 years, 2 months
