[JBoss JIRA] (AS7-6120) Expand support for System Property substitution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6120?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6120:
----------------------------------
Attachment: (was: expressions.ods)
> Expand support for System Property substitution
> -----------------------------------------------
>
> Key: AS7-6120
> URL: https://issues.jboss.org/browse/AS7-6120
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jimmy Wilson
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: eap-6.1-prd
> Fix For: 7.2.0.CR1
>
> Attachments: expressions.ods
>
>
> Audit the core AS and all subsystems shipped in the AS distribution for suport for expression in management resource attributes.
> The basic philosophy toward expressions in previous releases was to only push devs to add support if there was a clear important use case. Devs could choose to add support beyond that, but we wouldn't push that. This JIRA and PRODMGT-195 from which it is derived reflects a change in philosophy. Now the philosophy is to support expressions unless the dev foresees a technical or future compatibility problem arising from doing so.
> This task DOES NOT advocate adding expression support to attributes that represent references to other model elements. Such references may prove problematic in the future and should not be added. We already have some model ref attributes that support expressions; this task DOES NOT advocate removing such support, unless the support has never been provided in a Final release (i.e. it was added during 7.2 development.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBJCA-954) Add explicit <recovery> element
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-954:
-------------------------------------
Summary: Add explicit <recovery> element
Key: JBJCA-954
URL: https://issues.jboss.org/browse/JBJCA-954
Project: IronJacamar
Issue Type: Task
Components: AS
Reporter: Jesper Pedersen
Assignee: Jeff Zhang
Fix For: 1.1.0.Beta4
In the RAR info tool add an explicit <recovery> element with <user-name> and <password> elements to all <connection-defintion>'s for an XATransaction based resource adapter.
Same goes for the resource adapter and datasource converter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6260) EJB 2.x Entity Bean Audit Field Deployment Issue
by Cory Dahlstrom (JIRA)
Cory Dahlstrom created AS7-6260:
-----------------------------------
Summary: EJB 2.x Entity Bean Audit Field Deployment Issue
Key: AS7-6260
URL: https://issues.jboss.org/browse/AS7-6260
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final
Reporter: Cory Dahlstrom
Assignee: jaikiran pai
Upon deployment of an EJB 2 entity bean that has <audit> tags specified in the jbosscmp-jdbc.xml file you will get this exception:
Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command
at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:132)
at org.jboss.as.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:215)
at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:44)
... 5 more
Caused by: java.lang.RuntimeException: JBAS010726: No security-domain configured but created-by specified
at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.initGeneratedFields(JDBCAbstractCreateCommand.java:148)
at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.init(JDBCAbstractCreateCommand.java:87)
at org.jboss.as.cmp.jdbc.JDBCInsertPKCreateCommand.init(JDBCInsertPKCreateCommand.java:43)
at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:130)
... 7 more
In looking at the source code where the error occurs in org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand, the securityManager is not being initialized in the init() method as it is in other version of JBoss. This causes an exception to be thrown from the initGeneratedFields() method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6259) Deployment of .rar with multiple ironjacamar.xml
by Stefano Maestri (JIRA)
Stefano Maestri created AS7-6259:
------------------------------------
Summary: Deployment of .rar with multiple ironjacamar.xml
Key: AS7-6259
URL: https://issues.jboss.org/browse/AS7-6259
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.2.Final (EAP)
Reporter: Stefano Maestri
Assignee: Stefano Maestri
Priority: Critical
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in
{noformat}
11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6258) Datasource subsystem "installed-drivers" attribute doesn't do anything
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6258:
-------------------------------------
Summary: Datasource subsystem "installed-drivers" attribute doesn't do anything
Key: AS7-6258
URL: https://issues.jboss.org/browse/AS7-6258
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, JCA
Reporter: Brian Stansberry
Assignee: Stefano Maestri
The "installed-drivers" attribute registered by DataSourcesSubsystemRootDefinition doesn't appear to do anything. Perhaps it should only be registered if registerRuntimeOnly && ! deployed and then it can use InstalledDriversListOperationHandler.INSTANCE as the read-handler? If so, the AttributeDefinition should include addFlag(Flag.STORAGE_RUNTIME).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JBCLUSTER-303) [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4, null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes.
by pankaj pandey (JIRA)
pankaj pandey created JBCLUSTER-303:
---------------------------------------
Summary: [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4,null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes.
Key: JBCLUSTER-303
URL: https://issues.jboss.org/browse/JBCLUSTER-303
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: HA-Server-Cache-ISPN
Environment: JBOSS 7.1.1 FINAL , REDHAT LINUX ENTERPRISE
Reporter: pankaj pandey
Assignee: Paul Ferraro
I am getting problem while implementing jboss 7 clustering with session persistence.
ava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: an exception which occurred: in element at index [0] of size [1]
02:41:08,277 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4,null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes. at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:216) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180) at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:772) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:669) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:119) at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:107) at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:58) at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:391) at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:119) at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:163) at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:67) at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:391) at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:154) at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:114) at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:85) at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:200) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.RSVP.up(RSVP.java:192) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:739) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:566) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.BARRIER.up(BARRIER.java:126) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.stack.Protocol.up(Protocol.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP.passMessageUp(TP.java:1180) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: an exception which occurred: in element at index [0] of size [1]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-6257) AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6257:
-------------------------------------
Summary: AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
Key: AS7-6257
URL: https://issues.jboss.org/browse/AS7-6257
Project: Application Server 7
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.3.0.Alpha1
AttributeDefinition.validateOperation currently only converts a string to an expression if the attribute supports expressions. It should convert any time it sees the syntax. This way if a STRING attribute that doesn't support expressions finds one, it will reject it instead of accepting it as a raw string.
Scheduling for 7.3 out of concern this may break things in 7.2 without time to notice/adapt.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (AS7-5311) Deployment of multiple .rar's with ironjacamar.xml
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-5311?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-5311:
--------------------------------------
it seems to me a regression on master (code rewritten for new DMR APIs). I've fixed it, but I'll open another issue for that.
It should not happen in 7.1.x
> Deployment of multiple .rar's with ironjacamar.xml
> --------------------------------------------------
>
> Key: AS7-5311
> URL: https://issues.jboss.org/browse/AS7-5311
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in
> {noformat}
> 11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] (JGRP-1557) SUPERVISOR: protocol to check conditions and perform corrective actions if needed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1557?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1557.
----------------------------
Resolution: Done
> SUPERVISOR: protocol to check conditions and perform corrective actions if needed
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1557
> URL: https://issues.jboss.org/browse/JGRP-1557
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> SUPERVISOR is a protocol anywhere in the stack that passes messages up and down by default; it doesn't take part in message processing.
> However, it handles events ADD_RULE / REMOVE_RULE, which adds/removes rules. A rule is a condition with a name, an interval and an (optional) action.
> When the interval for a condition has elapsed, it is triggered and (if true) it'll invoke the associated action. A condition can be triggered by an interval elapsed or perhaps also when a event is received (e.g. a view change).
> Example:
> - Condition: check if FD is present in the stack. If it is and fd.isMonitorRunning() == false and fd.getView().size() > 1, then call action fd.startFailureDetection() and log an error message.
> The error messages are stored in a bounded list, so the last N error messages can be retrieved, e.g. via probe.sh.
> A rule should be able to be invoked manually, e.g. via probe.
> SUPERVISOR could be configured with a file which lists the rules to be created (class name, interval, description etc) at startup.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months