[JBoss JIRA] Created: (JBAS-7590) ClusteredDeploymentRepository does not take lock before removing deployment
by Brian Stansberry (JIRA)
ClusteredDeploymentRepository does not take lock before removing deployment
---------------------------------------------------------------------------
Key: JBAS-7590
URL: https://jira.jboss.org/jira/browse/JBAS-7590
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, ProfileService
Affects Versions: JBossAS-6.0.0.M1, JBossAS-5.1.0.GA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-6.0.0.M2
The global lock should be taken in removeDeploymentContent(), otherwise you can get this:
1.
13:40:15,744 ERROR [StandaloneManagedDeploymentComponent] Failed to remove deployment 'vfsfile:/home/emuckenh/svn/eap/JBPAPP_5_0/build/output/jboss-5.0.0.Branch/server/all/farm/ROOT.war/'.
2.
java.lang.RuntimeException: java.util.ConcurrentModificationException
3.
at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:312)
4.
at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.remove(StreamingDeploymentTarget.java:228)
5.
at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.remove(DeploymentProgressImpl.java:322)
6.
at org.jboss.profileservice.management.client.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:95)
7.
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:155)
8.
at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.deleteResource(StandaloneManagedDeploymentComponent.java:314)
9.
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10.
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
11.
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
12.
at java.lang.reflect.Method.invoke(Method.java:597)
13.
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
14.
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
15.
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
16.
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
17.
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
18.
at java.lang.Thread.run(Thread.java:619)
19.
Caused by: java.util.ConcurrentModificationException
20.
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
21.
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1154)
22.
at org.jboss.system.server.profileservice.repository.clustered.local.AbstractLocalContentManager.getContentMetadataForRemove(AbstractLocalContentManager.java:505)
23.
at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.removeDeploymentContent(DefaultRepositoryClusteringHandler.java:362)
24.
at org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.removeDeployment(ClusteredDeploymentRepository.java:352)
25.
at org.jboss.profileservice.management.upload.remoting.DeployHandler.removeDeployment(DeployHandler.java:176)
26.
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.remove(AbstractDeployHandler.java:384)
27.
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:236)
28.
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
29.
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
30.
at org.jboss.remoting.Client.invoke(Client.java:1917)
31.
at org.jboss.remoting.Client.invoke(Client.java:768)
32.
at org.jboss.profileservice.management.client.upload.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:304
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBRULES-2399) java regexp inline modifier in dsl causes java.lang.IndexOutOfBoundsException
by Lev Kochubeevsky (JIRA)
java regexp inline modifier in dsl causes java.lang.IndexOutOfBoundsException
-----------------------------------------------------------------------------
Key: JBRULES-2399
URL: https://jira.jboss.org/jira/browse/JBRULES-2399
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.0.1.FINAL
Environment: Windows XP, Eclipse 3.4 with Drools 5.0.1 plugin
Reporter: Lev Kochubeevsky
Assignee: Mark Proctor
Does Drools 5 support java regexp inline modifiers? I tested my pattern matching in java and it works fine:
System.out.println (
Pattern.matches("(?i)update the message",
"uPdAte the message")); // true
I'm trying to use the same thing in DSL:
[then](?i)update the message fact=update ( m );
DSLR:
update the message fact
and get:
java.lang.IndexOutOfBoundsException: No group 3
at java.util.regex.Matcher.group(Matcher.java:470)
at java.util.regex.Matcher.appendReplacement(Matcher.java:737)
at java.util.regex.Matcher.replaceAll(Matcher.java:813)
at org.drools.lang.dsl.DefaultExpander.expandRHS(DefaultExpander.java:305)
at org.drools.lang.dsl.DefaultExpander.expandConstructions(DefaultExpander.java:145)
at org.drools.lang.dsl.DefaultExpander.expand(DefaultExpander.java:116)
at org.drools.compiler.DrlParser.parse(DrlParser.java:125)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(Unknown Source)
at org.drools.eclipse.DroolsEclipsePlugin.parseResource(Unknown Source)
at org.drools.eclipse.view.rules.RulesView.updateResource(Unknown Source)
at org.drools.eclipse.view.rules.RulesView.access$1(Unknown Source)
at org.drools.eclipse.view.rules.RulesView$1.visit(Unknown Source)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79)
at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48)
at org.drools.eclipse.view.rules.RulesView.resourceChanged(Unknown Source)
at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:288)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:282)
at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148)
at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313)
at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:153)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBRULES-1432) Queries Executed while Rules are Firing Causes Exceptions
by Steve Shabino (JIRA)
Queries Executed while Rules are Firing Causes Exceptions
---------------------------------------------------------
Key: JBRULES-1432
URL: http://jira.jboss.com/jira/browse/JBRULES-1432
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.4
Environment: Sun 1.5.0_04 Windows
Reporter: Steve Shabino
We have a stateful WM into which we periodically (1) insert new facts and fire rules, and (2) execute queries. Drools fails when we allow query execution in another thread during fireAllRules().
Set-up:
- Every 10 seconds, Thread A inserts some facts and calls fireAllRules(). fireAllRules() is never called concurrently with itself.
- Thread B executes many getQueryResults() calls in series (no concurrency in query execution)
Our rule base uses shadow facts for all facts and is set up this way:
conf.setAssertBehaviour(RuleBaseConfiguration.AssertBehaviour.EQUALITY);
conf.setRemoveIdentities(true);
conf.setLogicalOverride(RuleBaseConfiguration.LogicalOverride.DISCARD);
conf.setMaintainTms(true);
conf.setShadowProxy(true);
We are making some use of insertLogical().
Expected:
- Queries are run against the last consistent truth state, even while fireAllRules() is running.
Actual Behavior:
We get this exception:
Caused by: java.lang.RuntimeException: Unable to pop
at org.drools.util.PrimitiveLongStack.pop(PrimitiveLongStack.java:63)
at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:44)
at org.drools.reteoo.ReteooWorkingMemory.getQueryResults(ReteooWorkingMemory.java:90)
This bug occurs under 4.04 and 4.1 Trunk as of 1/22.
Please let us know if we can provide additional information.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBRULES-1649) Queryresult.getFactHandles() returns bad handles
by Jaroslaw Kijanowski (JIRA)
Queryresult.getFactHandles() returns bad handles
------------------------------------------------
Key: JBRULES-1649
URL: http://jira.jboss.com/jira/browse/JBRULES-1649
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.0.7, 5.0.0-M1
Reporter: Jaroslaw Kijanowski
Assigned To: Mark Proctor
This is present in 4.0.7 and trunk (rev. 20565)
I have following code:
TestFact tf1 = new TestFact();
TestFact tf2 = new TestFact();
FactHandle factHandle1 = workingMemory.insert(tf1);
FactHandle factHandle2 = workingMemory.insert(tf2);
workingMemory.fireAllRules();
System.out.println("Expected:");
System.out.println(tf1);
System.out.println(factHandle1);
System.out.println(tf2);
System.out.println(factHandle2);
System.out.println("Received:");
QueryResults queryResults = workingMemory.getQueryResults("getTestFacts");
for ( Iterator it = queryResults.iterator(); it.hasNext(); ) {
QueryResult result = ( QueryResult ) it.next();
System.out.println(result.get(0 ));
System.out.println( result.getFactHandles()[0] );
}
I would expect that result.getFactHandles() returns the same handle I got when I was inserting the fact into the workingmemory
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBAS-7593) Investigate org.jboss.test.spring.test.SpringClusterTestCase failure
by Brian Stansberry (JIRA)
Investigate org.jboss.test.spring.test.SpringClusterTestCase failure
--------------------------------------------------------------------
Key: JBAS-7593
URL: https://jira.jboss.org/jira/browse/JBAS-7593
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Spring integration, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: JBossAS-6.0.0.M2
Test fails because of this:
Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Bean class [org.jboss.spring.cluster.CachePostProcessor] not found
Offending resource: URL [vfszip:/home/bes/dev/jboss/trunk/testsuite/output/lib/spring-cluster-pojos.jar/META-INF/cluster-spring.xml]
The class isn't found because it's not there; appears to have been dropped in the extraction of spring-int module.
I'll check w/ Ales if he wants it.
This test will eventually be removed, or perhaps repackaged to include POJO Cache in the deployment, as POJO Cache will not be included with AS 6 and the Infinispan we use with AS 6 will not include the kind of capabilities used by this CachePostProcessor class.
--
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
16 years, 4 months