[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ]
Amos Feng updated WFLY-5682:
----------------------------
Fix Version/s: 10.0.0.Final
> Can't define absolute path for object store location
> ----------------------------------------------------
>
> Key: WFLY-5682
> URL: https://issues.jboss.org/browse/WFLY-5682
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.Final
>
>
> As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible.
> If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2].
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 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)Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> {code}
> [2]
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13]
> Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters"
> at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205)
> at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit
by Sanne Grinovero (JIRA)
Sanne Grinovero created JGRP-1980:
-------------------------------------
Summary: Improve throughput under contention for FlowControl.Credit
Key: JGRP-1980
URL: https://issues.jboss.org/browse/JGRP-1980
Project: JGroups
Issue Type: Enhancement
Affects Versions: 3.6.6
Reporter: Sanne Grinovero
Assignee: Bela Ban
The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups.
Wondering if we can think of polishing the implementation, although it looks like challenging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5696) Mixed domain test launches a broken server from the DC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5696?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5696:
-----------------------------------
Description:
The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
However, WildcardReadsTestCase is asserting that the wildcard reads are able to read this server, so we need to decide how to proceed. Simply dropping the "server" element from host.xml doesn't work.
was:
The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
Our goal in these tests is to test how the old slaves handle stuff. We have other ways to test how new servers handle old stuff. So I'm going to remove the launch of this server from the DC config.
> Mixed domain test launches a broken server from the DC
> ------------------------------------------------------
>
> Key: WFLY-5696
> URL: https://issues.jboss.org/browse/WFLY-5696
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 10.0.0.CR4
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
> The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
> However, WildcardReadsTestCase is asserting that the wildcard reads are able to read this server, so we need to decide how to proceed. Simply dropping the "server" element from host.xml doesn't work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5696) Mixed domain test launches a broken server from the DC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5696?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5696:
-----------------------------------
Summary: Mixed domain test launches a broken server from the DC (was: Mixed domain test launches a server from the DC)
> Mixed domain test launches a broken server from the DC
> ------------------------------------------------------
>
> Key: WFLY-5696
> URL: https://issues.jboss.org/browse/WFLY-5696
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 10.0.0.CR4
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The host.xml used by the DC in the testsuite/mixed-domain tests is launching a server. This server fails to launch because the profiles being used include stuff that won't work on current version servers (i.e. legacy subsystems like web).
> The failure to launch the server isn't affecting the test results, proving the existence of the server is not relevant to the test assertions.
> Our goal in these tests is to test how the old slaves handle stuff. We have other ways to test how new servers handle old stuff. So I'm going to remove the launch of this server from the DC config.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-1363) Updating deployment with dependant
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-1363?page=com.atlassian.jira.plugin.... ]
Brad Maxwell resolved WFLY-1363.
--------------------------------
Fix Version/s: 8.0.0.Alpha1
Resolution: Done
> Updating deployment with dependant
> ----------------------------------
>
> Key: WFLY-1363
> URL: https://issues.jboss.org/browse/WFLY-1363
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: Windows 7 64bit, JBoss 7.2.0.Final
> Reporter: Bart Van Dosselaer
> Assignee: Jason Greene
> Labels: deployment
> Fix For: 8.0.0.Alpha1
>
> Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>
> This works fine, until I want to update base.ear.
>
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-1363) Updating deployment with dependant
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1363?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1363:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=924562
Bugzilla Update: Perform
> Updating deployment with dependant
> ----------------------------------
>
> Key: WFLY-1363
> URL: https://issues.jboss.org/browse/WFLY-1363
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: Windows 7 64bit, JBoss 7.2.0.Final
> Reporter: Bart Van Dosselaer
> Assignee: Jason Greene
> Labels: deployment
> Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>
> This works fine, until I want to update base.ear.
>
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-1363) Updating deployment with dependant
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-1363?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-1363:
------------------------------------
Fixed in EAP 6.3 and beyond - via https://bugzilla.redhat.com/show_bug.cgi?id=924562
> Updating deployment with dependant
> ----------------------------------
>
> Key: WFLY-1363
> URL: https://issues.jboss.org/browse/WFLY-1363
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: Windows 7 64bit, JBoss 7.2.0.Final
> Reporter: Bart Van Dosselaer
> Assignee: Jason Greene
> Labels: deployment
> Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>
> This works fine, until I want to update base.ear.
>
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months