[JBoss JIRA] (AS7-4277) Performance regression introduced in AS7-4205
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4277:
-----------------------------------
Summary: Performance regression introduced in AS7-4205
Key: AS7-4277
URL: https://issues.jboss.org/browse/AS7-4277
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: No Release
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.2.Final
After https://github.com/jbossas/jboss-as/pull/1869 we are seeing read time-outs on the clients and TimeoutException on the server.
{noformat}
[JBossINF] 12:46:55,011 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-5717,null) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [OKaB26plMWYsWpHQS+UmsJ7R] for requestor [GlobalTransaction:<perf21/web>:3592818:remote]! Lock held by [GlobalTransaction:<perf21/web>:3591864:remote]
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:204)
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:178)
[JBossINF] at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLock(LockManagerImpl.java:168)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockKeyAndCheckOwnership(AbstractTxLockingInterceptor.java:209)
[JBossINF] at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAndRegisterBackupLock(AbstractTxLockingInterceptor.java:136)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor$LockAcquisitionVisitor.visitPutKeyValueCommand(OptimisticLockingInterceptor.java:202)
[JBossINF] at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.acquireLocksVisitingCommands(OptimisticLockingInterceptor.java:262)
[JBossINF] at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitPrepareCommand(OptimisticLockingInterceptor.java:92)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:58)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:106)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.handleWithRetries(StateTransferLockInterceptor.java:208)
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:85)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130)
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:89)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
[JBossINF] at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70)
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131)
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345)
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:127)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
[JBossINF] at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221)
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201)
[JBossINF] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.RSVP.up(RSVP.java:181) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:882) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:595) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.BARRIER.up(BARRIER.java:102) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:282) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:358) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1174) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1722) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1704) [jgroups-3.0.8.Final.jar:3.0.8.Final]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-3658) NPE when starting a hornetQ backup server
by Emanuel Muckenhuber (JIRA)
Emanuel Muckenhuber created AS7-3658:
----------------------------------------
Summary: NPE when starting a hornetQ backup server
Key: AS7-3658
URL: https://issues.jboss.org/browse/AS7-3658
Project: Application Server 7
Issue Type: Bug
Components: JMS
Reporter: Emanuel Muckenhuber
Assignee: Andy Taylor
Fix For: 7.1.1.Final
When configuring a <hornetq-server /> with <backup>true</backup> - the service fails to start:
{code}
17:45:00,446 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.messaging.backup-server.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging.backup-server.jms.manager: java.lang.NullPointerException
at org.jboss.as.messaging.jms.JMSService.start(JMSService.java:80)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
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: java.lang.NullPointerException
at org.jboss.as.messaging.jms.JMSService.start(JMSService.java:74)
... 5 more
{code}
This affects e.g. docs/examples/configs/standalone-hornetq-colocated.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3437) SAXParseException configuring event listeners in spring
by Mario Fusco (JIRA)
Mario Fusco created JBRULES-3437:
------------------------------------
Summary: SAXParseException configuring event listeners in spring
Key: JBRULES-3437
URL: https://issues.jboss.org/browse/JBRULES-3437
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Part of my spring configuration:
<drools:ksession id="statefulSession" type="stateful" kbase="kbase1">
<drools:workingMemoryEventListener>
<bean class="org.drools.event.DebugWorkingMemoryEventListener"/>
</drools:workingMemoryEventListener>
<drools:processEventListener>
<bean class="org.drools.event.DebugProcessEventListener"/>
</drools:processEventListener>
</drools:ksession>
throws :
Caused by: org.xml.sax.SAXParseException; lineNumber: 15; columnNumber: 41;
cvc-complex-type.2.4.a: Invalid content was found starting with element
'drools:processEventListener'. One of
'{"http://drools.org/schema/drools-spring":workingMemoryEventListener,
"http://drools.org/schema/drools-spring":batch,
"http://drools.org/schema/drools-spring":script,
"http://drools.org/schema/drools-spring":configuration}' is expected.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:134)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:387)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:321)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:421)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3186)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1810)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:709)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:376)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2732)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:625)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:819)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:748)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at
com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:239)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:288)
at
org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75)
at
org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388)
But following configuration is OK:
<drools:ksession id="statefulSession" type="stateful" kbase="kbase1">
<drools:processEventListener>
<bean class="org.drools.event.DebugProcessEventListener"/>
</drools:processEventListener>
</drools:ksession>
Also this configuration is OK:
<drools:ksession id="statefulSession" type="stateful" kbase="kbase1">
<drools:workingMemoryEventListener>
<bean class="org.drools.event.DebugWorkingMemoryEventListener"/>
</drools:workingMemoryEventListener>
</drools:ksession>
Exception occurs only when both listeners are configured.
probably because of bad position of elements; when listeners configured inside
<drools:ksession> as shown above, current order required:
agendaEventListener
processEventListener
workingMemoryEventListener
but when configured through <drools:eventListeners> element and listeners
attribute in <drools:ksession> element, order of event listeners does not
matter. I think this is because of <xsd:all> resp. <xsd:sequence> inside
drools-spring.xsd.
It would by nice to unite both styles of configuration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3375) Adding ProcessEventListener throws NPE
by Mario Fusco (JIRA)
Mario Fusco created JBRULES-3375:
------------------------------------
Summary: Adding ProcessEventListener throws NPE
Key: JBRULES-3375
URL: https://issues.jboss.org/browse/JBRULES-3375
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mario Fusco
Description of problem:
When you try to add a ProcessEventListener to StatefulKnowledgeSession and you
are missing jBPM libraries on classpath, you get a NullPointerException.
Version-Release number of selected component (if applicable):
BRMS-5.3.0.dev5
Drools-5.3.0.Final
How reproducible:
Using attached reproducer.
Steps to Reproduce:
1. Make sure you don't have any jBPM libs on classpath
2. Create stateful session
3. Add ProcesEventListener (e.g. DebugProcessEventListener)
Actual results:
java.lang.NullPointerException
at
org.drools.impl.StatefulKnowledgeSessionImpl.addEventListener(StatefulKnowledgeSessionImpl.java:199)
at org.sample.TryProcessListener.main(TryProcessListener.java:20)
Expected results:
Either meaningful exception (like NojBPMException) or correct addition of
listener
Additional info:
It only affects StatefulKnowledgeSession, the StatefulKnowledgeSession runs
just fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4085) Improve testing of Infinispoan subsystem management features
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-4085:
----------------------------------------
Summary: Improve testing of Infinispoan subsystem management features
Key: AS7-4085
URL: https://issues.jboss.org/browse/AS7-4085
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.0.Final
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Fix For: 7.1.2.Final
We current use InfinispanSubsystemTest to test the integrity of the Infinispan subsystem implementation.
>From the documentation:
{noformat}
Tests the ability to create a model from an xml configuration, marshal the model back to xml, re-read that marshalled model
into a new model that matches the first one, execute a "describe" operation for the model, create yet another model
from executing the results of that describe operation, and compare that model to first model.
{noformat}
Over and above these tests, we need more specific tests which cover use cases such as:
- every attribute can be read/written as required and that the subsequent reload-required state is as expected
- operation sequences such as add/remove/add, add/add give expected results for all resources in the subsystem
- validating that the XML configuration specified gets translated into the desired Infinispan configuration
- and many others
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-3488) Make default-cache attribute of cache-container "eventually required" rather than required.
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created AS7-3488:
----------------------------------------
Summary: Make default-cache attribute of cache-container "eventually required" rather than required.
Key: AS7-3488
URL: https://issues.jboss.org/browse/AS7-3488
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 7.1.0.Final
Can we remove the restriction that default-cache must be set when you
create the cache-container? That way, I can just make it so the UI
forces them to set that value before calling the start operation. So
under that covers, the console does this:
{noformat}
<!-- user creates a new cache container without specifying default-cache. -->
/subsystem=infinispan/cache-container=X:add
<!-- for top-level cache container attributes, user sets them via write-attribute -->
/subsystem=infinispan/cache-container=X:write-attribute(name=jndi-name,value=W)
<!-- for nested nested cache-container attributes, user access them as an addressable resource and sets them via write-attribute -->
/subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=stack, value=udp)
/subsystem=infinispan/cache-container=X/transport=TRANSPORT:write-attribute(name=lock-timeout, value=100)
<!-- When user is ready to start the cache-container, prompt for default-cache if not set. -->
<!-- Then do these two as a batch -->
/subsystem=infinispan/cache-container=X:write-attribute(name=default-cache, value=Y)
/subsystem=infinispan/cache-container=X:start(mode=on-demand)
{noformat}
Any thoughts on this? The answer has great implications on the UI design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4015) init.d script, jboss-as/bin/init.d/jboss-as-standalone.sh tests for *executable* /etc/rc.d/init.d/functions
by Leo Breuss (JIRA)
Leo Breuss created AS7-4015:
-------------------------------
Summary: init.d script, jboss-as/bin/init.d/jboss-as-standalone.sh tests for *executable* /etc/rc.d/init.d/functions
Key: AS7-4015
URL: https://issues.jboss.org/browse/AS7-4015
Project: Application Server 7
Issue Type: Bug
Components: Documentation, Scripts
Affects Versions: 7.1.0.Final
Environment: CentOS 6.2 (netinstall, all default)
Reporter: Leo Breuss
Assignee: Brian Stansberry
Fix For: 7.1.1.Final
On CentOS 6 (and maybe other Distros too), the /etc/rc.d/init.d/functions has no executable flag set. The jboss init.d script itself sources it with ". /etc/rc.d/init.d/functions"
ll /etc/rc.d/init.d/functions
-rw-r--r--. 1 root root 18171 Oct 7 16:01 /etc/rc.d/init.d/functions
On line 89, the supplied init script jboss-as-standalone.sh does a check if /etc/rc.d/init.d/functions is executable.
So you might want to fix the jboss init.d script the following way:
# diff /opt/jboss-as/bin/init.d/jboss-as-standalone.sh /etc/init.d/jboss
89c89
< if [ -x /etc/rc.d/init.d/functions ]; then
---
> if [ -r /etc/rc.d/init.d/functions ]; then
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months