[JBoss JIRA] Created: (JGRP-1371) Unable to suspend self in FLUSH.blockMessageDuringFlush(); Eternal timeouts not supported
by Nicolas Estrada (JIRA)
Unable to suspend self in FLUSH.blockMessageDuringFlush(); Eternal timeouts not supported
-----------------------------------------------------------------------------------------
Key: JGRP-1371
URL: https://issues.jboss.org/browse/JGRP-1371
Project: JGroups
Issue Type: Bug
Affects Versions: 2.12.1
Environment: All
Reporter: Nicolas Estrada
Assignee: Bela Ban
Priority: Critical
If a positive timeout is specified for the FLUSH protocol, if the specified waiting time timeout elapses during the notBlockedDown.await(timeout) invocation, the shouldSuspendByItself flag will be set but it will continue looping forever. The if clause below should be moved into the while block.
If the timeout is 0L or negative, instead of waiting forever, it will instantaneously return from the await(timeout) method, but seeing as it can never suspend itself as mentioned earlier, it will loop forever until a STOP_FLUSH or ABORT_FLUSH event is received.
Changing the method to await() for "eternal" timeouts may be dangerous however; There must be a guarantee that the isBlockingFlushDown is toggled even if the FLUSH coordinator fails.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (JBRULES-3150) NPE in ObjectTypeConfigurationRegistry when accumulate returns null (and "quick hack for 5.2")
by Wolfgang Laun (JIRA)
NPE in ObjectTypeConfigurationRegistry when accumulate returns null (and "quick hack for 5.2")
----------------------------------------------------------------------------------------------
Key: JBRULES-3150
URL: https://issues.jboss.org/browse/JBRULES-3150
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.2.0.Final
Reporter: Wolfgang Laun
Assignee: Mark Proctor
Fix For: 5.2.1.Final
rule foo # the problem is usually better "hidden"
when
Object() from accumulate( Object(),
init( Object res = null; )
action( res = null; )
result( res ) )
then
end
causes the exception as shown below, or similar.
A runtime diagnostic should tell the user (at least) that
an accumulate result is null.
ALSO, PLEASE NOTE THIS COMMENT in AccumulateNode.java:642!
// this is a quick hack for the 5.2 release
Exception in thread "main" java.lang.NullPointerException
at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:58)
at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:646)
at org.drools.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:183)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:146)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:204)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:191)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:332)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:293)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:905)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
at match.Main.makeFacts(Main.java:120)
at match.Main.execute(Main.java:98)
at match.Main.main(Main.java:126)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (AS7-1054) The CallbackHandler is called multiple times on the client side with Remoting / Managent Interface
by Darran Lofthouse (JIRA)
The CallbackHandler is called multiple times on the client side with Remoting / Managent Interface
--------------------------------------------------------------------------------------------------
Key: AS7-1054
URL: https://issues.jboss.org/browse/AS7-1054
Project: Application Server 7
Issue Type: Bug
Components: Remoting, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Alpha1
This may be a side effect of the current problems where Remoting is looped to establish the connection but it means that we need to cache the users username and password from the first attempt so we don't keep prompting them - the problem then is we do not know if the subsequent call is because their values were invalid or just because of the retries.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (AS7-1374) Domain Management - Ensure we keep Native connections alive where appropriate
by Darran Lofthouse (JIRA)
Domain Management - Ensure we keep Native connections alive where appropriate
-----------------------------------------------------------------------------
Key: AS7-1374
URL: https://issues.jboss.org/browse/AS7-1374
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Beta1
Establishing a connection can generally also involve negotiating the security before the connection is first used, this has the potential to become a major performance drain especially if the management load is high (management can be everything from updating the model to querying metrics).
This task is to ensure we keep the connections alive where it makes sense.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (AS7-1102) Create PKCS#11 Compitable Cryptographic Services for Domain Management
by Darran Lofthouse (JIRA)
Create PKCS#11 Compitable Cryptographic Services for Domain Management
----------------------------------------------------------------------
Key: AS7-1102
URL: https://issues.jboss.org/browse/AS7-1102
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Fix For: 7.1.0.Beta1
Within domain management there are occasions where passwords need to be stored or keystores accessed either for encryption / decryption of password or to load the keys used for SSL exchanges.
Commonly a password within code is used for password based encryption of other passwords, this obfuscates the password but does not over complicate the process of recovering the password, alternatively a local keystore can be used for the encryption but again everything is available on the local disk to recover the password.
PKCS#11 will allow the cryptographic to be delegated to hardware which contains it's own protection against keys being made available.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years