[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar
by Justin Goldsmith (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ]
Justin Goldsmith edited comment on DROOLS-1008 at 8/17/16 12:37 AM:
--------------------------------------------------------------------
[~mfusco]
[~andrew.collins]
Any status on this. I am able to duplicate this error and have to clear out my local .m2 before the snapshot gets updated in business-central on a deployment.
I have the update policy set to always in my settings.xml so I am pretty sure everything is configured correctly
My scenario is slightly different but basically the same
build and deploy kjar to remote nexus - using a seperate settings.xml for this build and a seprate local reposiotry as to not conflict with what BC is using
deploy GAV to BC
The deployment is still the old snapshot
was (Author: jgoldsmith613):
[~mfusco]
[~andrew.collins]
Any status on this. I am able to duplicate this error and have to clear out my local .m2 before the snapshot gets updated in business-central on a deployment.
I have the update policy set to always in my settings.xml so I am pretty sure everything is configured correctly
> KieServer to update container for SNAPSHOT kjar
> -----------------------------------------------
>
> Key: DROOLS-1008
> URL: https://issues.jboss.org/browse/DROOLS-1008
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Andrew Collins
> Assignee: Mario Fusco
> Attachments: snapshot_kjar_reproducer.patch
>
>
> General:
> When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
> Steps to reproduce:
> * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
> * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
> * Start KieServer (verify new snapshot version is pulled from remote)
> * Deploy new kjar snapnshot. (unique version "2")
> Expected behavior:
> * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
> Actual Behavior
> * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
> Workaround:
> * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
> * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar
by Justin Goldsmith (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ]
Justin Goldsmith commented on DROOLS-1008:
------------------------------------------
[~mfusco]
[~andrew.collins]
Any status on this. I am able to duplicate this error and have to clear out my local .m2 before the snapshot gets updated in business-central on a deployment.
I have the update policy set to always in my settings.xml so I am pretty sure everything is configured correctly
> KieServer to update container for SNAPSHOT kjar
> -----------------------------------------------
>
> Key: DROOLS-1008
> URL: https://issues.jboss.org/browse/DROOLS-1008
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Andrew Collins
> Assignee: Mario Fusco
> Attachments: snapshot_kjar_reproducer.patch
>
>
> General:
> When a kjar has a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup, regardless of settings.xml snapshot updatePolicy setting. Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
> Steps to reproduce:
> * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
> * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
> * Start KieServer (verify new snapshot version is pulled from remote)
> * Deploy new kjar snapnshot. (unique version "2")
> Expected behavior:
> * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
> Actual Behavior
> * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
> Workaround:
> * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
> * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering integration tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6965?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6965:
--------------------------------------
I have analyzed and enabled 5 cases in a PR https://github.com/wildfly/wildfly/pull/9131
RemoteFailoverTestCase already has PR submitted since 2015.
Fine/CoarseSessionPassivationTestCase fail intermittently probably due to Infinispan issue.
> Audit @Ignore-d clustering integration tests
> --------------------------------------------
>
> Key: WFLY-6965
> URL: https://issues.jboss.org/browse/WFLY-6965
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
> {noformat}
> [rhusar@syrah clustering]$ git grep @Ignore
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
> src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering integration tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6965?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6965 at 8/16/16 6:51 PM:
---------------------------------------------------------------
Analyzed and enabled 5 cases in a PR https://github.com/wildfly/wildfly/pull/9131
RemoteFailoverTestCase already has PR submitted since 2015.
Fine/CoarseSessionPassivationTestCase fail intermittently probably due to Infinispan issue.
was (Author: rhusar):
I have analyzed and enabled 5 cases in a PR https://github.com/wildfly/wildfly/pull/9131
RemoteFailoverTestCase already has PR submitted since 2015.
Fine/CoarseSessionPassivationTestCase fail intermittently probably due to Infinispan issue.
> Audit @Ignore-d clustering integration tests
> --------------------------------------------
>
> Key: WFLY-6965
> URL: https://issues.jboss.org/browse/WFLY-6965
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
> {noformat}
> [rhusar@syrah clustering]$ git grep @Ignore
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
> src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-835) @Resource UserTransaction error when file passivation store is selected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on WFLY-835:
-------------------------------------
The change that went in for JBTM-2449 with changelog https://github.com/jbosstm/jboss-transaction-spi/commit/82a089300e3298ed6... gives out false promise of serializability as ServerVMClientUserTransaction's fields are not serializable.
Current stack trace:
{noformat}
Caused by: org.infinispan.commons.marshall.NotSerializableException: org.jboss.tm.usertx.UserTransactionRegistry
Caused by: an exception which occurred:
in field registry
in field transaction
in field instance
in field instance
in object java.util.concurrent.ConcurrentHashMap@491f1c2f
in object org.wildfly.clustering.ejb.infinispan.group.InfinispanBeanGroupEntry@25b0d1c3
in object org.infinispan.commands.write.PutKeyValueCommand@d8752047
in object org.infinispan.commands.tx.PrepareCommand@4b44a59
{noformat}
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
> Key: WFLY-835
> URL: https://issues.jboss.org/browse/WFLY-835
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.CR2
> Environment: Ubuntu 11.10, Intel® Core™ i3-2120 CPU @ 3.30GHz × 4
> Reporter: Abraham Cabanillas Piera
> Priority: Critical
> Labels: jboss
> Attachments: serializationerr_server.log
>
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> ... 15 more
> Caused by: an exception which occurred:
> in field userTransaction
> in field instance
> in field instance
> in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl@6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
> <session-bean>
> <stateless>
> <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
> </stateless>
> <stateful default-access-timeout="10000" cache-ref="passivating"/>
> <singleton default-access-timeout="5000"/>
> </session-bean>
> <mdb>
> <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
> <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
> </mdb>
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
> <caches>
> <cache name="simple" aliases="NoPassivationCache"/>
> <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
> </caches>
> <passivation-stores>
> <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
> </passivation-stores>
> <async thread-pool-name="default"/>
> <timer-service thread-pool-name="default">
> <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
> </timer-service>
> <remote connector-ref="remoting-connector" thread-pool-name="default"/>
> <thread-pools>
> <thread-pool name="default">
> <max-threads count="100"/>
> <keepalive-time time="100" unit="milliseconds"/>
> </thread-pool>
> </thread-pools>
> <iiop enable-by-default="false" use-qualified-name="false"/>
> </subsystem>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1307:
----------------------------------------
Assignee: (was: Brian Stansberry)
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Fix For: 3.0.0.CR1
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1307) jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1307:
-------------------------------------
Fix Version/s: 3.0.0.CR1
> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1307
> URL: https://issues.jboss.org/browse/WFCORE-1307
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Fix For: 3.0.0.CR1
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed.
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone@localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at java.nio.file.Files.copy(Files.java:3004)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months