Hi Manik,
I've sent a bunch of logging statements to a file, using log4j and a TRACE
level appender.
This situation is a real problem for my project, thanks a lot for your help! :)
Here they are:
|
|
| 2007-11-02 16:02:43,986 413229 TRACE [org.jboss.cache.ReplicationQueue]
(Timer-7:)
it helps a bit (the CCE happens when replaying transaction modifications on
remote instances during a commit) but the logs aren't very detailed.
Between the
<14:26:47,422> :72,
| /MyApp/Portfolios/Portfolio_cache, item, {BIG_TOSTRING}
|
and
| <14:26:59,971>
| (stack trace)
Ok, I answered my own question from your stack trace that this is on the remote
instance, but still, some more logging would help a bit more.
Thanks
Manik
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101282#4101282
Reply to the post :
http://www.jboss.com
Hello Manik,
Here is what I hope will help you. Since I'm not too knowledgable about
TreeCache's internals, I selected a few logs that I thought were representing
of the situation just before the exception.
| <14:26:40,328> :72>
|
| <14:26:40,328>
|
|
| <14:26:40,328> :
I can't make out too much from the logs you posted. Are you using log4j for
logging? Could you enable DEBUG or TRACE level logging?
Also, is this exception on the instance where you're performing the
transaction, or on one of the remote instances where this is replicated to?
View the original
Hmm, I still don't get this. The OptimisticCreateIfNotExistsInterceptor throws
a CCE attempting to cast the 2nd argument to an Fqn, but the eviction
interceptor before that does manage the cast with no problems.
I just tried to recreate this as well, in a unit test, with no luck. Do you
have
Well I must admin that it's very strange to me, too.
I've seen the line of code that results in the exception, but don't see why my
class is being returned at that point.
I don't have a test case that can recreate this. Actually, I don't have the
slightest idea on how to write a test case that
Thanks for the advice regarding Options.
What I always do is these calls:
final InvocationContext invocationContext = treeCache.getInvocationContext();
| final Option optionOverrides = invocationContext.getOptionOverrides();
I guess that I recieve a new option object each time, or at least one
The other thing that has changed here is that you are now using an Option to
suppress replication (cache mode local). Do you have an updated stack trace
with this? The previous trace showed the CCE on the remote node when the
change is replicated. That won't be the case any more.
View the or
and you get the CCE in both cases?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102517#4102517
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102517
___
jboss-user mailing l
Manik,
The localMode variable is not always set to 'true'.
When I load the cache at startup-time, both members of the cluster fill their
cache based on the data that is in the database. The both fill their cache in
local mode, so that one does not invalidate the other's data.
Once the app is l
I changed a few things and might have moved a bit forward
The ClassCast with my class happened with the put being done this way:
| final InvocationContext invocationContext =
treeCache.getInvocationContext();
| final Option optionOverrides = invocationContext.getOptionOverrides();
| o
Re Options, as a general rule, I recommend not creating and caching the
options. Options are meant for single use only, and should not be reused as I
cannot guarantee that the option is not modified/reset during the course of a
call. If you want to reuse an Option object, make sure you reset()
"spennec" wrote :
| We are heavily using TreeCache on my project, so if I can be of any help to
have this problem solved, I'd be more than happy! :-)
|
What you could do is check out the fix (once I have committed it), build the
cache from srcs and give it a try, see if it solves your prob
Thanks for the tip on this, certainly looks useful.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102758#4102758
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102758
___
jbo
The fix is in subversion (trunk) so go ahead and build/test it, feedback.
In terms of stability, 2.1.0 is in CR1 at the moment so it is pretty close to
GA, which should be in the next couple of weeks. Note that CR1 - released
earlier this week - does not have the fix.
Re: cache listeners, what
Ok this is definitely a bug/limitation in the CacheMarshaller.
See JBCACHE-1211.
Thanks for bringing this up.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102735#4102735
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p
See: http://lucene.apache.org/java/docs/fileformats.html on VInt on saving
space for the ordinary case.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102751#4102751
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=41027
Hi Manik,
The fix was commited quickly, thanks!
Regarding listeners, I am using REPL_ASYNC. What seems strange is that with
Replication on, the data is refreshed twice: with the replication and when the
listener is called. What I want to do is just reload the data when a node is
removed.
I gu
Manik,
Great to see that the reason is now clear! :-)
If I checkout and build TreeCache from the source, will the result be as stable
as the 2.0.0 version that I am using?
Or are you in heavy development and there may be parts of the products that are
"work in progress"? I certainly would like
Manik,
I tried to checkout the source code, based on the page I found
http://docs.jboss.org/process-guide/en/html/svnaccess.html but I cannot connect
to either svn.jboss.org, nor anonsvn.jboss.org. Might be my company's firewall,
or something else, I'm not sure.
Could you build a jar and give
Can't be a f'wall - it's over http!!
Does this link open in a browser?
http://anonsvn.jboss.org/repos/jbosscache/core/trunk
If so, try:
| svn co http://anonsvn.jboss.org/repos/jbosscache/core/trunk
|
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=41028
That was a proxy problem, I am downloading the code right now...
Will keep you informed :)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102922#4102922
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102922
__
Manik,
Wow, there are 58 tests failures... I just can't use this as a production
component...
I'll build it without running the tests just to check that the fix resolved my
problem, and keep you informed.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=410316
Yes, there are failures in trunk at the moment. I'm not suggesting you use a
snapshot build in production. :-)
I just want to make sure the patch solves your specific problem. Naturally,
trunk will be stabilised before releasing.
View the original post :
http://www.jboss.com/index.html?modu
Hi Manik,
Sorry, I just haven't had time today to test the build. I'll test it Monday and
provide you with feedback.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103286#4103286
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mod
26 matches
Mail list logo
