[JBoss JIRA] Created: (JGRP-447) Non-thread-safe access to FC.creditors
by Brian Stansberry (JIRA)
Non-thread-safe access to FC.creditors
--------------------------------------
Key: JGRP-447
URL: http://jira.jboss.com/jira/browse/JGRP-447
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4.1 SP1
Reporter: Brian Stansberry
Assigned To: Bela Ban
During load testing of AS HttpSession repl, QE saw RPC transmission errors with the following root cause:
[JBoss] Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
[JBoss] at java.util.ArrayList.RangeCheck(ArrayList.java:546)
[JBoss] at java.util.ArrayList.get(ArrayList.java:321)
[JBoss] at org.jgroups.protocols.FC.handleDownMessage(FC.java:390)
[JBoss] at org.jgroups.protocols.FC.down(FC.java:320)
[JBoss] at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
[JBoss] at org.jgroups.protocols.FC.receiveDownEvent(FC.java:314)
[JBoss] at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
[JBoss] at org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
[JBoss] at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
[JBoss] at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
[JBoss] at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:294)
[JBoss] at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
[JBoss] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
[JBoss] at org.jgroups.JChannel.down(JChannel.java:1231)
[JBoss] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:788)
[JBoss] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:765)
[JBoss] at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:299)
[JBoss] at org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:444)
[JBoss] at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:193)
[JBoss] at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:429)
Having a look at FC, in handleDownMessage(), where the problem occurred, there's this:
Util.release(lock);
try
{
...
for(int i=0; i < creditors.size(); i++) {
sendCreditRequest((Address)creditors.get(i));
}
}
....
in handleCredit() there's:
if(Util.acquire(lock)) {
...
if(creditors.size() > 0) { // we are blocked because we expect credit from one or more members
creditors.remove(sender);
...
}
...
}
If the creditors.remove(sender) call is invoked while the handleDownMessage for loop is looping, there's a possibility of IndexOutOfBoundsException.
--
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
[JBoss JIRA] Closed: (JBCACHE-404) Provide API to allow multiple callers to safely call activateRegion() .
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-404?page=all ]
Manik Surtani closed JBCACHE-404.
---------------------------------
Fix Version/s: 2.0.0.GA
Resolution: Done
> Provide API to allow multiple callers to safely call activateRegion() .
> -----------------------------------------------------------------------
>
> Key: JBCACHE-404
> URL: http://jira.jboss.com/jira/browse/JBCACHE-404
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4SP1, 1.2.4
> Reporter: Brian Stansberry
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: 2.0.0.CR1, 2.0.0.GA
>
>
> If a caller calls activateRegion() and the region is already active, they will get a RegionNotEmptyException. Need to add an API to make it easy for use cases where multiple callers may want to activate the same region.
> Use case for this is ClusteredSSO. Multiple ClusteredSSO valves can be running in the same server; all share the /SSO region. The TreeCache is shared with session replication, so the activateRegion API needs to be used. Currently it catches the RegionNotEmptyException, but I don't like this in the ClusteredSSO code.
> Possibilities:
> 1) Add an isRegionActive() method, callers can check first. But this can lead to race conditions.
> 2) Overload the activateRegion method with a version that won't throw the RegionNotEmptyException.
> Don't want to get rid of the RegionNotEmptyException, as in many uses cases (e.g. session repl) the region should not have data; if it does that's an error condition the application should know about.
--
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
[JBoss JIRA] Commented: (JBCACHE-404) Provide API to allow multiple callers to safely call activateRegion() .
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-404?page=comments#action_12357929 ]
Manik Surtani commented on JBCACHE-404:
---------------------------------------
I've implemented an activateIfEmpty() method in Region and RegionManager - for now this just catches the RNEE and logs rather than re-throws.
> Provide API to allow multiple callers to safely call activateRegion() .
> -----------------------------------------------------------------------
>
> Key: JBCACHE-404
> URL: http://jira.jboss.com/jira/browse/JBCACHE-404
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.4SP1, 1.2.4
> Reporter: Brian Stansberry
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: 2.0.0.CR1
>
>
> If a caller calls activateRegion() and the region is already active, they will get a RegionNotEmptyException. Need to add an API to make it easy for use cases where multiple callers may want to activate the same region.
> Use case for this is ClusteredSSO. Multiple ClusteredSSO valves can be running in the same server; all share the /SSO region. The TreeCache is shared with session replication, so the activateRegion API needs to be used. Currently it catches the RegionNotEmptyException, but I don't like this in the ClusteredSSO code.
> Possibilities:
> 1) Add an isRegionActive() method, callers can check first. But this can lead to race conditions.
> 2) Overload the activateRegion method with a version that won't throw the RegionNotEmptyException.
> Don't want to get rid of the RegionNotEmptyException, as in many uses cases (e.g. session repl) the region should not have data; if it does that's an error condition the application should know about.
--
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
[JBoss JIRA] Created: (JBAS-4275) seperating classloader in an ear file can not deploy resource adapters
by Ingo Bruell (JIRA)
seperating classloader in an ear file can not deploy resource adapters
----------------------------------------------------------------------
Key: JBAS-4275
URL: http://jira.jboss.com/jira/browse/JBAS-4275
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading, Deployment services, JCA service
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows XP SP2, jdk1.6, jdk1.5.0_07
Reporter: Ingo Bruell
Assigned To: Scott M Stark
i have created an ear file which contains some resource adapters in embedded rar files. These rar files contains classes who implements the adapter. If i try to deploy this ear file with scoped classloading the adapters could not be deployed.
I always got the following traces:
2007-03-30 11:42:45,500 DEBUG [org.jboss.resource.connectionmanager.RARDeployment] Starting jboss.jca:service=ManagedConnectionFactory,name=AccountVerifierAdapter
2007-03-30 11:42:45,500 ERROR [org.jboss.resource.connectionmanager.RARDeployment] Could not find ManagedConnectionFactory class: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
java.lang.ClassNotFoundException: No ClassLoaders found for: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:322)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy32.start(Unknown Source)
at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
2007-03-30 11:42:45,515 DEBUG [org.jboss.resource.connectionmanager.RARDeployment] Starting failed jboss.jca:service=ManagedConnectionFactory,name=AccountVerifierAdapter
org.jboss.deployment.DeploymentException: Could not find ManagedConnectionFactory class: de.wincor.fotop.verifier.connector.ManagedConnectionFactoryImpl
at org.jboss.resource.connectionmanager.RARDeployment.startService(RARDeployment.java:327)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy32.start(Unknown Source)
at org.jboss.deployment.SimpleSubDeployerSupport.startService(SimpleSubDeployerSupport.java:356)
at org.jboss.deployment.SimpleSubDeployerSupport.start(SimpleSubDeployerSupport.java:127)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
i have enabled scoped classloading in the jboss-app.xml with:
<jboss-app>
<loader-repository>
de.wincor:loader=FOtopApp.ear
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>
--
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
[JBoss JIRA] Created: (JBPM-852) setPooledActors in AssignmentHandler doesn't work
by Diego Tobaldi (JIRA)
setPooledActors in AssignmentHandler doesn't work
-------------------------------------------------
Key: JBPM-852
URL: http://jira.jboss.com/jira/browse/JBPM-852
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.4
Environment: windows, jbpm-starters-kit-3.1.4
Reporter: Diego Tobaldi
Assigned To: Tom Baeyens
I'd implemented an AssignmentHandler and can´t to assign a task to several users. Example:
public class TestAssignmentHandler implements AssignmentHandler {
public void assign(Assignable assignable, ExecutionContext executionContext) throws Exception {
String[] actors= new String[]{"bert", "ernie"};
assignable.setActorId(null);
assignable.setPooledActors(actors);
}
--
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
