Also, I'm presuming neither of you see this problem when there is only one node
in the cluster?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935466#3935466
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3935466
Please check out the just released 1.3. The eviction policy has been
refactored. So you should be able to create more of your customed policy.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935417#3935417
Reply to the post :
http://www.jboss.com/index.html?m
Hi there
I haven't seen this with other transaction managers before.
Perhaps you don't have the same tx manager? When obtaining your tx manager in
your test code, try doing:
| TransactionManager txmgr = cache.getTransactionManager();
| txmgr.begin()
|
View the original post :
(sorry, that last one was in response to the original post)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935361#3935361
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3935361
-
Hi there,
I made some deeper explorations and found following:
When commit() is called in application,
OrderedSynchronizationHandler.beforeCompletion() is called. It then calls
beforeCompletion() for registered Synchronizations, in my case only
TxInterceptor.LocalSynchronizationHandler. Still ev
This isn't the issue TreeCacheMarshaller fixes; that's deserializing state
received from another node. Here you're trying to serialize your own state.
As you mentioned, the class it can't find is in jboss-minimal.jar.
I haven't played enough with JBC in WebLogic to be much help; here's a wiki
You need to
- add pbcast.STATE_TRANSFER to the top and
- enable automatic fetching of state after reconnect:
Channel.setOpt(Channel.AUTO_GETSTATE, Boolean.TRUE)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935165#3935165
Reply to the post :
http://www.jbos
Sorry, misread... you're using Websphere, not WebLogic. So even my wiki link
is no use :(
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935159#3935159
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3935159
-
Do you mean their state does synchronize after the merge? This is the
responsibility of the application (JGroups has no way of knowing what the state
is, whether it should be merged, or how to merge it). If you implement the
JGroups MembershipListener interface you can be notified of changes i
Hi,
Yes this is a drop in replacement. You should be able to use your old config
file, but to use the new features you probably want a new config file anyway.
Also, if you use cache loaders, you should refer to
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheCacheLoaders
Cheers,
Manik
Vie
Well, it seems I have the same problem. I am running on WebSphere and got the
same exception in
org.jboss.cache.interceptors.TxInterceptor.handleCommitRollback() method.
| The following exception was logged java.lang.IllegalStateException: local
transaction [EMAIL PROTECTED] transaction does
OK, but strange is, that I got this error even if cache is empty.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3935017#3935017
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3935017
--
This is the classical classloader problem. In startup, replicated object class
must be in the classpath of the application(or server) or you can register
classloader with related object class using marshaller. See documentation about
using the Marshaller.
View the original post :
http://www.jb
Thanks Manik. I'm glad to hear it :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934663#3934663
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934663
---
This SF
Yes it has - see the announcement at the top of the forum list for details.
Cheers,
Manik
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934642#3934642
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934642
Congrats, you may well be our first production user of 1.3.0 "Wasabi"! :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934659#3934659
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934659
---
Thanks Guys!
The new release certainly has improved performance in our testing so far. Just
got to go through a complete test before going into production.
cheers, and thanks again,
Paul
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934652#3934652
Reply
Hello,
as suggested , we tested with the Jboss 1.2.4 but havent achieved any
improvement result on it.
No drop of CPU utilization.
specification : jdk 1.4, sun solaris E-270 server with Quadra system.
Jboss 3.2.5, Jboss-cache.jar version 1.2.4
We even tested with SleepyC
I should wait and let Manik post the official announcement in the European AM,
but anyway ...
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=102339&release_id=406920
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934528#3934528
Reply
Hi there
Yeah thats pretty much what it is used for. If you set this option the
replication interceptor will be bypassed. Everything else will function the
same.
Cheers,
Manik
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934413#3934413
Reply to the pos
This has been fixed in JBossCache 1.3.0 GA release. See JBCACHE-523 for
further details.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934072#3934072
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934072
--
This has been fixed in JBossCache 1.3.0 GA release. See JBCACHE-523 for
further details.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934071#3934071
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3934071
--
This is exactly what JSR 171 (IIRC) does: Java Content Repository. An
implementation could be based on JBossCache. What they essentially do for
versioning is to create another subtree for the same data with a version
number++. Reverting back to an old version simply entails setting the view to
Nice stuff. Not to be pessimistic though, true CMS functionality cannot be
achieved without being able to version the data, roll back to specific
versions, etc.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3934017#3934017
Reply to the post :
http://www.
"akardell" wrote :
| In addition, it appears as though using the INVALIDATION_ASYNC actually
causes all other nodes' caches to be emptied (invalidated) when one node's
cache is written to with a put.
|
Surely not the entire cache? E.g., if cache1 does a put on /a/b/c, other
caches will o
The rollback exception you see is caused by
| Caused by: org.jboss.cache.CacheException: unable to validate nodes
| at
org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInt
| erceptor.java:109)
|
which is the result of 2 or more threads at
"akardell" wrote :
| 1) Is it okay to use optimistic node locking with REPLICATION_ASYNC, or is
optimistic node locking only meant for use with INVALIDATION_ASYNC?
|
You can use optimistic locking regardless of cache mode
(LOCAL/REPL_SYNC/REPL_ASYNC/INVALIDATION_SYNC/INVALIDATION_ASYNC)
"
Have a look at this:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=80239
Looks like your issue is the same as mentioned in the above post.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3933916#3933916
Reply to the post :
http://www.jboss.com/inde
Well, good / bad news here...
The good news is that by upgrading to Hibernate 3.2 CR 1 and using the
OptimisticTreeCacheProvider instead of the default TreeCacheProvider, we were
able to get past the basic issue of puts not taking effect in the cache (which
was the root of issue #2 described be
Thanks for pointing this out. I've opened a JIRA; this will be fixed for
1.3.0.GA. See http://jira.jboss.com/jira/browse/JBCACHE-523.
For a workaround, add
false
to your config file. That will prevent registration of the MBeans (at the cost
of them not being visible via JMX).
Re: the depe
I just noticed that this default logging behaviour is filling up my disk
too..to switch the log level to more sensible 'INFO' or 'WARN', edit your
log4j.xml found in server conf directory and add the following category.
|
|
|
in Limit Categories section...
HTH.
View the
Just as a waning: if you try implementing locking per FQN, you will end up
creating a tree-like structure again ! IMO we should better implement this in
the cache itself, and use multiple root for example to bypass this problem.
Or - if you absolutely have to do it - extract this functionality in
Just as well you didn't write the test case while *you* were driving. :)
The test case is fine so far, but if you would like to contribute further for
more performance benchmarking and some of the major improvements I have planned
for the 1.4.0 timeframe, do let me know - I could always use an
Manik,
Thanks for you reply, glad the test case helped (I wrote in the car on the way
home! :) - my wife was driving..)
I'll grab CVS Head and check out the changes. At this stage, _any_ efficiency
gains in the 1.3.0 release would be most sincerely appreciated.
If it helps, I could help wrlte
Hi, thanks for your test case. It proves this inefficiency quite well.
I'm working on a proper fix involving locking on a per-fqn level based on
method and isolation level, but for now I have a fix in CVS which does improve
efficiency considerably but is not the final fix. If this "halfway fix
What JBossCache version? A number of CPU utilization improvements went into
1.2.4 (use 1.2.4.SP2).
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3933383#3933383
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3933383
Actually, this is all encapsulated in:
http://jira.jboss.com/jira/browse/JBCACHE-513
See my test case attached to that issue.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3933295#3933295
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=post
Hi Manik,
We are using Hibernate 3.0.5. The load test isn't specific to JBossCache -- it
is a full load test of our application; we aren't going out of our way to
create transactions on the same object to induce concurrency, but it probably
happens as a 'side effect' of our test.
As best as w
Another option is to use jboss-cache.jar under jboss as 3.2.6. It runs under
JDK1.3 but the corresponding release is probably JBossCache1.1 though.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3933123#3933123
Reply to the post :
http://www.jboss.com/index.h
While we're looking into this, a good workaround is to *not* create/remove
nodes *directly* under root, because in this case we only need to acquire a
read-lock for root, e.g.
/a/b/c, /x/y/z, but *not* /a, /b or /c
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic
I got it! The problem is related to the Fqn that I was using. Unlike my
previous post, I was using:
Fqn fqn1 = new Fqn(new Object[] {"/", "cluster", "object1"});
| Fqn fqn2 = new Fqn(new Object[] {"/", "cluster", "object2"});
The extra "/" character caused a problem when the cache were trying
Yep. I don't know what is disabled on my company controlled laptop (damn
network nazis), but I took it to a network which I control and got it to work.
Thanks,
Michael
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932833#3932833
Reply to the post :
http://
Difficult to say. But I have one almost identical test case under:
tests/functional/org/jboss/cache/aop/ReplicatedObjectGraphAopTest.testCicurlarReference1
Can you try it out?
Or if you can turn your test case in a junit test to run under JBossCache and
still be able to repruce it, I then take
I jsut checked. It works in my setup. What I suspect is your mcast is not
working properly and therefore the group is not forming proeprly (and therefore
no replication).
Please make sure it works first, say, by going thru the cache example. Or this:
http://wiki.jboss.org/wiki/Wiki.jsp?page=Test
That was the problem. My cache usage was set to "read-write", not
"transactional"
Thank you greatly for your help!!!
Brian
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932510#3932510
Reply to the post :
http://www.jboss.com/index.html?module=bb&op
And what abt your hbm.xml file? Basically, do you set you rcache mode to
transactional?
See
http://www.hibernate.org/hib_docs/v3/reference/en/html/performance.html#performance-cache-transactional
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932471#3932471
Here is my hibernate.cfg.xml
|
| http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";>
|
|
|
| oracle.jdbc.driver.OracleDriver
| jdbc:oracle:thin:@db:1521:DB
| user
| pw
| 1
|
| thread
|
|
what does your hibernate config look like?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932468#3932468
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3932468
---
Th
sorry...
treecache.xml
|
|
|
|
|
|
| jboss:service=Naming
| jboss:service=TransactionManager
|
| org.jboss.cache.GenericTransactionManagerLookup
| REPEATABLE_READ
| REPL_ASYNC
| true
| 0
|
Here is the treecache.xml again
-
jboss:service=Naming
jboss:service=TransactionManager
org.jboss.cache.GenericTransactionManagerLookup
REPEATABLE_READ
REPL_ASYNC
true
0
0
tr
Aaron, this problem seems to be something specific with when used with
Hibernate. WHich version of Hibernate is this tested against?
Also, what do you do in your load test? Do you start transactions on the same
objects to induce concurrency?
Cheers,
Manik
View the original post :
http://www
Optimistic locking will always bypass these locking issues - because the very
concept of o/l is that node data is copied, rather than locked, for each
transaction. The OOME errors are probably due to the extra memory requirements
of o/l (additional memory space to copy node data, etc.)
View th
I tried increasing the timeout from 15000 to 15. Similar results.
However, I noticed that there's a new option with 1.3, in addition to the new
INVALIDATION_ASYNC option...
| OPTIMISTIC
|
Setting this caused all of the lock exceptions to go away!
I'm now getting OutOfMemory
anonymous wrote : the method is named tearDown() I misspelled it in my post :-)
| So this is not the problem..
In my code it has the correct name:
tearDown()
So the method-name is not the problem...
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932123#39321
tieDown()? Surely you mean tearDown()? If you name the method 'tieDown()' it
won't get called. :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932120#3932120
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3932120
the method is named tearDown() I misspelled it in my post :-)
So this is not the problem..
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3932078#3932078
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3932078
--
anonymous wrote : and stop the service with a stopService()-call in tieDown().
I hope this is a typo. If not, then the method name should be:
public void tearDown()
If the method name does not match tearDown() then the call to stopService will
never be invoked and as a result, the TreeCache ser
Thank you Brian. I think that answered my questions. I may have mroe detailed
questions later, but will probably do them in another thread in such case.
Cheers
- Lars
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931917#3931917
Reply to the post :
http://w
Whenever an attempt is made to retrieve a node from the cache, the cache is
traversed from the root node (has a special Fqn of "/").
There is a single instance of the root node within the cache, which like all
nodes, keeps a reference to its children in a hash map that supports concurrent
reads
Thank you for your quick reply. It was my impression though that the "root node
contention" was an issue whther you had multiple roots in a tree or not. Or am
I missing something?
Just for safety, let me expand a bit: onsider three domain which are keeping
state in the cache as "/a", "/b" and "
There have been a number of changes made since my post that dramatically
improve scalability and performance of JBossCache, and a few of those
optimizations alleviate some of root node contention.
However, the fundamental problem that is described in this thread still exists.
The right approach
Hello,
I'm presently evaluating JBoss Cache for a large system state replication
mechanism. However, we're looking at a cache where certain sub-trees may change
frequently wheras others may stay fairly static for a long time but may mutate
rapidly in certain periods. As such, this problem seeme
lock acquisition timeout
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931722#3931722
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3931722
---
This SF.Net email is
Perhaps I'm missing a setting? None of my timeouts are set to 0, as seen below.
I can re-run a test, but which timeouts should I increase?
Thanks!
Aaron
|
|
|
|
|
|
|
| jboss:service=Naming
| jboss:service=TransactionManager
|
|
|
|
Perhaps I'm missing a setting? None of my timeouts are set to 0, as seen below:
|
|
|
|
|
|
|
| jboss:service=Naming
| jboss:service=TransactionManager
|
|
|
| org.jboss.cache.DummyTransactionManagerLookup
|
|
| READ_COM
Does this change if you have a really high timeout? Threads will block for
longer (as expected), but I'd like to see if this affects anything - since the
log message says timeout after o secs.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931668#3931668
Under a substantial amount of load, it was not uncommon to get
TimeoutException's and IdentityLock's in 1.2.4.SP2 with REPL_ASYNC
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931654#3931654
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=p
Hi there - do you still see this when using JBossCache 1.2.4.SP2 with
REPL_ASYNC?
And no, you don't need to upgrade your Hibernate jars as long as you're using
Hibernate >= 3.0.2.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931640#3931640
Reply to th
Wow, I found Option parameter in put method now. When I set cacheModeLocal to
true, is seems that I get the desired behavior! Object is stored to memory and
leaves other cluster members untouched. Cool. Is this correct usage? Does it
have any side-effects I should know about?
I think you JbossC
"[EMAIL PROTECTED]" wrote : 1. In general, TreeCacheAop only has advantage is
your pojo has long life time. So most of the time I think issuing removeObject
explicitly is not a problem. But yeah, I agree that it is still an issue. I
just didn't have good solution. But there is a plan to refactor
Thanks!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931502#3931502
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3931502
---
This SF.Net email is sponsored by xPM
Yes, yes, and yes. :-) The best way to do it is to look at the example that
bundles in 1.2.4 release. it has both annotation and xml examples there.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931474#3931474
Reply to the post :
http://www.jboss.com/index.
1. In general, TreeCacheAop only has advantage is your pojo has long life time.
So most of the time I think issuing removeObject explicitly is not a problem.
But yeah, I agree that it is still an issue. I just didn't have good solution.
But there is a plan to refactor it in 2.0 due in 4-5 months
OK.It seems replication of the UserSessionObject wasnt happening in the first
place..When the put was done only once in the hashmap,that was the only time
the object was replicated.After that it was just modification to the
POJO(UserSessionObject).
So the question is, do I need to Instrument the
hi Manik,
Again sorry to distrub you.
(1)public void put(Fqn fqn,
java.util.Map data)
throws CacheException
(2)public java.lang.Object put(java.lang.String fqn,
java.lang.Object key,
java.lang.Object value)
hi manik,
thanks for ur reply.
now i have got the answer.
regards,
Biswajit.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931358#3931358
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3931358
--
>From the codebase:
| public Object get(String fqn, Object key) throws CacheException
| {
| return get(Fqn.fromString(fqn), key);
| }
|
Hope that answers your question. :-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3931352#3931352
Repl
Hi Brian,
Just find the two methods
(1)public java.lang.Object get(java.lang.String fqn,
java.lang.Object key)
throws CacheException
(2)public java.lang.Object get(Fqn fqn,
java.lang.Object key)
thr
I am not aware of any other implication since my dev enviornment has been all
jdk1.5. Since we have 1.3beta release now, I'd suggest you test it out yourself
since we have couple bug fixes for Pojocache (the new name for TreeCacheAop now
:-)
-Ben
View the original post :
http://www.jboss.com/
Hi,
Have you tried this with the current 1.3.0.Beta2 release?
Cheers,
Manik
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930969#3930969
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3930969
---
First, for general JBossCache docs, be sure you are familiar with
http://docs.jboss.com/jbcache/1.2.4sp2/TreeCache/en/html/
OK, what I'm going to describe now is a cache that is deployed as part of a
webapp. All the servers in the cluster that deploy the webapp will also deploy
the cache, an
Hi Biswajit,
Sounds like your cache's can't communicate properly. Here are a couple links
to help you debug why not:
http://wiki.jboss.org/wiki/Wiki.jsp?page=TestingJBoss
http://www.jgroups.org/javagroupsnew/docs/newuser/node15.html
View the original post :
http://www.jboss.com/index.html?mo
Hi,
In my case i am not able to retrieve the cached entries from the 2nd node if
the 1st node goes down.
Could you pliz suggest me a solution for this.
Regards,
Biswajit.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930668#3930668
Reply to the post :
ht
So your cache should be replicated and if the first server node goes down, the
application should still be able to retrieve cached entries from the cache
instance on the second node.
If the cache isn't replicated successfully, then it's likely that your nodes
aren't communicating properly. You
Hi
In my treecache-service.xml i have made cache mode as,
REPL_ASYNC
Waiting for your response.
Thanks in advance.
Biswajit..
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930656#3930656
Reply to the post :
http://www.jboss.com/index.html?module=bb&
Where is your cache configuration? Did you specify CacheMode as REPL_SYNC or
REPL_ASYNC? This is necessary to indicate that you want a replicated cache.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930653#3930653
Reply to the post :
http://www.jboss.com/
Daniel, that was that did it. :-) I ahve done it in two branches. In Head, it
has been refactored into BaseEvictionAlgorithm now. So no need to change it
there.
-Ben
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930589#3930589
Reply to the post :
http://w
Hi,
At least just tell me the proper configuration for the below mentioned
ClusterConfig part(which is a part of treecache-service.xml).
I am using 2 nodes for my clustering.
Thanks in advance.
Regards,
Biswajit.
View the original post :
http://www.jboss.com/index
Bela, I would like to follow up. I notice in FishEye that you changed the log
statement in BaseEvictionAlgorithm.java from warn to debug but as far as I can
tell you did not change it in LRUAlgorithm.java. Did you perhaps forget about
it? I just want to make sure it wasn't missed, as this is
sorry i did not get.
pliz give me a proper solution
Biswajit
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930353#3930353
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3930353
--
just listening.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930351#3930351
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3930351
---
This SF.Net email is sponsore
thank you for the fast response,
the solution with additiolnal arraylist is enough for me now
90% operations concern fast lookup and the rest - listing all elements in right
order
have a nice day
regards
tom
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=
LinkedHashMap is currently not supported. I added LinkedHashMap to Jira issue
http://jira.jboss.com/jira/browse/JBCACHE-166. You can vote for this Jira
issue if you think its important.
We currently support the following implementations:
HashMap - This is the only only offering hashed key lo
Hi Nick.
There hasn't been much interest in such a feature
(http://jira.jboss.com/jira/browse/JBCACHE-311), and as such, I'm not very keen
on increasing prio on this one. It would be a ncie to have, but at the moment
a lot of the internal code relies on JGroups. The channel is one example, bu
Makes sense..Thanks!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929692#3929692
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929692
---
This SF.Net email is spo
No it is not a simple wrapper. The reason that it is not is because all the
Collection data (e.g., in Map case, the key, value paris). So all these
get/remove/iterator need to operate on the cache store data (instead of just
in-memory data). This is how TreeCacheAop (or PojoCache as we call it n
Aren't the Collection Proxies simple wrappers over the actual collection,just
the way EJBObjects are one layer over the actual beans?
Is there any reason why you need to create your own datastructures?
How do you compare the performance of your data structures over java's data
structures?
View t
I reposted this on the JBossing Messaging area as this occurs when I post a
message to a quote remotely.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929366#3929366
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=39293
We are having this problem too. this is occurring on Windows 2003, but does
not occur on XP.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929359#3929359
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929359
-
I've created a JIRA for it..Could you assign to yourself.
http://jira.jboss.com/jira/browse/JBCACHE-498
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929340#3929340
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929340
301 - 400 of 1896 matches
Mail list logo
