October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBSEAM-405) timeZone/timeZoneSelector

by Gavin King (JIRA)

timeZone/timeZoneSelector ------------------------- Key: JBSEAM-405 URL: http://jira.jboss.com/jira/browse/JBSEAM-405 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Gavin King Assigned To: Gavin King Priority: Minor Fix For: 1.1 Analogous to Locale and Theme handling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-786) errors from "OK" putFailFast replications

by Owen Taylor (JIRA)

errors from "OK" putFailFast replications ----------------------------------------- Key: JBCACHE-786 URL: http://jira.jboss.com/jira/browse/JBCACHE-786 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Owen Taylor Assigned To: Manik Surtani Priority: Optional Attachments: jbosscache-failfast-replicate-failure.patch [ Although putFailFast() is deprecated, it is still used by current versions of Hibernate ] With putFailFast(), you fairly frequently see the following situation: - a call to putFailFast() succeeds - the (asynchronous) replication fails due to a lock timeout, and throws an exception t that is thrown is logged at level ERROR (Much more frequently because of JBCACHE-785, but it is a legitimate situation that doesn't indicate an error.) This patch simply detects that case and suppresses the warning. (You might be able to it more elegantly by bridging putFailFast() onto the options framework, but to get the exact existing behavior of putFailFast() would take a fairly extensive patch.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-785) InvocationContext and suspended transactions

by Owen Taylor (JIRA)

InvocationContext and suspended transactions -------------------------------------------- Key: JBCACHE-785 URL: http://jira.jboss.com/jira/browse/JBCACHE-785 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: Owen Taylor Assigned To: Manik Surtani The attached test case demonstrates that if you: A) Make calls to the tree cache B) suspend the current transaction C) Make more calls to the tree cache The locks created at step C) are sometimes attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed. It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-761) Make connecting the channel and state transfer an atomic part of startup

by Brian Stansberry (JIRA)

Make connecting the channel and state transfer an atomic part of startup ------------------------------------------------------------------------ Key: JBCACHE-761 URL: http://jira.jboss.com/jira/browse/JBCACHE-761 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Manik Surtani If an exception is thrown during initial state transfer, the channel should be disconnected. The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state. But the current code leaves the channel connected, leaving a "zombie" member of the group. Probably need to alter stopService() as well to ensure it can handle an already disconnected channel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBPM-583) add jms support for the messaging service

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-583?page=all ] Tom Baeyens updated JBPM-583: ----------------------------- Fix Version/s: jBPM 3.1.4 jBPM 3.2 (was: jBPM 3.2 alpha 2) (was: jBPM 3.1.3) Description: postponed. work is in progress on HEAD. but as long as it is not stable there, it is not ported to 3.1 branch. > add jms support for the messaging service > ----------------------------------------- > > Key: JBPM-583 > URL: http://jira.jboss.com/jira/browse/JBPM-583 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Jim Rigsbee > Priority: Critical > Fix For: jBPM 3.1.4, jBPM 3.2 > > > postponed. work is in progress on HEAD. but as long as it is not stable there, it is not ported to 3.1 branch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-717) cascade persistence operations from timer to action

by Alejandro Guizar (JIRA)

cascade persistence operations from timer to action --------------------------------------------------- Key: JBPM-717 URL: http://jira.jboss.com/jira/browse/JBPM-717 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Alejandro Guizar Assigned To: Tom Baeyens Fix For: jBPM 3.1.3 when creating timers from user code, the action object is not saved with the timer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-724) Add more non-String objects to testsuite Fqns

by Brian Stansberry (JIRA)

Add more non-String objects to testsuite Fqns --------------------------------------------- Key: JBCACHE-724 URL: http://jira.jboss.com/jira/browse/JBCACHE-724 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Priority: Minor Almost all of the fqn's used in the testsuite are composed solely of String elements. We should look for and identify places to include non-String elements in order to help prevent issues like JBCACHE-703. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-745) nodeEvicted being called for nodes that don't actuall get evicted

by gregorypierce (JIRA)

nodeEvicted being called for nodes that don't actuall get evicted ----------------------------------------------------------------- Key: JBCACHE-745 URL: http://jira.jboss.com/jira/browse/JBCACHE-745 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.0.SP1 Reporter: gregorypierce Assigned To: Manik Surtani Attachments: CacheEviction.java Working on class example from training materials CacheEviction.java. Will receive a nodeEvicted call that the root node has been evicted, but if you look at the console itself and print the tree - the root node doesn't get evicted. Should not call nodeEvicted with a node that hasn't actually already been evicted from the tree. Looks like it realizes that the node is a parent node and decides against evicting it after the interface call. // FIXME We extend AbstractTreeCacheListener, which provides a default implementation // of the TreeCacheListener interface. You just need to override methods to write to // the console for cache events in which you are interested. Do something like this: public void nodeCreated(Fqn fqn) { System.out.println("nodeCreated(): fqn: " +fqn); } public void nodeEvicted(Fqn fqn) { System.out.println("nodeEvicted(): fqn: " +fqn); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

