[jboss-user] [JBossWS] - Re: charset encoding problem with the jsr181pojo sample : ec
Who else has encountered this problem? Since it affects all non-ASCII UTF-8 characters, it should be basically everybody who's not using English in their webservice app ... Note my patch for 1.2.1GA (comes with JBoss 4.2.0GA) in the post above. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060526#4060526 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060526 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossWS] - Re: charset encoding problem with the jsr181pojo sample : ec
I've been debugging for hours on this one and eventually tracked the problem down, which I posted on the JIRA: http://jira.jboss.org/jira/browse/JBWS-1716 A workaround UTF-8 fix can be downloaded there for version 1.2.1GA of JBossWS. Setting the system property file.encoding may not work when you have an application which relies on platform-default file encoding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056756#4056756 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056756 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
Sorry for my late reply, been too busy yesterday. anonymous wrote : So I am missing something. You mean to tell me that TreeCache.remove() *fails* if the node does not exist even when you explicitly specify "fail silently"? I needed the "protection check" in OptimisitcTreeCache.remove() because there I cannot explcitly set the fail-silectly mode... Yes, that I is what I mean. Actually, ironically, I didn't pay attention to why you wrote that there, I just read it didn't work well, so I thought you were referring to a known bug and I used the "protected" remove call and it worked. FYI, the stack: System Thread [RMI TCP Connection(9)-192.168.1.72] (Suspended (exception NullPointerException)) OptimisticNodeInterceptor.invoke(MethodCall) line: 68 OptimisticCreateIfNotExistsInterceptor(Interceptor).invoke(MethodCall) line: 68 OptimisticCreateIfNotExistsInterceptor.invoke(MethodCall) line: 69 OptimisticValidatorInterceptor(Interceptor).invoke(MethodCall) line: 68 OptimisticValidatorInterceptor.invoke(MethodCall) line: 75 OptimisticLockingInterceptor(Interceptor).invoke(MethodCall) line: 68 OptimisticLockingInterceptor.invoke(MethodCall) line: 122 TxInterceptor(Interceptor).invoke(MethodCall) line: 68 TxInterceptor.handleNonTxMethod(MethodCall) line: 345 TxInterceptor.invoke(MethodCall) line: 156 CacheMgmtInterceptor(Interceptor).invoke(MethodCall) line: 68 CacheMgmtInterceptor.invoke(MethodCall) line: 183 TreeCache.invokeMethod(MethodCall) line: 5517 TreeCache.remove(Fqn, Object) line: 3741 TreeCache.remove(Fqn, Object, Option) line: 3296 OptimisticTreeCache.writeLoad(Object, Object, Object) line: 77 TransactionalCache.put(Object, Object, long, Object, Comparator, boolean) line: 55 TwoPhaseLoad.initializeEntity(Object, boolean, SessionImplementor, PreLoadEvent, PostLoadEvent) line: 156 CriteriaLoader(Loader).initializeEntitiesAndCollections(List, Object, SessionImplementor, boolean) line: 842 CriteriaLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 717 CriteriaLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 224 CriteriaLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2145 CriteriaLoader(Loader).listUsingQueryCache(SessionImplementor, QueryParameters, Set, Type[]) line: 2061 CriteriaLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 2021 CriteriaLoader.list(SessionImplementor) line: 95 SessionImpl.list(CriteriaImpl) line: 1562 CriteriaImpl.list() line: 283 anonymous wrote : anonymous wrote : Exceptions all over the place Other than whats discussed above? What are they? I was only silently hoping for an exception-free first run with the new OptmisticTreeCache, but then I again got exceptions. Admittedly, it's no big deal, but hence my "oh-no-not-again" feeling and I figured it was time to swap the debugger for a drink ;) Well, you have the exception above, and the CacheException I now get once in a while, as mentioned above. It seems there is a problem with unexpected version increases/checks on the parent nodes, but I still haven't had the time to look into this. I think it must have to do something with the same parent nodes being touched originating from different child accesses; FYI the stack (I replaced package/object names I'm not allowed to disclose): Caused by: org.jboss.cache.CacheException: DataNode [/com/myapp/hibernate] version [EMAIL PROTECTED] [current=16, previous=16, src=SingleTableEntityPersister(com.myapp.hibernate.ObjectB)] is newer than workspace node [EMAIL PROTECTED] [current=1, previous=1, src=SingleTableEntityPersister(com.myapp.hibernate.ObjectA)] at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:127) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:796) at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1061) ... 73 more View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3958008#3958008 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3958008
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
Exceptions all over the place, must be my lucky day!;) (today is the
13th after all...)
Fortunately for one part it seems a simple beauty fixup, I replaced in your
latest OptimisticTreeCache:
| public void writeLoad(Object key, Object value, Object currentVersion) {
| try {
| Option option = new Option();
| option.setFailSilently( true );
| option.setDataVersion( NonLockingDataVersion.INSTANCE );
| cache.remove( new Fqn( regionFqn, key ), "ITEM", option
);
by
| public void writeLoad(Object key, Object value, Object currentVersion) {
| try {
| this.remove(key);
for the same reasons you mention in remove().
The bad part: now I get once in a while get a CacheException thrown where it
shouldn't. At some point, TreeCache seems to detect parent nodes with higher
versions than in the transaction's workspace. I'm still debugging into these.
Oddily enough, my quick 'n dirty fix I posted above didn't do that. I'll post
as soon as I have a result.
As for your comments:
- The insert warning: it no longer occurs since writeLoad() no longer passes in
a previousVersion=null, so now we have the behaviour of the warning which
corresponds to the idea. I got confused by the combination of the bug and the
text of the warning, never mind.
- The query-cache-0.6-second gap and the CMT edge case you suspect: could you
tell where that happens in the code? I'm very interested in looking up these
issues since my app is highly concurrent.
- Weird validated node in next transaction: now that is strange. Could you
perhaps post a code snippet where it occurs? However, I refer to my earlier
post, TreeCache does seem to validate all nodes your transaction has accessed -
modified or not. To me this sounds perfectly okay since you effectively
read/write lock this way using the benefit of version control. Perhaps you're
seeing this?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957698#3957698
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957698
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
Just checked out the latest Hibernate source from
http://anonhibernate.labs.jboss.com/trunk/Hibernate3, but I can't find a method
testNoVersioningProvided() in there ... where should this be included?
Anyway, my guess is still remains: TreeCache doesn't work fine if you mix
non-versioning and versioning calls in the same transaction. So either one
could fix TreeCache such that DefaultDataVersion.ZERO is again correctly
assigned to WorkSpaceNodeImpl when using a non-versioning call, either you pass
in via OptimisticTreeCache a DefaultDataVersion.ZERO, as I tried.
Same way, problem nr 2 can be fixed by adding to writeUpdate() and writeLoad():
if ( source != null ) {
| ...
| } else
| option.setDataVersion(DefaultDataVersion.ZERO);
and modifying :
public boolean newerThan(DataVersion dataVersion) {
|if ( previousVersion == null ) {
| log.warn( "Unexpected optimistic lock check on inserted data" );
| return false;
|}
| ...
Replacing the null parameter in writeLoad to currentVersion may have the same
effect.
But I'm still confused by the warning issued by the code above. Why shouldn't
there be an optimistic lock check on inserted data? Based on what I read in the
TreeCache documentation and from what I saw in the code, everything accessed by
a transaction is put into it's workspace (both read/write, it seems). At commit
time, everything in the workspace is being checked for newer versions against
the cache (see
org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate())
which, as I understand it, boils down to obtaining both optimistic read and
write locks, which is neat and exactly what I want.
Being non-familiar with the JBoss code, I may be totally wrong or looking at
the wrong root cause, but this is the only explanation IMHO I'm able to see.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957298#3957298
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957298
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
More news: It seems it is happening with the query cache enabled, since at the location of the exception the toString() of workspaceNode is: WorkNode fqn=/org/hibernate/cache/StandardQueryCache dirty ver=null When I disable the query cache, I get another similar exception: Caused by: java.lang.NullPointerException at org.hibernate.util.ComparableComparator.compare(ComparableComparator.java:13) at org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter.newerThan(OptimisticTreeCache.java:258) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.simpleValidate(OptimisticValidatorInterceptor.java:124) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.validateNodes(OptimisticValidatorInterceptor.java:101) at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:66) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:95) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:796) at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1061) ... 73 more Now in order to force it to proceed, I tried to patch org.hibernate.util.ComparableComparator.compare() by adding if (x == null) return -1; This seems to make it work, but I get: WARN [OptimisticTreeCache] Unexpected optimistic lock check on inserted data It seems that the core of the problem is that org.hibernate.cache.OptimisticTreeCache$DataVersionAdapter.previousVersion is null in some cases, probably set by org.hibernate.cache.OptimisticTreeCache.writeLoad(), but I have no clue as to why these lock checks occur, or whether these instances with a version or previousversion set to null are ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3956920#3956920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3956920 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
Well, no luck. I replaced OptimisticTreeCache with the latest version from CVS,
which, as I understood from reading HHH-1796 at least, should fix the problem
using a new Fqn.
I've been debugging and browsing code for hours now trying to figure out what
is going on and I think problem is twofold, and both are related. It seems at
some point instances of org.jboss.cache.optimistic.WorkspaceNodeImpl, which by
default appear to have their version set to DefaultDataVersion.ZERO, are
altered via a call setVersion() with null as an argument.
1/ Now the first part of the problem seems exactly what you mention, i.e. "no
way Hibernate would apply a DataVersion to a query cache thus we set null".
But looking at these lines from
org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.createNode():
DataVersion version = null;
| if (ctx.getOptionOverrides() != null &&
ctx.getOptionOverrides().getDataVersion() != null)
| {
| version = ctx.getOptionOverrides().getDataVersion();
| workspace.setVersioningImplicit( false );
| }
it seems the transaction workspace's versioning mode is set to explicit
versioning when we pass in an Option which sets a DataVersion, for example when
calling OptimisticTreeCache.writeLoad(). But then, somewhat further in the same
method, we have:
if (!workspace.isVersioningImplicit())
childWorkspaceNode.setVersion(version);
If now this method gets called again by Hibernate's StandardQueryCache for
example, via OptimisticTreeCache.put(), then the workspace versioningImplicit
still remains false. Since a put call like this one doesn't contain a set
dataversion, the above method call will effectively reset the default
DefaultDataVersion.ZERO of org.jboss.cache.optimistic.WorkspaceNodeImpl to null.
Since I do not have intimate knowledge of the JBoss and Hibernate code, I may
be totally wrong, but adding the line below to OptimisticTreeCache.put() sure
does fix the problem. This might not be the ideal fix since I assumed only
StandardQueryCache directly calls OptimisticTreeCache.put():
option.setDataVersion(DefaultDataVersion.ZERO);
2/ The second part of the problem seems similar, but it appears to be caused by
a call to writeLoad() where source==null. This also ultimately boils down to
passing in an Option with a dataversion null. In the stack this happens when
loading a one to many collection. But I'm still trying to find out what is
happening there.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957096#3957096
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957096
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
I'll dig into this further tomorrow. But just by quickly looking at the test case you mention, and according to what I saw TreeCache doing today, that test may pass since it only seems to deal with non-versioning stuff within a transaction. But that might not be the case when running for real, since you'll have mixed non-versioning (query cache) calls and versioning (regular versioned data cache) calls within the *same transaction*. But as it seems, as pointed out before, TreeCache's transaction workspace is set to explicit user versioning as soon as you pass in a DataVersion via an Option (e.g. using write, writeLoad, ...). Hence subsequent non-versioning calls seem to be ought versioning calls, which, according to what I saw, fails. So your test may fail once you add a regular versioning call in between there. As for your reply to point 2, yes, then that is likely to be the reason, since once source==null, you effectively pass in an Option with dataversion=null (=non-versioning), which fails in the aforementioned situation, i.e. when mixed in the same transaction with a versioning call. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957157#3957157 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957157 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: TreeCache/Hibernate/JBossAS optimistic locking problem
Clarification to my previous post: As for point 2, yes, I confirm, source==null happened in a case where a cached collection was loading (or being put into; don't remember) from its collection cache. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957164#3957164 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957164 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
