[JBoss JIRA] (WFCORE-4979) WFLYSRV0137: No deployment content with hash
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4979?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-4979:
------------------------------------------
The boot failure is expected given the state of the server installation (config referencing a file that is not in the content repo.) The question is how the server installation ended up in that state. James can comment more if this is wrong but AIUI earlier he'd been using the wildlfy maven plugin. The server.log (and I assume the standalone_xml_history) in the attached zip provides a quasi-record of what he'd been doing.
> WFLYSRV0137: No deployment content with hash
> --------------------------------------------
>
> Key: WFCORE-4979
> URL: https://issues.redhat.com/browse/WFCORE-4979
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: James Perkins
> Assignee: Jeff Mesnil
> Priority: Major
>
> I saw the following when attempting to start a server.
> {code}
> jperkins@localhost ~/servers/wildfly-19.1.0.Final $ ./bin/standalone.sh
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jperkins/servers/wildfly-19.1.0.Final
> JAVA: java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=com.yourkit,org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:43:21,055 INFO [org.jboss.modules] (main) JBoss Modules version 1.10.2.Final-SNAPSHOT
> 11:43:21,410 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.11.Final
> 11:43:21,421 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.3.Final
> 11:43:21,545 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) starting
> 11:43:22,184 INFO [org.wildfly.security] (ServerService Thread Pool -- 24) ELY00001: WildFly Elytron version 1.11.4.Final
> 11:43:22,703 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:43:22,774 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 37) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:43:22,815 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "simple-servlet.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 7e2e9824daa6775b04ed1eb5b012c7372f69c4a6 is available in the deployment content repository for deployment 'simple-servlet.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 11:43:22,823 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:43:22,853 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) stopped in 24ms
> {code}
> The deployment is there in the model, but doesn't appear to be in the file structure.
> {code}
> [standalone@embedded /] /deployment=simple-servlet.war:read-resource
> {
> "outcome" => "success",
> "result" => {
> "content" => [{
> "hash" => bytes {
> 0x7e, 0x2e, 0x98, 0x24, 0xda, 0xa6, 0x77, 0x5b,
> 0x04, 0xed, 0x1e, 0xb5, 0xb0, 0x12, 0xc7, 0x37,
> 0x2f, 0x69, 0xc4, 0xa6
> },
> "archive" => undefined
> }],
> "enabled" => true,
> "name" => "simple-servlet.war",
> "owner" => undefined,
> "persistent" => true,
> "runtime-name" => "simple-servlet.war",
> "subdeployment" => undefined,
> "subsystem" => undefined
> }
> }
> {code}
> I've zipped up the server in case it helps. https://www.dropbox.com/s/an9wj3n41vr0m30/failed-deployment-wildfly-19.1....
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Fearghal O Maolcatha (Jira)
[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ]
Fearghal O Maolcatha commented on WFLY-13498:
---------------------------------------------
I understand it's difficult to do much when you're not able to reproduce the problem yourself.
The issue is consistent in my app. The @Observes @Initialized idiom was used to eagerly load some CDI beans in our application. I've put in a workaround to get over this issue.
I'll try to dig into the issue a bit more in the coming days.
> @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
> --------------------------------------------------------------
>
> Key: WFLY-13498
> URL: https://issues.redhat.com/browse/WFLY-13498
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Fearghal O Maolcatha
> Assignee: Matěj Novotný
> Priority: Major
>
> I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.servlet.ServletContext;
> @ApplicationScoped
> public class FactoryLocator {
> public FactoryLocator() {
> System.out.println("In the constructor.........................");
> }
> private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
> System.out.println("Invoking the event observer method..................");
> }
> }
> {code}
> One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
> After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
> Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10173:
-----------------------------------
I've updated the tests to use async singleton business methods, to avoid the complication of client-side thread pool. All client requests will arrive at the ejb container around the same time, and all wait time will be tracked by ejb container. I kept the 50-ms sleep time inside the bean method, and changed number of client invocations from 4 to 3. I believe this setup should be able to guarantee a positive wait-time.
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 20.0.0.Final
>
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> 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.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4979) WFLYSRV0137: No deployment content with hash
by James Perkins (Jira)
James Perkins created WFCORE-4979:
-------------------------------------
Summary: WFLYSRV0137: No deployment content with hash
Key: WFCORE-4979
URL: https://issues.redhat.com/browse/WFCORE-4979
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: James Perkins
Assignee: Jeff Mesnil
I saw the following when attempting to start a server.
{code}
jperkins@localhost ~/servers/wildfly-19.1.0.Final $ ./bin/standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/jperkins/servers/wildfly-19.1.0.Final
JAVA: java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=com.yourkit,org.jboss.byteman -Djava.awt.headless=true
=========================================================================
11:43:21,055 INFO [org.jboss.modules] (main) JBoss Modules version 1.10.2.Final-SNAPSHOT
11:43:21,410 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.11.Final
11:43:21,421 INFO [org.jboss.threads] (main) JBoss Threads version 2.3.3.Final
11:43:21,545 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) starting
11:43:22,184 INFO [org.wildfly.security] (ServerService Thread Pool -- 24) ELY00001: WildFly Elytron version 1.11.4.Final
11:43:22,703 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/core-service=management/management-interface=http-interface' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
11:43:22,774 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 37) WFLYCTL0028: Attribute 'security-realm' in the resource at address '/subsystem=undertow/server=default-server/https-listener=https' is deprecated, and may be removed in a future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
11:43:22,815 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "simple-servlet.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 7e2e9824daa6775b04ed1eb5b012c7372f69c4a6 is available in the deployment content repository for deployment 'simple-servlet.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
11:43:22,823 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
11:43:22,853 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Full 19.1.0.Final (WildFly Core 11.1.1.Final) stopped in 24ms
{code}
The deployment is there in the model, but doesn't appear to be in the file structure.
{code}
[standalone@embedded /] /deployment=simple-servlet.war:read-resource
{
"outcome" => "success",
"result" => {
"content" => [{
"hash" => bytes {
0x7e, 0x2e, 0x98, 0x24, 0xda, 0xa6, 0x77, 0x5b,
0x04, 0xed, 0x1e, 0xb5, 0xb0, 0x12, 0xc7, 0x37,
0x2f, 0x69, 0xc4, 0xa6
},
"archive" => undefined
}],
"enabled" => true,
"name" => "simple-servlet.war",
"owner" => undefined,
"persistent" => true,
"runtime-name" => "simple-servlet.war",
"subdeployment" => undefined,
"subsystem" => undefined
}
}
{code}
I've zipped up the server in case it helps. https://www.dropbox.com/s/an9wj3n41vr0m30/failed-deployment-wildfly-19.1....
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13506) MicroProfile BOM missing from root README
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-13506:
--------------------------------------
Summary: MicroProfile BOM missing from root README
Key: WFLY-13506
URL: https://issues.redhat.com/browse/WFLY-13506
Project: WildFly
Issue Type: Enhancement
Components: BOM
Affects Versions: 19.1.0.Final
Reporter: Eduardo Martins
Assignee: Eduardo Martins
The MicroProfile BOM should be added to the WildFly BOMs repository's README.adoc.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (AG-140) Connection leak caused by failed transaction integration
by Luis Barreiro (Jira)
[ https://issues.redhat.com/browse/AG-140?page=com.atlassian.jira.plugin.sy... ]
Luis Barreiro resolved AG-140.
------------------------------
Fix Version/s: 1.9
Resolution: Done
Thanks for reporting Dimitry!
> Connection leak caused by failed transaction integration
> --------------------------------------------------------
>
> Key: AG-140
> URL: https://issues.redhat.com/browse/AG-140
> Project: Agroal
> Issue Type: Bug
> Components: narayana, pool
> Affects Versions: 1.8
> Reporter: Dmitry Telegin
> Assignee: Luis Barreiro
> Priority: Major
> Fix For: 1.9
>
> Attachments: agroal-connection-leak-poc.log
>
>
> If the following conditions are met:
> - transaction integration is installed;
> - connection checkout has been successful;
> - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception,
> then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion.
> The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active):
> {code:java}
> Foo foo = new Foo();
> try {
> em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted
> } catch (Exception e) {
> // suppress exception
> LOG.log(Level.WARNING, "merge", e);
> }
>
> // continue using the same EntityManager
> em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked
> {code}
> Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager afterwards), but it shouldn't lead to connection leaks either.
> The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month