[JBoss JIRA] Created: (BPEL-244) Support for BPEL process instance monitoring in jBPM admin console
by Meghana Joglekar (JIRA)
Support for BPEL process instance monitoring in jBPM admin console
------------------------------------------------------------------
Key: BPEL-244
URL: http://jira.jboss.com/jira/browse/BPEL-244
Project: JBoss jBPM BPEL
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Engine
Reporter: Meghana Joglekar
Assigned To: Alejandro Guizar
One can currently run BPEL processes on jBPM engine and check the log files to see the runtime report. But this process is not efficient in monitoring how the process is doing, what processes are running, what went wrong when a fault occurred etc. It will be nice to have administration console to see this information. The administration console can then list the process instances that are running, show visual graph of the instance and for each node in the graph more information about it. ActiveBPEL and OracleBPEL both provide such consoles and they are great tools for administrators. It will be nice if it also provides 'delete' functionality for stalled processes or old processes. The list could go on but in its basic form, processes listing, process instance listing and then more information about them [instances] will be useful.
--
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
17 years
[JBoss JIRA] Created: (JBRULES-759) CLONE -Unable to add package after it was added and removed
by Brugger Antony (JIRA)
CLONE -Unable to add package after it was added and removed
-----------------------------------------------------------
Key: JBRULES-759
URL: http://jira.jboss.com/jira/browse/JBRULES-759
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.0.4
Environment: Windows2000 Advanced Server
JBRules3.0.4
Reporter: Brugger Antony
Assigned To: Edson Tirelli
Fix For: 3.0.5
Unable remove a rule package when it was added after it has been added and removed.
I have seen the issue [#JBRULES-358]. My test go a little far than [#JBRULES-358].
I remove the package again when it was added for the seconn time, then an exception was thrown.
My test case is:
public void testRuleBaseRemove() throws Exception
{
RuleBase ruleBase = RuleBaseFactory.newRuleBase();
File file = new File("test.drl");
//add and remove
PackageBuilder builder = new PackageBuilder();
builder.addPackageFromDrl(new FileReader(file));
Package pkg = builder.getPackage();
ruleBase.addPackage(pkg);
ruleBase.removePackage(pkg.getName());
//add and remove again
builder = new PackageBuilder();
builder.addPackageFromDrl(new FileReader(file));
pkg = builder.getPackage();
ruleBase.addPackage(pkg);
ruleBase.removePackage(pkg.getName());
}
the exception is throw:
java.lang.NullPointerException
at org.drools.reteoo.HashedObjectSinkList.remove(HashedObjectSinkList.java:102)
at org.drools.reteoo.ObjectTypeNode.remove(ObjectTypeNode.java:245)
at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:211)
at org.drools.reteoo.LeftInputAdapterNode.remove(LeftInputAdapterNode.java:285)
at org.drools.reteoo.TerminalNode.remove(TerminalNode.java:297)
at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:589)
at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:244)
at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:338)
at com.zte.ums.uep.pal.fm.osf.rules.core.RuleBaseTest.testRuleBaseRemove(RuleBaseTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
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
17 years, 1 month
[JBoss JIRA] Created: (JGRP-549) ConnectionTable: spurious Connection instances on concurrent connects
by Bela Ban (JIRA)
ConnectionTable: spurious Connection instances on concurrent connects
---------------------------------------------------------------------
Key: JGRP-549
URL: http://jira.jboss.com/jira/browse/JGRP-549
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
If we have members A and B, and they don't yet have connections to each other, and start sending messages to each other at the exact same time, then we run into the following scenario:
- A attempts to connect to B (new Socket())
- B attempts to connect to A
- A accepts B's connection and adds an entry for B into its table
- B adds an entry for A into its table
- B gets the accept() from A, but doesn't add the new Connection into its table because there is already a Connection. This leads to a spurious Connection object, which will only be closed and garbage collected once A or B leaves the cluster
- We used to close Connections which were already in the table, but this lead to ping-pong effects where concurrent initial senders always closed each others connections
- Even worse: a new Socket() always creates a new Connection object and places it into the table, *regardless* of whether a Connection for a given destination already exists or not !
GOAL:
#1 Have only 1 TCP connection between any 2 members
#2 Establish a handshaking mechanism, to avoid spurious connections
SOLUTION:
- When A establishes a connection to B, A needs to get agreement from B first (and vice versa)
--
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
17 years, 2 months