[JBoss JIRA] Updated: (JBAS-2071) Need a mechanism to retrieve FamilyClusterInfo in a consistent/synchronized way
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2071?page=all ]
Dimitris Andreadis updated JBAS-2071:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Brian, unless you can work on this, I'm deferring the issue.
> Need a mechanism to retrieve FamilyClusterInfo in a consistent/synchronized way
> -------------------------------------------------------------------------------
>
> Key: JBAS-2071
> URL: http://jira.jboss.com/jira/browse/JBAS-2071
> Project: JBoss Application Server
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.3RC1
> Reporter: Adrian Brock
> Assigned To: Brian Stansberry
> Fix For: JBossAS-4.0.6.CR1
>
>
> The retrieveal of the FamilyClusterInfo information is not done a consistent way.
> e.g. the targets and view id could be retrieved across a view change
> public void JRMPInvokerProxyHA::writeExternal(final ObjectOutput out)
> throws IOException
> {
> ArrayList targets = this.familyClusterInfo.getTargets();
> --> View change here
> long vid = this.familyClusterInfo.getCurrentViewId ();
> targets.trimToSize();
> out.writeObject(targets);
> out.writeObject(this.loadBalancePolicy);
> out.writeObject (this.proxyFamilyName);
> out.writeLong (vid);
--
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, 10 months
[JBoss JIRA] Updated: (JBAS-3316) outdated log4j.jar causes UndeclaredThrowableException
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3316?page=all ]
Dimitris Andreadis updated JBAS-3316:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Not likely to upgrade log4j for 4.0.5
> outdated log4j.jar causes UndeclaredThrowableException
> ------------------------------------------------------
>
> Key: JBAS-3316
> URL: http://jira.jboss.com/jira/browse/JBAS-3316
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Affects Versions: JBossAS-4.0.4.GA
> Environment: java version 1.5.0_06 macosx
> Reporter: afm
> Assigned To: Scott M Stark
> Fix For: JBossAS-4.0.6.CR1
>
>
> The log(String callerFQCN, Priority level, Object message, Throwable t) method of org.apache.log4j.Logger
> in the log4j.jar distributed with JBoss throws a NullPointerException if called with t = null. This then
> causes an InvocationTargetException on line 288 of org/apache/commons/logging/impl/Log4jProxy.java,
> leading to an UndeclaredThrowableException on line 296. The problem is that very often the method is
> called with t = null, e.g. on line 235, in the debug method. This then causes some servlets not to work
> (Google finds a few instances of this).
> The cause is a rather outdated log4j.jar. Replacing log4j.jar by a more recent version seems to
> fix this problem
--
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, 10 months
[JBoss JIRA] Updated: (JBAS-2923) Making JCA security more pluggable
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2923?page=all ]
Dimitris Andreadis updated JBAS-2923:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
To the next release.
> Making JCA security more pluggable
> ----------------------------------
>
> Key: JBAS-2923
> URL: http://jira.jboss.com/jira/browse/JBAS-2923
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JCA service
> Reporter: Adrian Brock
> Fix For: JBossAS-4.0.6.CR1
>
>
> We need a mechanism to make JCA security more pluggable.
> This is to cater for use cases where some extra context needs to be used.
> The connection manager only understands a subject.
> The connection factory (e.g. DataSource) only understands the CRI (method parameters).
> The pooling uses both without needing to understand what they are in detail.
> This change would provide a "wrapper" connection manager that can do things
> more associated to context, e.g. it could be connection factory specific,
> i.e. it understands the CRI and can do things that the connection factory doesn't do
> or it can do things based on information.
> An example of other information would allowing a per deployment
> security domain such that you have different pre-configured user/password per ejb.
> With something like the following in META-INF/jboss-[web].xml
> <jboss>
> <enterprise-beans>
> <session>
> <ejb-name>Whatever</ejb-name>
> ...
> <resource-ref>
> <res-ref-name>jdbc/DataSource</res-ref-name>
> <jndi-name>java:/MySQLDS</jndi-name>
> <security-domain>FooBar</security-domain>
> </resource-ref>
> </session>
> </enterprise-beans>
> </jboss>
--
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, 10 months
[JBoss JIRA] Updated: (JBAS-2939) Make Invocation policies more configurable
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-2939?page=all ]
Dimitris Andreadis updated JBAS-2939:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
to the next release
> Make Invocation policies more configurable
> ------------------------------------------
>
> Key: JBAS-2939
> URL: http://jira.jboss.com/jira/browse/JBAS-2939
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Remoting
> Reporter: Adrian Brock
> Fix For: JBossAS-4.0.6.CR1
>
>
> Since JBAS-1442 it has been possible to change the invocation policies
> like local invocation optimizations.
> This is handled by subclassing the org.jboss.invocation.InvokerInterceptor
> The only one that is direclty supported by simple configuration is whether
> marshalling of invocations should take place.
> This feature request is to deal with the more common polices
> like turning off the local optimization when you want to force load
> balancing to an SLSB even though it is availabe locally.
--
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, 10 months
[JBoss JIRA] Commented: (HIBERNATE-41) Usage of load() in PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock
by Steve Ebersole (JIRA)
[ http://jira.jboss.com/jira/browse/HIBERNATE-41?page=comments#action_12340088 ]
Steve Ebersole commented on HIBERNATE-41:
-----------------------------------------
(1) Hibernate (unfortunately from my POV) does not require a user to demarcate transactions at all (auto-commit behavior). So if we do not put into the L2 cache immediately when exactly is it that we are guarenteed to be able to later? Also there is the question of at the "later point" how will we know which entities and collections to write into the L2 cache? Iterate all entries in the persistence context? That's a *lot* if unecessary overhead...
(2) This is a general problem (IMHO) with all cache implementations. They assume they are the "truth of the system". At least from the perspective of a Hibernate L2 cache (and many other applications of caching) this is simply not true. The database is the ultimate truth of the system. Why is this problematic? Well consider that there are two vastly different ways in which Hibernate might be putting data into the L2 cache:
(a) in response to newly created data (i.e. an insert or the like);
(b) data loaded from the database because it was not present (for whatever reason) in the L2 cache.
In case (b), why apply a write lock at all? How does that make sense?
(3) Again, why is this particular scenario acquiring a write lock at all? And in the case of what Hibernate would see as actual writes, these acquisitions are delayed as long as possible (flush time).
I am not saying your scenario represents an illegal sequence of events. But you are that one that proposed that Hibernate delay these "writes" until the end of the transaction, and as such I think it is totally reasonable that you explain why you think that is the correct solution.
Also note that o.h.cache.Cache and o.h.cache.CacheProvider are published extension points...
> Usage of load() in PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock
> ------------------------------------------------------------------------------------------------
>
> Key: HIBERNATE-41
> URL: http://jira.jboss.com/jira/browse/HIBERNATE-41
> Project: Hibernate
> Issue Type: Bug
> Environment: SUSE 10.1, kernel 2.6.15 SPM, JDK 1.5.0_06, PostgreSQL 8.0.1
> Reporter: Yegor Yenikyeyev
> Assigned To: Steve Ebersole
> Priority: Blocker
> Attachments: nloptc.zip
>
>
> It seems like we discovered an unpredictable Hibernate and/or TreeCache behavior after upgrade JBossCache from 1.2.4SP2 to JBossCache 1.3.0SP2. For now I can witness that the same problem appears with 1.4.0CR2. I do not think that it's Hibernate-only or TreeCache-only issue but I do think it's a kind of integration issue or misunderstanding of how TreeCache transaction isolation is implemented. According Manik Surtani JBossCache v1.2.4 had an issue with READ_COMMITED implementation (JBCACHE-218 ) and sinnce it fixed any usage of PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock if both method load same instance of an entiry.
> Our application works in clustered environment and we use JBossCache as L2 cache solution for Hibernate 3.1.3 (I checked this with 3.2.0CR2 as well). Our settings for JBossCache are
> REPL_SYNC, READ_COMMITED and our target business object methods (f1 and f2) have PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW. Our JDBC driver is 3.0 compliant.
> Our objects hierarchy is like: Occasion contains link to Round and Round contains link to Tournament. Round is NOT configured as "lazy" field in Occasion mapping b/c we always need to have it initialized.
>
> Here is in short what we try to do in our application:
>
> (1) Transaction1: Call f1 (PROPAGATION_REQUIRED) method of a business object and it causes Occasion1 to be loaded via a cachable query. After that Hibernate initializes Occasion1.round field and loads Round1.
> (2) Transaction1: Hibernate puts loaded Occasion1 and Round1 in L2 cache.
> (3) Transaction1: TreeCache creates com/companyname/Occasion/com.companyname.Occasion#1 region and obtains WriteLock (WL1)
> (4) Transaction1: TreeCache creates com/companyname/Round/com.companyname.Round#1 region and obtains WriteLock (WL2)
> (5) Transaction1: Do some business logic stuff
> (6) Transaction1: We expect current transaction to be long and we want to change status of Occasoin1 in DB very quickly. At this point we need an exclusive lock for appropriate row in DB table to change the status and commit it. In order to do this we call f2 (PROPAGATION_REQUIRES_NEW) which suppose to be a REALLY short transaction which release lock on the DB row as fast as possible.
>
> (7) Transaction2: Transaction1 SUSPENDED at this point. We call HibernateTemplate (we use Spring as well) to load Occasion1 for update with LockMode.UPGRADE flag and get exclusive lock.
> (8) Transaction2: Hibernate does NOT check for an instance of Occasion1 in L2 cache ( I suppose it's b/c we obviously do want to lock it for update )
> (9) Transaction2: Hibernate does check for an instance of Round1 in L2 cache and it calls get() on TreeCache to obtain com/companyname/Round/com.companyname.Round#1
> (10) Transaction2: At this point 1.3.0SP2 tries to obtain ReadLock for com/companyname/Round/com.companyname.Round#1 and it can't b/c there is a WL for that node in suspended Transaction1 !!! It can't obtain ReadLock for Round#1 anyhow!
> (11) Transaction2: Stuck waiting for WL2 to be released in TreeCache but it can't be released as soon as Transaction1 suspended and waits for Transaction2 to finish.
>
> Obviously this situation is ridiculous - a legal sequence of operations causes a deadlock on TreeCache. We do not expect com/companyname/Round/com.companyname.Round#1 to be visible in Transaction2 b/c we use READ_COMMITED but WL2 must not affect Transaction2 in this way. As soon as TreeCache prevents other transactions from reading com/companyname/Round/com.companyname.Round#1 it must not tell other transactions that the node exists to keep READ_COMMITED behavior consistent. For now it simply preventing everybody from using PROPAGATION_REQUIRES_NEW.
> The described scenario works with 1.2.4SP2 without a problem and I have serious concern that READ_COMMITED strategy is really implemented in v1.2.4 but at least the behavior is more consistent comparing to v1.3.0. As far as i understand this is result of JBCACHE-218 bugfix.
>
> We tried to change PROPAGATION_REQUIRES_NEW to PROPAGATION_NESTED and take advantage of nested transactions. We assume that com/companyname/Round/com.companyname.Round#1 would be available in a nested Transaction2 from Transaction1. But PROPAGATION_NESTED isn't supported by current JBossTransaction implementation (see line 209 in TxManager.java from 4.0.4.GA).
> We could change isolation to READ_UNCOMMITED but it's simply impossible in many other places of our application.
> We could make a trick and load Occasion1 with Round1 in a separate Transaction0 before starting Transaction1 but we HAVE to use LRU policy. That is why there is no chance for us to make sure that eviction won't happen between Transaction0 and Transaction1. If it happened then we are in the same situation as described above.
> Finally we could stop using Transaction2 but our application is intend to handle large amount of traffic and as soon as Transaction1 takes up to 3sec (comparing to 50ms for Transaction2) we might get up to 700-1000 transactions on queue waiting for table row lock to be released and we just can't allow this.
>
> From what I see in Hibernate TreeCache sources and I have no idea how to avoid the situation described above. One of my developers told me that probably it's possible to put stuff into L2 cache on transaction commit which would decrease WL time and resolve the issue with the deadlock. Honestly I'm seriously concerned how it applies to existing Hibernate. I think small issues like performance issue of loading the same object during 1 transaction more then once can be resolved by using L1 cache or JDBC driver abilities. But I guess there are a plenty of work to make this working for cachable queries.
> Another option I see is to do a trick and put values for Round1 and Occasion1 into a new region for Transaction2 if we know that Transaction1 suspended and owns WLs for various nodes. I really do not like this way b/c in fact it's not a pure pessimistic locking. But the issue described before is worse price for "pure" READ_COMMITED strategy. In fact it showstopper assuming there is no way to use PROPAGATION_NESTED.
--
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, 10 months
[JBoss JIRA] Created: (JBPM-710) Cancelling a task will signal token over default transition
by Chris OBrien (JIRA)
Cancelling a task will signal token over default transition
-----------------------------------------------------------
Key: JBPM-710
URL: http://jira.jboss.com/jira/browse/JBPM-710
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.2
Environment: jBPM 3.1.2, Windows XP, WSAD 5.1.2, jdk 1.4.2_05
Reporter: Chris OBrien
Assigned To: Tom Baeyens
Cancelling a task still calls .end(); This will cause the task to set all the time stamps appropriately, but then just signal the token over the default transition.
What happens if someone wants to cancel a task but go down a specific route, or not follow any transition, and remain where it is?
Also, this is in regards to JIRA-654 which was marked as fixed, but I am unclear as to if it was, or how.
--
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, 10 months