[JBoss JIRA] (WFLY-5239) XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5239?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reopened WFLY-5239:
----------------------------------
Test case is still ignored: reopening to unignore.
> XSiteSimpleTestCase.testPutRelayedToBackups intermittently fails in ~5% cases with "no physical address for"
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5239
> URL: https://issues.jboss.org/browse/WFLY-5239
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> I have done some work to stabilize this test a little more by switching both stacks (default stack and the bridge stack) to tcp. This does not help the test completely, it still fails with the well known:
> {noformat}
> rhusar [0m[0m15:14:52,808 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "xsite.war" (runtime-name : "xsite.war")
> [0mExecuting HTTP request: http://[::1]:8080/xsite/cache?operation=put&key=a&value=100
> [33m15:14:53,513 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:55,581 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:57,583 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:14:59,584 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:01,585 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:03,277 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site NYC: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from NYC (sync, timeout=10000)
> [0mExecuted HTTP request
> [33m15:15:03,586 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message
> [0m[33m15:15:05,591 WARNING [org.jgroups.protocols.TCP] (TransferQueueBundler,ee,LON-1) JGRP000032: LON-1: no physical address for a9d43ee2-698a-fbab-2ed8-fb54009f7af4, dropping message 17:02
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6882 at 8/16/16 1:15 PM:
-------------------------------------------------------------
[~elguardian] The truth is that, as currently implemented, the ejb-client topology and ejb deployments are intrinsically related. While it's true that the topology does not contain any information about what is deployed, what is deployed determines the topology. The client mappings registry service (which drives the topology reported to the ejb client) starts in response to an ejb deployment. If an ejb deployment is not started (because it was deployed as a singleton service, and that node is not the primary singleton provider), then the client mappings registry responsible for driving ejb client topology will not start.
This was done this way by design, so that the ejb client doesn't attempt to connect to node to which nothing is deployed - however, we can certainly discuss changing this, such that the requisite services start actively (instead of on demand).
was (Author: pferraro):
[~elguardian] The truth is that the ejb-client topology and ejb deployments are intrinsically related. While it's true that the topology does not contain any information about what is deployed, what is deployed determines the topology. The client mappings registry service (which drives the topology reported to the ejb client) starts in response to an ejb deployment. If an ejb deployment is not started (because it was deployed as a singleton service, and that node is not the primary singleton provider), then the client mappings registry responsible for driving ejb client topology is not started.
This was done this way by design, so that the ejb client doesn't attempt to connect to node to which nothing is deployed - however, we can certainly discuss changing this, such that the requisite services start actively (instead of on demand).
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6882:
------------------------------------
[~elguardian] The truth is that the ejb-client topology and ejb deployments are intrinsically related. While it's true that the topology does not contain any information about what is deployed, what is deployed determines the topology. The client mappings registry service (which drives the topology reported to the ejb client) starts in response to an ejb deployment. If an ejb deployment is not started (because it was deployed as a singleton service, and that node is not the primary singleton provider), then the client mappings registry responsible for driving ejb client topology is not started.
This was done this way by design, so that the ejb client doesn't attempt to connect to node to which nothing is deployed - however, we can certainly discuss changing this, such that the requisite services start actively (instead of on demand).
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1720) Migrate ModelControllerMBeanTestCase from wildfly test suite to core test suite
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1720:
-----------------------------------------
Summary: Migrate ModelControllerMBeanTestCase from wildfly test suite to core test suite
Key: WFCORE-1720
URL: https://issues.jboss.org/browse/WFCORE-1720
Project: WildFly Core
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 3.0.0.Alpha4
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Priority: Minor
Brian Stansberry: please copy ModelControllerMBeanTestCase from full into core
it uses a sar deployment but that can be converted to a ServiceActivator deployment as core doesn't support .sar
then all the methods in the copy of the test in full except testAllMBeanInfos() can be removed
all this, besides getting the test in a better spot, will remove the need to simultaneously upgrade core and fix the test in full
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6431) NPE when suspending server with MDB deployed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6431?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6431:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> NPE when suspending server with MDB deployed
> --------------------------------------------
>
> Key: WFLY-6431
> URL: https://issues.jboss.org/browse/WFLY-6431
> Project: WildFly
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Fix For: 11.0.0.Alpha1
>
> Attachments: ARTEMIS-459.patch
>
>
> I have simple MDB deployed and when calling suspend on server, the suspend operation fails with NPE [1].
> Steps to reproduce:
> 1) Start EAP 7.0.0.ER4 with deployed MDB - don't create corresponding queue
> 2) call suspend operation via jboss-cli
> 3) operation fails with NPE.
> Note with EAP 7.0.0.ER3 it works just fine => it is regression in comparison to EAP 7.0.0.ER3.
> [1]
> {noformat}
> 12:07:43,057 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0190: Step handler org.jboss.as.server.operations.ServerShutdownHandler$1@5ef6ed4e for operation {"operation" => "shutdown","operation-headers" => {"caller-type" => "user","access-mechanism" => "NATIVE"},"address" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.teardown(ActiveMQActivation.java:388)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.stop(ActiveMQActivation.java:293)
> at org.apache.activemq.artemis.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:195)
> at org.jboss.jca.core.rar.EndpointImpl.deactivate(EndpointImpl.java:255)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.deactivate(MessageDrivenComponent.java:267)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.access$100(MessageDrivenComponent.java:62)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent$1.preSuspend(MessageDrivenComponent.java:91)
> at org.jboss.as.server.suspend.SuspendController.suspend(SuspendController.java:72)
> at org.jboss.as.server.operations.ServerShutdownHandler$1$1.handleResult(ServerShutdownHandler.java:144)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1301)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1719) Wildfly 10.1.0.CR1 does not start as a windows service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1719?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1719:
--------------------------------
Workaround Description:
Workaround / fix is to open service.bat file
and locate
{{set DESCRIPTION="WildFly Application Server"}}
and replace it with
{{set DESCRIPTION=WildFly Application Server}}
was:
Workaround / fix is to open script.bat file
and locate
{{set DESCRIPTION="WildFly Application Server"}}
and replace it with
{{set DESCRIPTION=WildFly Application Server}}
> Wildfly 10.1.0.CR1 does not start as a windows service
> ------------------------------------------------------
>
> Key: WFCORE-1719
> URL: https://issues.jboss.org/browse/WFCORE-1719
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.2.0.Final
> Environment: Windows 8/Windows Server 2012
> Oracle Java 8
> Reporter: Anton Yudin
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha6
>
>
> Wildfly fails to start as a windows service.
> Installation works fine:
> {code}
> .\service.bat install
> Using the X86-64bit version of prunsrv
> "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown"
> Service Wildfly installed
> {code}
> Windows reports this error:
> {quote}
> Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
> {quote}
> {code}
> Event log report:
> The Wildfly service terminated with the following service-specific error:
> Incorrect function.
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager"/>
> <EventID Qualifiers="49152">7024</EventID>
> <Version>0</Version>
> <Level>2</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8080000000000000</Keywords>
> <TimeCreated SystemTime="2016-08-13T21:40:42.402218400Z"/>
> <EventRecordID>196500</EventRecordID>
> <Correlation/>
> <Execution ProcessID="668" ThreadID="10184"/>
> <Channel>System</Channel>
> <Computer>ITPC7.intra.rfgh.net</Computer>
> <Security/>
> </System>
> -
> <EventData>
> <Data Name="param1">Wildfly</Data>
> <Data Name="param2">%%1</Data>
> <Binary>570069006C00640066006C0079000000</Binary>
> </EventData>
> </Event>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1719) Wildfly 10.1.0.CR1 does not start as a windows service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1719?page=com.atlassian.jira.plugi... ]
Tomaz Cerar resolved WFCORE-1719.
---------------------------------
Fix Version/s: 3.0.0.Alpha6
Resolution: Done
> Wildfly 10.1.0.CR1 does not start as a windows service
> ------------------------------------------------------
>
> Key: WFCORE-1719
> URL: https://issues.jboss.org/browse/WFCORE-1719
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.2.0.Final
> Environment: Windows 8/Windows Server 2012
> Oracle Java 8
> Reporter: Anton Yudin
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha6
>
>
> Wildfly fails to start as a windows service.
> Installation works fine:
> {code}
> .\service.bat install
> Using the X86-64bit version of prunsrv
> "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown"
> Service Wildfly installed
> {code}
> Windows reports this error:
> {quote}
> Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
> {quote}
> {code}
> Event log report:
> The Wildfly service terminated with the following service-specific error:
> Incorrect function.
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager"/>
> <EventID Qualifiers="49152">7024</EventID>
> <Version>0</Version>
> <Level>2</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8080000000000000</Keywords>
> <TimeCreated SystemTime="2016-08-13T21:40:42.402218400Z"/>
> <EventRecordID>196500</EventRecordID>
> <Correlation/>
> <Execution ProcessID="668" ThreadID="10184"/>
> <Channel>System</Channel>
> <Computer>ITPC7.intra.rfgh.net</Computer>
> <Security/>
> </System>
> -
> <EventData>
> <Data Name="param1">Wildfly</Data>
> <Data Name="param2">%%1</Data>
> <Binary>570069006C00640066006C0079000000</Binary>
> </EventData>
> </Event>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1719) Wildfly 10.1.0.CR1 does not start as a windows service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1719?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1719:
--------------------------------
Component/s: Scripts
Workaround Description:
Workaround / fix is to open script.bat file
and locate
{{set DESCRIPTION="WildFly Application Server"}}
and replace it with
{{set DESCRIPTION=WildFly Application Server}}
Workaround: Workaround Exists
> Wildfly 10.1.0.CR1 does not start as a windows service
> ------------------------------------------------------
>
> Key: WFCORE-1719
> URL: https://issues.jboss.org/browse/WFCORE-1719
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.2.0.Final
> Environment: Windows 8/Windows Server 2012
> Oracle Java 8
> Reporter: Anton Yudin
> Assignee: Tomaz Cerar
>
> Wildfly fails to start as a windows service.
> Installation works fine:
> {code}
> .\service.bat install
> Using the X86-64bit version of prunsrv
> "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown"
> Service Wildfly installed
> {code}
> Windows reports this error:
> {quote}
> Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
> {quote}
> {code}
> Event log report:
> The Wildfly service terminated with the following service-specific error:
> Incorrect function.
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager"/>
> <EventID Qualifiers="49152">7024</EventID>
> <Version>0</Version>
> <Level>2</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8080000000000000</Keywords>
> <TimeCreated SystemTime="2016-08-13T21:40:42.402218400Z"/>
> <EventRecordID>196500</EventRecordID>
> <Correlation/>
> <Execution ProcessID="668" ThreadID="10184"/>
> <Channel>System</Channel>
> <Computer>ITPC7.intra.rfgh.net</Computer>
> <Security/>
> </System>
> -
> <EventData>
> <Data Name="param1">Wildfly</Data>
> <Data Name="param2">%%1</Data>
> <Binary>570069006C00640066006C0079000000</Binary>
> </EventData>
> </Event>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1719) Wildfly 10.1.0.CR1 does not start as a windows service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1719?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-6953 to WFCORE-1719:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1719 (was: WFLY-6953)
Affects Version/s: 2.2.0.Final
(was: 10.1.0.CR1)
> Wildfly 10.1.0.CR1 does not start as a windows service
> ------------------------------------------------------
>
> Key: WFCORE-1719
> URL: https://issues.jboss.org/browse/WFCORE-1719
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.2.0.Final
> Environment: Windows 8/Windows Server 2012
> Oracle Java 8
> Reporter: Anton Yudin
> Assignee: Tomaz Cerar
>
> Wildfly fails to start as a windows service.
> Installation works fine:
> {code}
> .\service.bat install
> Using the X86-64bit version of prunsrv
> "C:\applications\wildfly-10.1.0.CR1-test\bin\service\amd64\wildfly-service" install Wildfly --DisplayName=WildFly --Description=""WildFly Application Server"" --LogLevel=INFO --LogPath="C:\applications\wildfly-10.1.0.CR1-test\standalone\log" --LogPrefix=service --StdOutput=auto --StdError=auto --StartMode=exe --Startup=manual --StartImage=cmd.exe --StartPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StartParams="/c#set#NOPAUSE=Y#&&#standalone.bat#-Djboss.server.base.dir=C:\applications\wildfly-10.1.0.CR1-test\standalone#--server-config=standalone.xml" --StopMode=exe --StopImage=cmd.exe --StopPath="C:\applications\wildfly-10.1.0.CR1-test\bin" ++StopParams="/c jboss-cli.bat --controller=localhost:9990 --connect --command=:shutdown"
> Service Wildfly installed
> {code}
> Windows reports this error:
> {quote}
> Windows could not start the Wildfly on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1.
> {quote}
> {code}
> Event log report:
> The Wildfly service terminated with the following service-specific error:
> Incorrect function.
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager"/>
> <EventID Qualifiers="49152">7024</EventID>
> <Version>0</Version>
> <Level>2</Level>
> <Task>0</Task>
> <Opcode>0</Opcode>
> <Keywords>0x8080000000000000</Keywords>
> <TimeCreated SystemTime="2016-08-13T21:40:42.402218400Z"/>
> <EventRecordID>196500</EventRecordID>
> <Correlation/>
> <Execution ProcessID="668" ThreadID="10184"/>
> <Channel>System</Channel>
> <Computer>ITPC7.intra.rfgh.net</Computer>
> <Security/>
> </System>
> -
> <EventData>
> <Data Name="param1">Wildfly</Data>
> <Data Name="param2">%%1</Data>
> <Binary>570069006C00640066006C0079000000</Binary>
> </EventData>
> </Event>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months