[JBoss JIRA] (WFCORE-1201) Could not upload new deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1201:
------------------------------------------
By "stuff" I mean the actual encoded bits of the war file and the DMR op. There are multipart form sections and the Content-Disposition headers.
> Could not upload new deployment
> -------------------------------
>
> Key: WFCORE-1201
> URL: https://issues.jboss.org/browse/WFCORE-1201
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: 2 different machines
> Linux Debian Squeeze & Jessie
> Oracle Java SE 8
> Reporter: Claudio Weiler
> Assignee: Harald Pehl
>
> WildFly stop to accept deployments via interface upload with following stacktrace:
> ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203)
> at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 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.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Same artifact was used before with success, nothing changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1201) Could not upload new deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1201:
------------------------------------------
I'm going to ask our console guys to look at this, as the HAR output looks strange. I'm a noob when it comes to that but the postData.text output on the failed request doesn't look right to me. I don't seen stuff for the encoded file nor the encoded DMR op. Maybe that's not normal in a HAR; I don't know.
> Could not upload new deployment
> -------------------------------
>
> Key: WFCORE-1201
> URL: https://issues.jboss.org/browse/WFCORE-1201
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: 2 different machines
> Linux Debian Squeeze & Jessie
> Oracle Java SE 8
> Reporter: Claudio Weiler
>
> WildFly stop to accept deployments via interface upload with following stacktrace:
> ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203)
> at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 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.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Same artifact was used before with success, nothing changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1201) Could not upload new deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1201:
----------------------------------------
Assignee: Harald Pehl
> Could not upload new deployment
> -------------------------------
>
> Key: WFCORE-1201
> URL: https://issues.jboss.org/browse/WFCORE-1201
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: 2 different machines
> Linux Debian Squeeze & Jessie
> Oracle Java SE 8
> Reporter: Claudio Weiler
> Assignee: Harald Pehl
>
> WildFly stop to accept deployments via interface upload with following stacktrace:
> ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203)
> at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> 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.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 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)
> Same artifact was used before with success, nothing changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5859) NPE in Infinispan when unmarshalling
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-5859:
-----------------------------------
Summary: NPE in Infinispan when unmarshalling
Key: WFLY-5859
URL: https://issues.jboss.org/browse/WFLY-5859
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Ladislav Thon
Assignee: Paul Ferraro
In a job {{eap-7x-failover-db-session-shutdown-repl-sync-sybase}} (i.e., a REPL_SYNC failover test where sessions are stored in a Sybase database, but I'm not sure how significant is that), I've seen these NPEs thrown in Infinispan:
{code}
12:27:25,723 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread--p6-t6) ISPN000136: Error executing command PrepareCommand, writing keys []: java.lang.NullPointerException
at org.infinispan.commons.marshall.AbstractMarshaller.objectFromInputStream(AbstractMarshaller.java:91)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromInputStream(AbstractDelegatingMarshaller.java:60)
at org.infinispan.persistence.jdbc.JdbcUtil.unmarshall(JdbcUtil.java:67)
at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.unmarshallBucket(JdbcBinaryStore.java:639)
at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.loadBucket(JdbcBinaryStore.java:543)
at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:579)
at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:131)
at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:488)
at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:386)
at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:330)
at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:73)
at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:292)
at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:125)
at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:111)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:105)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:89)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:97)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:144)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:39)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:239)
at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:88)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:172)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.commands.tx.PrepareCommand.perform(PrepareCommand.java:96)
at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
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)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5571) Intermittent failure in ModelPersistenceTestCase.testSimpleOperation
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5571?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-5571.
-----------------------------
Resolution: Done
I am closing this issue as the original problem was addressed.
but we have problem occasional with file locks on windows that cause testsuite failures.
I have cloned this issue to WFLY-5571 to address that.
> Intermittent failure in ModelPersistenceTestCase.testSimpleOperation
> --------------------------------------------------------------------
>
> Key: WFLY-5571
> URL: https://issues.jboss.org/browse/WFLY-5571
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR3
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
> Fix For: 10.0.0.CR5
>
>
> ModelPersistenceTestCase.testSimpleOperation occasionally fails with the following pattern:
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.management.api.ModelPersistenceTestCase.testSimpleOperation(ModelPersistenceTestCase.java:119)
> ------- Stdout: -------
> 14:06:18,604 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml
> at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:552)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:65)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:780)
> 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:1336)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> 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:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
> 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)
> Caused by: java.nio.file.FileSystemException: C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\standalone.last.xml: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165)
> at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278)
> at java.nio.file.Files.copy(Files.java:1274)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.copyFile(FilePersistenceUtils.java:73)
> at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:550)
> ... 23 more
> {code}
> The test fails because the standalone.last.xml file isn't being updated as expected; the file isn't updated due to the "The process cannot access the file because it is being used by another process" IOException.
> 3 generally possibilities come to mind:
> 1) There's some other process on the CI server that really is using the file. Something like antivirus that touches lots of files briefly. (Not suggesting its actually AV.) It's odd we don't get other failures though; e.g. failures to persist the main config file.
> 2) It's the test driver process that's holding the file, conflicting with the server process. This is certainly possible. I've looked though and the test driver seems to be correct in terms of how it handles the file, reading it to calculate a CRC and then closing the stream used to do that in a finally block. It's also odd that this would only happen on Windows CI. Still, since we know we have 2 processes, test driver and server, both touching a file and we are getting an exception about 2 processes conflicting over that file, something in this area seems most likely.
> 3) There's some flaw in ConfigurationFile itself. But it's odd that a flaw there would produce an exception talking about how the file "is being used by another process".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5858) Testsuite on windows sometimes fails with file locks on standalone-*.xml
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-5858:
---------------------------------
Summary: Testsuite on windows sometimes fails with file locks on standalone-*.xml
Key: WFLY-5858
URL: https://issues.jboss.org/browse/WFLY-5858
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 10.0.0.CR3
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Fix For: 10.0.0.CR5
ModelPersistenceTestCase.testSimpleOperation occasionally fails with the following pattern:
{code}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at org.jboss.as.test.integration.management.api.ModelPersistenceTestCase.testSimpleOperation(ModelPersistenceTestCase.java:119)
------- Stdout: -------
14:06:18,604 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml
at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:552)
at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:65)
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:780)
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:1336)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
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:147)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
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)
Caused by: java.nio.file.FileSystemException: C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\standalone.last.xml: The process cannot access the file because it is being used by another process.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165)
at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278)
at java.nio.file.Files.copy(Files.java:1274)
at org.jboss.as.controller.persistence.FilePersistenceUtils.copyFile(FilePersistenceUtils.java:73)
at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:550)
... 23 more
{code}
The test fails because the standalone.last.xml file isn't being updated as expected; the file isn't updated due to the "The process cannot access the file because it is being used by another process" IOException.
3 generally possibilities come to mind:
1) There's some other process on the CI server that really is using the file. Something like antivirus that touches lots of files briefly. (Not suggesting its actually AV.) It's odd we don't get other failures though; e.g. failures to persist the main config file.
2) It's the test driver process that's holding the file, conflicting with the server process. This is certainly possible. I've looked though and the test driver seems to be correct in terms of how it handles the file, reading it to calculate a CRC and then closing the stream used to do that in a finally block. It's also odd that this would only happen on Windows CI. Still, since we know we have 2 processes, test driver and server, both touching a file and we are getting an exception about 2 processes conflicting over that file, something in this area seems most likely.
3) There's some flaw in ConfigurationFile itself. But it's odd that a flaw there would produce an exception talking about how the file "is being used by another process".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1233) Unable to specify alias for PKCS11 provider
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1233?page=com.atlassian.jira.plugi... ]
Martin Choma moved JBEAP-2434 to WFCORE-1233:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1233 (was: JBEAP-2434)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Security
(was: Security)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.4.Final
(was: 7.0.0.ER3)
> Unable to specify alias for PKCS11 provider
> -------------------------------------------
>
> Key: WFCORE-1233
> URL: https://issues.jboss.org/browse/WFCORE-1233
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 2.0.4.Final
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Unable to specify keystore alias for PKCS11 provider in SSL for security realm.
> Specifying keystore alias works only for JKS keystore as stated here:
> {code:xml}
> <xs:attribute name="alias" type="xs:string" use="optional">
> <xs:annotation>
> <xs:documentation>
> The alias of the entry to use from the keystore, if specified all remaining
> entries in the keystore will be ignored.
> Note: The use of aliases is only available for JKS based stores, for other store types this will be ignored.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ]
Jason Greene reassigned WFLY-5857:
----------------------------------
Assignee: Paul Ferraro (was: Jason Greene)
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5857
> URL: https://issues.jboss.org/browse/WFLY-5857
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
> Reporter: Serg Jakean19019
> Assignee: Paul Ferraro
>
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again.
> If Node2 ist started again, than Start is called in Node1 again.
> This Solution worked in 8.2.0.Final and was taken from GitHub
> Part of Log after Stop in Singletone:
> 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service.
> 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service
> 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c
> 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1]
> 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms)
> 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms)
> This issue also in:
> https://developer.jboss.org/thread/266831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-5857:
-------------------------------
Component/s: Clustering
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5857
> URL: https://issues.jboss.org/browse/WFLY-5857
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
> Reporter: Serg Jakean19019
> Assignee: Jason Greene
>
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again.
> If Node2 ist started again, than Start is called in Node1 again.
> This Solution worked in 8.2.0.Final and was taken from GitHub
> Part of Log after Stop in Singletone:
> 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service.
> 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service
> 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c
> 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1]
> 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms)
> 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms)
> This issue also in:
> https://developer.jboss.org/thread/266831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months