[JBoss JIRA] Created: (JBAS-5338) Timer Persistency
by aneesh vasanthan (JIRA)
Timer Persistency
-----------------
Key: JBAS-5338
URL: http://jira.jboss.com/jira/browse/JBAS-5338
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.0.2RC1
Environment: Windows xp
Reporter: aneesh vasanthan
Assigned To: Alexey Loubyansky
Priority: Critical
We are facing some problems in implementing ejb timer service. We are using stateless session bean as the timed objects. Upon server restart it gets back the previous timerstate, it can be found from the jmx-console that a new handle is created for each of the timer with remaining time = negative value, which goes on decreasing and never reaches timeout.
Server: jboss 4.02 AS
Operating system : WindowsXP
--
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
14 years, 5 months
[JBoss JIRA] Created: (JBAS-5801) New ManagedConnection locking does not play nicely with transaction interleaving
by Adrian Brock (JIRA)
New ManagedConnection locking does not play nicely with transaction interleaving
--------------------------------------------------------------------------------
Key: JBAS-5801
URL: https://jira.jboss.org/jira/browse/JBAS-5801
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1
Reporter: Adrian Brock
Assignee: Jesper Pedersen
Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA
The new locking in the jms resource adapter to avoid race conditions between the asynch rollback
and the normal usage is not playing nicely with transaction interleaving.
When we are using transaction interleaving, there is no such race condition because the "normal usage"
has already been suspended and the managed connection (for normal usage) given to another transaction.
In fact, the new locking in this could cause over contention because besides the lock being irrelevant,
it could actually cause the real current usage of the managed to block.
The problem has actually first show up as incorrect release of the lock:
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at org.jboss.resource.adapter.jms.JmsManagedConnection.unlock(JmsManagedConnection.java:401)
at org.jboss.resource.adapter.jms.JmsXAResource.commit(JmsXAResource.java:102)
at org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper.commit(JcaXAResourceWrapper.java:53)
at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:502)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3107)
at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3022)
at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2126)
at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1819)
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
but this is really a symptom of taking the lock unnecessarily in the first place.
The fix would be to spot that we are transaction interleaving by keeping track of the "active" xid in
JmsXAResource wrapper and only doing the locking in the 2PC callbacks if we are the active xid.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Created: (JBJMX-109) loaderRepositoryClass="..." seems to be useless
by David Schlotfeldt (JIRA)
loaderRepositoryClass="..." seems to be useless
-----------------------------------------------
Key: JBJMX-109
URL: http://jira.jboss.com/jira/browse/JBJMX-109
Project: JBoss JMX
Issue Type: Feature Request
Affects Versions: JBossAS-4.0.0
Reporter: David Schlotfeldt
This isn't exactly an error, and maybe we just aren't suppose to use it, but DTD and documentation says we can specify an implementation of org.jboss.mx.loading.LoaderRepository to use in many xml files, such as jboss-app.xml, with the loaderRepositoryClass attribute.
Well even though you can -- you can't. You can't because a number of classes including UnifiedClassLoader cast objects directly to UnifiedLoaderRepository3 instead of LoaderRepository. Which means your implementations actually need to extend UnifiedLoaderRepository3.
Also HeirarchicalLoaderRepository3 is not flexible. You would think it would be possible to create a hierarchy of LoaderRepositorys but you can't. This is because it expects its parent to be a UnifiedLoaderRepository3 -- okay fine, whatever. So you should at least be able a HeirarchicalLoaderRepository3 object as a parent to another HeirarchicalLoaderRepository3 object since UnifiedLoaderRepository3 extends UnifiedLoaderRepository3. You can't . Why? Well because I am PRETTY SURE that HeirarchicalLoaderRepository3.getPackageClassLoaders(..) returns a Set of PkgClassLoader objects while UnifiedLoaderRepository3 .getPackageClassLoaders(..) (the method it overrides!) returns a Set of RepositoryClassLoader objects. When HeirarchicalLoaderRepository3 calls getPackageClassLoaders(...) on its parent repository it casts items to RepositoryClassLoader , since that is what UnifiedLoaderRepository3 returns. This means if you make HeirarchicalLoaderRepository3 have a parent of type HeirarchicalLoaderRepository3 you will get a ClassCastException since.. well.. a PkgClassLoader isn't a RepositoryClassLoader class.
LoadMgr3 is actually programmed to expect the Set returned by getPackageClassLoaders(...) to be both RepositoryClassLoader and PkgClassLoader objects probably because of this.
I COMPLETELY understand how code gets messy through time but this code should really be cleaned up -- especially if we are allowing users to specify a LoaderRepository implementation. As it stands the loaderRepositoryClass attribute SEEMS to be useless to specify your own implementation.
--
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
14 years, 6 months
[JBoss JIRA] Created: (JASSIST-39) failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types
by twieger (JIRA)
failure to compile an instance method which invokes a static method in a different class and both methods have the same return type, name and argument types
------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JASSIST-39
URL: http://jira.jboss.com/jira/browse/JASSIST-39
Project: Javassist
Issue Type: Bug
Reporter: twieger
Assigned To: Shigeru Chiba
The testcase below demonstrates the problem.
The first invocation of CtNewMethod#make works, the second one fails.
It looks like the problem is related with MemberResolver#lookupMethod.
The check to enable the creation of a recursively called method is not precise enough. It actually succeeds, although the current method is an instance method, and the method which shall be invoked is a static method.
==========================================
package experimental;
import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtNewMethod;
import org.testng.annotations.Test;
public class TestJavaAssist {
@Test
public void testJavaAssist() throws CannotCompileException {
ClassPool classPool = new ClassPool();
classPool.appendSystemPath();
CtClass ctClass = classPool.makeClass("Test");
CtNewMethod.make("public String foox(){return experimental.TestJavaAssist.foo();}", ctClass);
CtNewMethod.make("public String foo(){return experimental.TestJavaAssist.foo();}", ctClass);
}
public static final String foo() {
return "foo";
}
}
--
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
14 years, 6 months
[JBoss JIRA] Created: (JBPORTAL-1707) New UserModule/RoleModule finders
by Andrew Oliver (JIRA)
New UserModule/RoleModule finders
---------------------------------
Key: JBPORTAL-1707
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1707
Project: JBoss Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Portal Security
Affects Versions: 2.6.1 Final
Reporter: Andrew Oliver
Assigned To: Julien Viet
While working with clients using the portal API some efficiency issues with regards to finders have become apparent:
It is presently possible to find users having a role by calling MembershipModule.getUsers(role). However it is not possible to get a list of users with a set of roles, a list of users who do NOT have a role or set of roles. (there are ways in both HQL and LDAP to construct each type of query). I suggest something similar to hibernate conditions.
MembershipModule.getUsers().addCondition(
Condition.and(
Condition.not(roleSet), Condition.with(roleSet)
)
)
this would result in roughly:
from Users where roles in (:roleSet) and roles not in (:roleSet2)
and something like
(& (|(role=roleName)(role=roleName) )
(&(!role=roleName)(!role=roleName) )
)
in LDAP
the attribute name can be based on the type. As it stands you have to do something like:
try {
Role roleApproved = rolemodule.findRoleByName("approved");
Role roleUsers = rolemodule.findRoleByName("User");
//todo create transient wrapper set.
Set users = membership.getUsers(roleUsers);
dirtyStinkyHackToGetAroundPortalAPIBugACO(users);
System.err.println("Total number of users with User Role : " + users.size() );
Set temp = new HashSet();
temp = dirtyStinkyHackToGetAroundPortalAPIBugACO(users); //because the hibernate set doesn't have removeall
users = temp;
Set usersApproved = membership.getUsers(roleApproved);
System.err.println("number of users with approved role: "+usersApproved.size());
users.removeAll(usersApproved);
System.err.println("Total number of users with User Role and NO approved role : " + users.size() );
Map profiles = profiles(users);
response.setRenderParameter("op", "new");
request.getPortletSession().setAttribute("users", users);
request.getPortletSession().setAttribute("profiles", profiles);
} catch (IdentityException e) {
//todo type this and catch it up higher to make a
//smarter error message
throw new RuntimeException(e);
}
private Map profiles(Set users) throws IdentityException {
Iterator i = users.iterator();
Map retval = new HashMap();
while(i.hasNext()) {
User user = (User) i.next();
retval.put(user, profileModule.getProperties(user));
}
return retval;
}
private Set dirtyStinkyHackToGetAroundPortalAPIBugACO(Set users) {
Iterator i = users.iterator();
Set retval = new HashSet();
while(i.hasNext()) {
User u = (User)i.next();
u.getUserName();
retval.add(u);
}
return retval;
}
Just to get the list of users who DONT have the "approved" role. For our immediate needs:
UserModule.getUsersWithout(role) would work...until next time.
-Andy
--
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
14 years, 6 months
