Name ideas for JBCACHE-816?
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/JBCACHE-816
I've started to work on a prototype for this and after having a chat
with Manik last week, we both agreed that it'd be good for whatever
comes out of that JIRA to be a separate module from JBoss Cache Core.
Doing this would allow the module to slowly grow, mature while JBoss
Cache Core follows its own path as stable cache solution.
So, as a result of this, I'm trying to find a name for it. Any ideas?
Here's a couple I thought of but I'm not too conviced about them...:
JBoss Cache Beam
JBoss Cache Duct
Any ideas welcomed :)
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 9 months
Re: [jbosscache-dev] Cache name in LOCAL mode
by Galder Zamarreno
Mircea Markus wrote:
> Galder Zamarreno wrote:
>> Hi,
>>
>> I'm about to fix https://jira.jboss.org/jira/browse/JBCACHE-1465 to
>> make sure we don't encounter Thread name issues when using Cache
>> instances in LOCAL mode but I wanted to raise the following:
>>
>> In clustered mode, cluster name allows for each cache instance to be
>> distinguished individually but when it comes to LOCAL mode, there's
>> not a cache name as such, so if you had N LOCAL caches in a server,
>> how would you differentiate from one another when trying to search for
>> that instance in your JMX console?
>>
>> I think we could do with a cache name in general rather than limiting
>> us to a cluster name which by extension is used as the cache name in a
>> replicated environment.
> I don't see any reason for not having this, just the benefits.
> Another approach would be to add another attribute ("name") under the
> <exposeJmxStats> element, though I personally like Galder's approach more.
Actually, I like your idea more :)
Having a name in <exposeJmxStats> or similar jmx enabling tag probably
makes more sense than having a generic name. The problem about a generic
name is that then you have two names, name and cluster name and I could
see getting confusing for users, i.e., do I need to set a cache name for
a clustered cache? if so, what does it represent, cache name unique in
cluster or the cache name as it's known cluster wide...etc.
Cheersm
>>
>> Thoughts?
>>
>> Cheers,
>
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 9 months
Cache name in LOCAL mode
by Galder Zamarreno
Hi,
I'm about to fix https://jira.jboss.org/jira/browse/JBCACHE-1465 to make
sure we don't encounter Thread name issues when using Cache instances in
LOCAL mode but I wanted to raise the following:
In clustered mode, cluster name allows for each cache instance to be
distinguished individually but when it comes to LOCAL mode, there's not
a cache name as such, so if you had N LOCAL caches in a server, how
would you differentiate from one another when trying to search for that
instance in your JMX console?
I think we could do with a cache name in general rather than limiting us
to a cluster name which by extension is used as the cache name in a
replicated environment.
Thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 9 months
[Fwd: [jboss-dev] Maven and non-existent versions of jboss-cache artifacts]
by Galder Zamarreno
Forwarding to jbosscache-dev(a)lists.jboss.org.
-------- Original Message --------
Subject: [jboss-dev] Maven and non-existent versions of jboss-cache
artifacts
Date: Mon, 12 Jan 2009 05:54:36 -0500 (EST)
From: Juraci Costa <jcosta(a)redhat.com>
Reply-To: JBoss.org development list <jboss-development(a)lists.jboss.org>
To: JBoss.org development list <jboss-development(a)lists.jboss.org>
All,
Is there anything I can read about how we publish artifacts to the main
maven repository and maybe suggest some change to that? I'm asking that
because it is not the first time I see a mismatch between version
numbers in the public maven repository. So, if we follow some guide when
publishing it to the main repository, we need to make certain to not use
SNAPSHOT (which are temporal, AFAIK), and use GA's instead.
Example:
Hibernate tag 3.3.1.GA points to jbosscache-core 2.1.1.GA
https://svn.jboss.org/repos/hibernate/core/tags/hibernate-3.3.1.GA/cache-...
JBoss Cache core 2.1.1.GA says that its parent is
jbosscache-common-parent 1.3-SNAPSHOT
http://repository.jboss.org/maven2/org/jboss/cache/jbosscache-core/2.1.1....
But it doesn't exists. Only 1.3 or 1.4 are available.
http://repository.jboss.org/maven2/org/jboss/cache/jbosscache-common-parent/
To fix a local build, I can change my local jbosscache-core-2.1.1.GA.pom
to point to jbosscache-common-parent 1.3 or 1.4, but we would also need
to change it on our Hudson machines. Although possible, this sounds
wrong, as the builds should be reproducible without manual changes to
the environment :-)
- Juca.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
17 years, 9 months
JBC 3.0.2.CR2 released
by Manik Surtani
This has now been released and is in the Maven2 repo. It will make it
up to SF.net shortly.
Here is what has been included in both 3.0.2.CR1 and 3.0.2.CR2:
** Bug
* [ JBCACHE-1447 ] JDBM cache loader remove of the root
childeren doesn't clear the data
* [ JBCACHE-1450 ] putForExternalRead() doesn't use a 0 lock
acquisition timeout with MVCC
* [ JBCACHE-1452 ] JDBCCacheLoader Doesn't Work With Sybase
* [ JBCACHE-1454 ] Memory leak in CacheStoreInterceptor
* [ JBCACHE-1455 ] Rollback corrupts nodes loaded from cache
loader
* [ JBCACHE-1456 ] The root node starts with "children loaded"
flag
* [ JBCACHE-1457 ] TcpCacheServer: Listening thread should
attempt recovery
* [ JBCACHE-1459 ] FastCopyHashMaps misbehave when serialized
and then deserialized
* [ JBCACHE-1460 ] Inefficient remove() in JDBCCacheLoader
** Patch
* [ JBCACHE-1451 ] Read Time Out for TcpDelegatingCacheLoader
Enjoy!
Manik
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
17 years, 9 months
Non Blocking State Transfer Status (& Integration with JGroups)
by Jason T. Greene
Hi All,
I wanted to summarize my initial research into NBST. The planned design
(outlined in the wiki: http://www.jboss.org/community/docs/DOC-10275)
only needs to block transactional activity once, at the end of the
process when sending the tx log. Unfortunately it appears that flush and
partial flush can not be used for this, since the application needs the
ability to send state (tx log) during the flush. I.e. transactions need
to be paused by only 2 nodes, while the transfer state. This however is
not a big deal because we can just do this in JBoss Cache using a normal
RPC message that flips a gate.
In addition, the state transfer and streaming state transfer facilities
in jgroups can not be used (since they are designed around blocking the
entire group). This means JBoss Cache needs to stream state itself.
Ideally this would be a separate point-to-point connection, since we
don't want to pollute multicast traffic with potentially huge volumes of
noise. Currently jgroups does not yet support a streaming API like this:
https://jira.jboss.org/jira/browse/JGRP-653
IMO This leaves us with 3 options:
1. Wait on JGRP-653 (upping its priority), also add requirements for a
p2p connection.
2. Implement our own p2p connection using tcp (probably using xnio).
3. Somehow enhance state transfer / partial flush to meet our needs
Option 1 seems to be a useful feature for other applications. Although
we need feedback from Bela and Vladimir about that.
Option 2 would give us more flexibility in the implementation, however
care has to be taken to ensure that communication can only happen
between group members (for security reasons), and that the network
address configurations are somehow reused.
Option 3 I am less found of, since we would likely end up adding a bunch
of JBoss Cache specific code to JGroups that no one else would use.
--
Jason T. Greene
JBoss, a division of Red Hat
17 years, 10 months
Array interception bug involving switch statements requiring realignment
by Jason T. Greene
FYI,
A user uncovered a major problem with array interception when an array
operation immediately proceeds a switch statement (often occurs with enums).
This means AS5 http field replication has the same issue. I just
committed a fix to javassist; so, as soon as it and AOP release a new
rev, I will do a minor release of POJO Cache containing the fix.
--
Jason T. Greene
JBoss, a division of Red Hat
17 years, 10 months