3
3
0 / 0

[JBoss JIRA] Updated: (JBCACHE-629) SELECT FOR UPDATE semantics

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-629?page=all ] Manik Surtani updated JBCACHE-629: ---------------------------------- Fix Version/s: 3.x > SELECT FOR UPDATE semantics > --------------------------- > > Key: JBCACHE-629 > URL: http://jira.jboss.com/jira/browse/JBCACHE-629 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Assigned To: Manik Surtani > Fix For: 3.x > > > An API with semantics similar to a database SELECT FOR UPDATE would be useful -- e.g. getForUpdate(...) which acts like a get, but acquires a WL instead of a RL. > Example situation: > IsolationLevel is READ_COMMITTED > - Two threads A and B. > 1. Thread A starts a new Transaction. > 2. Thread A calls get(Fqn for x, key for x) > 3. Thread A modifies Object x (e.g x.setFoo("bar")). > 4. Thread B calls get(Fqn for x, key for Object x) > 5. Thread B calls x.getFoo() > 6. Thread A calls put(Fqn for x, key for x, x); > 7. Thread A rolls back the Transaction. > Problem is in Step 5 Thread B sees uncommitted data, because the WL on the cache node is not acquired until Step 6. Only way to control this is for Thread A to synchronize on x and write x in such a way that access to all properties like Foo are synchronized. > With getForUpdate, A would acquire the WL in step 1, thus blocking B from reading until the A's TX commits. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-618) Cache loader failed committing transaction

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-618?page=all ] Manik Surtani closed JBCACHE-618. --------------------------------- Resolution: Done > Cache loader failed committing transaction > ------------------------------------------ > > Key: JBCACHE-618 > URL: http://jira.jboss.com/jira/browse/JBCACHE-618 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss Cache distributed with JBoss AS 3.2.7 (final) > Reporter: Martin Jachs > Assigned To: Manik Surtani > Attachments: jboss.bug.cacheloader.zip > > > The following exception occured as the FileCacheLoader did not get prepared by the CacheStoreInterceptor. This is the case if no cache modifications have been made within the current transaction. > 14:21:44,785 [RMI TCP Connection(6)-172.27.17.130] ERROR org.jboss.cache.interceptors.CacheStoreInterceptor : failed committing transaction to cache loader > java.lang.Exception: transaction <null>:2 not found in transaction table > at org.jboss.cache.loader.FileCacheLoader.commit(FileCacheLoader.java:195) > at org.jboss.cache.interceptors.CacheStoreInterceptor$SynchronizationHandler.afterCompletion(CacheStoreInterceptor.java:251) > at org.jboss.tm.TransactionImpl.doAfterCompletion(TransactionImpl.java:1398) > at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:421) > at org.jboss.ejb.plugins.TransactionInterceptor.endTransaction(TransactionInterceptor.java:520) > at org.jboss.ejb.plugins.TransactionInterceptor._endTransaction(TransactionInterceptor.java:487) > at org.jboss.ejb.plugins.TransactionInterceptor.runWithTransactions(TransactionInterceptor.java:350) > at org.jboss.ejb.plugins.TransactionInterceptor.invoke(TransactionInterceptor.java:171) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) > at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) > at at.co.systema.gf.aop.jboss.ServerInvoker.invoke(ServerInvoker.java:104) > at at.co.systema.gf.aop.jboss.ServerInvoker.invoke(ServerInvoker.java:24) > at at.co.systema.gf.aop.jboss.AbstractServerInvocation.invoke(AbstractServerInvocation.java:187) > at at.co.systema.gf.rt.aop.ThreadContextInterceptor.internalInvoke(ThreadContextInterceptor.java:103) > at at.co.systema.gf.aop.AbstractInterceptor.invoke(AbstractInterceptor.java:176) > at at.co.systema.gf.aop.jboss.AbstractServerInvocation.invoke(AbstractServerInvocation.java:173) > at at.co.systema.gf.aop.jboss.ServerContainer.invoke(ServerContainer.java:260) > at at.co.systema.gf.aop.jboss.AbstractEJBInterceptor.invoke(AbstractEJBInterceptor.java:129) > at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:331) > at org.jboss.ejb.Container.invoke(Container.java:709) > at sun.reflect.GeneratedMethodAccessor86.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:82) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473) > at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:360) > at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) > at sun.rmi.transport.Transport$1.run(Transport.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:149) > at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006