5.0.0.CR5
by Manik Surtani
Hi guys
What do we have in store for CR5? What's been committed since CR4, and what's in the pipeline for CR5? Does a release on Monday (13th) make sense?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
12 years, 12 months
chunking ability on the JDBC cacheloader
by Sanne Grinovero
As mentioned on the user forum [1], people setting up a JDBC
cacheloader need to be able to define the size of columns to be used.
The Lucene Directory has a feature to autonomously chunk the segment
contents at a configurable specified byte number, and so has the
GridFS; still there are other metadata objects which Lucene currently
doesn't chunk as it's "fairly small" (but undefined and possibly
growing), and in a more general sense anybody using the JDBC
cacheloader would face the same problem: what's the dimension I need
to use ?
While in most cases the maximum size can be estimated, this is still
not good enough, as when you're wrong the byte array might get
truncated, so I think the CacheLoader should take care of this.
what would you think of:
- adding a max_chunk_size option to JdbcStringBasedCacheStoreConfig
and JdbcBinaryCacheStore
- have them store in multiple rows the values which would be bigger
than max_chunk_size
- this will need transactions, which are currently not being used by
the cacheloaders
It looks like to me that only the JDBC cacheloader has these issues,
as the other stores I'm aware of are more "blob oriented". Could it be
worth to build this abstraction in an higher level instead of in the
JDBC cacheloader?
Cheers,
Sanne
[1] - http://community.jboss.org/thread/166760
12 years, 12 months
Transport related configuration timeouts
by Vladimir Blagojevic
While working on ISPN-83 I realized that we have to form equality
relationships between all our transport related timeouts and verify that
the make sense as configuration instance is being processed.
Alphabetically we have the following timeouts in our configuration elements:
<async>: flushLockTimeout, shutdownTimeout
<deadlockDetection>: spinDuration
<hash>: rehashRpcTimeout
<locking>:lockAcquisitionTimeout
<singletonStore>:pushStateTimeout
<stateRetrieval>:logFlushTimeout, timeout, initialRetryWaitTime
<sync>:replTimeout
<transaction>:cacheStopTimeout
<transport>: distributedSyncTimout
My suggestions so far:
flushLockTimeout < shutdownTimeout
spinDuration < lockAcquisitionTimeout < replTimeout < rehashRpcTimeout
replTimeout < distributedSyncTimout < <stateRetrieval>:timeout
Am I overseeing something? Lets hear your thoughts in the area of your
expertize!
Regards,
Vladimir
13 years
Possible Bug in Distribution Manager
by Pedro Ruivo
Hi,
My name is Pedro and I am working in CloudTM project.
I think that I may have encountered a possible bug in the consistent
hash function.
I am working on Infinispan 'Pagoa' 5.0.0-SNAPSHOT with JGroups 3.0.0
Alpha1 and I have a total of 100 000 keys distributed by 11 nodes.
I am using Radargun, that was modified to execute the maximum number of
transactions in a 5 minutes run. All transactions updates at least one
key, ie, I didn't have read-only transactions.
At the end of the test, I am printing all the keys and their location
(keys' owners), and, as you can see for instance here [1], different
nodes have different opinions concerning which replicas are in charge of
storing some keys.
Note that I didn't change anything in the distribution code and my tests
only update keys, never delete them.
Part of the log can be found in [2] and the config file is in [3]. In
the log file we have a lot of 'WARN [DistLockingInterceptor] xxx entry
commit warmup_key(...) => Thread(...)'. Ignore this entries.
Unfortunately, the problem does not always show up, in my tests this
shows up, say, 5% of the times.
Did this ever happen to you, or am I hitting a known issue?
I hope that the information that I am providing can be sufficient to
reproduce the bug, let me know if there is anything else that I can do
to help....
Cheers
Pedro
[1] - http://pastebin.com/Pp47ctj9
[2] - http://pastebin.com/tpSXqVmV
[3] - http://pastebin.com/vjVP48L2
--
INESC-ID Lisboa, sala 511
gsd.inesc-id.pt/~pruivo
13 years
5.0.0.CR4 for 1st June
by Galder Zamarreño
Hi all,
I'm planning to release CR4 next Wednesday, 1st of June, and between now and then I'll be trying to narrow down more testsuite failures and fix the suggestions on the Klockwork report.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years
weekly questions
by Mircea Markus
Hi Jonathan,
We're thinking about doing some significant changes/improvements around transactions[1]. I'd like to pick your brain especially on improvement #1, as this changes the way we acquire locks quite a bit.
With this new locking approach, we don't acquire WL for a transaction until prepare phase. On each write we keep a copy of the written key on the node where transaction is executed so that each subsequent access, in the same transaction, would read/update this copy. Same goes for reads.
When transaction commits we acquire WL during prepare time. This looks to me very similar to the optimistic CC, just that there's no conflict verification before commit.
Also, it seems to preserve repeatable read transaction isolation correctly.
This is a very significant change in our transaction model - do you see any problems/suggestions around it?
Cheers,
Mircea
[1] http://community.jboss.org/wiki/PossibleLockingImprovements
13 years
Failure looking up the river marshaller under AS 7 environment
by "이희승 (Trustin Lee)"
Hi folks,
I'm trying to run Infinispan under AS 7 (i.e. JBoss Modules). I
succeeded to run an EmbeddedCacheManager, HotRodServer, and
MemcachedServer. However, it fails when a new node joins the cluser:
http://pastebin.com/pGfxSWJP
The root cause of the failure is that GenericJBossMarshaller fails to
find the RiverMarshallerFactory. So, I set the TCCL, but it didn't help
at all. Even setting the TCCL to
RiverMarshallerFactory.class.getClassLoader() doesn't seem to help. Any
clues?
Cheers
--
Trustin Lee, http://gleamynode.net/
13 years
