[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2494.
----------------------------
Release Notes Text: Fixed by using a later version
Resolution: Cannot Reproduce
> DNS_PING and failed probes
> --------------------------
>
> Key: JGRP-2494
> URL: https://issues.redhat.com/browse/JGRP-2494
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.9
> Reporter: Dewayne McNair
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGRP-2494.txt
>
>
> Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by José Fernando Tepedino Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ]
José Fernando Tepedino Martins updated WFLY-13697:
--------------------------------------------------
Description:
With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
For example, a job listener or other job artifact with the following code
{code:java}
@Resource(lookup="java:app/AppName")
private String applicationName;{code}
or
{code:java}
private String applicationName;
@PostConstruct
protected void initialize() throws NamingException {
applicationName = InitialContext.doLookup("java:app/AppName");
}{code}
when the batch job is started from JBoss CLI, the following error will be logged:
{code:java}
javax.naming.NameNotFoundException: java:app/AppName
{code}
was:
With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
For example, a job listener or other artifact with the following code
{code:java}
@Resource(lookup="java:app/AppName")
private String applicationName;{code}
or
{code:java}
private String applicationName;
@PostConstruct
protected void initialize() throws NamingException {
applicationName = InitialContext.doLookup("java:app/AppName");
}{code}
when the batch job is started from JBoss CLI, the following error will be logged:
{code:java}
javax.naming.NameNotFoundException: java:app/AppName
{code}
> JBoss CLI can't find java:app/AppName
> -------------------------------------
>
> Key: WFLY-13697
> URL: https://issues.redhat.com/browse/WFLY-13697
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: José Fernando Tepedino Martins
> Assignee: Jean Francois Denise
> Priority: Minor
> Labels: CLI, JNDI
>
> With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
> For example, a job listener or other job artifact with the following code
> {code:java}
> @Resource(lookup="java:app/AppName")
> private String applicationName;{code}
> or
> {code:java}
> private String applicationName;
> @PostConstruct
> protected void initialize() throws NamingException {
> applicationName = InitialContext.doLookup("java:app/AppName");
> }{code}
> when the batch job is started from JBoss CLI, the following error will be logged:
> {code:java}
> javax.naming.NameNotFoundException: java:app/AppName
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName
by José Fernando Tepedino Martins (Jira)
José Fernando Tepedino Martins created WFLY-13697:
-----------------------------------------------------
Summary: JBoss CLI can't find java:app/AppName
Key: WFLY-13697
URL: https://issues.redhat.com/browse/WFLY-13697
Project: WildFly
Issue Type: Bug
Components: CLI
Affects Versions: JBoss AS7 7.2.0.Final
Reporter: José Fernando Tepedino Martins
Assignee: Jean Francois Denise
With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'.
For example, a job listener or other artifact with the following code
{code:java}
@Resource(lookup="java:app/AppName")
private String applicationName;{code}
or
{code:java}
private String applicationName;
@PostConstruct
protected void initialize() throws NamingException {
applicationName = InitialContext.doLookup("java:app/AppName");
}{code}
when the batch job is started from JBoss CLI, the following error will be logged:
{code:java}
javax.naming.NameNotFoundException: java:app/AppName
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13433 at 7/23/20 5:15 PM:
---------------------------------------------------------------------
The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) which is now required by the remote resource in the ejb3 subsystem via a capability reference, and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class.
was (Author: rachmato):
The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class.
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13433 at 7/23/20 5:14 PM:
---------------------------------------------------------------------
I'm running into a problem with the LegacyConfigXTestSuite tests in the mixed-domain testsuite module, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities.
These tests do the following:
* start a master HC and slave HC using a given domain.xml file
* for each profile p in \{default, ha, full, full-ha} from the domain.xml file:
** start a server using profile p and wait for it to start
** check it has the correct profile name
** check we can connect via HTTP
** clean up the server
An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640.
The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests.
This is a mystery to me. [~yersan], [~brian.stansberry] any ideas?
NOTE: please ignore the last comment, I was getting tangled up with operation execution and capability validation.
was (Author: rachmato):
I'm running into a problem with the LegacyConfigXTestSuite tests in the mixed-domain testsuite module, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities.
These tests do the following:
* start a master HC and slave HC using a given domain.xml file
* for each profile p in \{default, ha, full, full-ha} from the domain.xml file:
** start a server using profile p and wait for it to start
** check it has the correct profile name
** check we can connect via HTTP
** clean up the server
An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640.
The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests.
This is a mystery to me. [~yersan], [~brian.stansberry] any ideas?
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13433:
--------------------------------------------
The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class.
> Improve capability support in EJB3 subsystem
> --------------------------------------------
>
> Key: WFLY-13433
> URL: https://issues.redhat.com/browse/WFLY-13433
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 20.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt
>
>
> Survey all external subsystem dependencies and introduce capability based dependencies where required.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (WFLY-13696) [GSS](7.3.z) UT000065: SSL must be specified to connect to a https URL when using ejb over https
by Flavia Rainone (Jira)
Flavia Rainone created WFLY-13696:
-------------------------------------
Summary: [GSS](7.3.z) UT000065: SSL must be specified to connect to a https URL when using ejb over https
Key: WFLY-13696
URL: https://issues.redhat.com/browse/WFLY-13696
Project: WildFly
Issue Type: Bug
Reporter: Flavia Rainone
Assignee: Tomasz Adamski
UT000065: SSL must be specified to connect to a https URL when using ejb over https
There is an XA Recovery Issue when EJB over HTTPS is used.
If an XA transaction fails, when the server is restarted it will find the standalone/data/ejb-xa-recovery files to recover, and the xa recovery runs it will hit this exception below.
./bin/standalone.sh -Djavax.net.ssl.trustStore=./standalone/configuration/application.keystore -Djavax.net.ssl.trustStorePassword=password -DRecoveryEnvironmentBean.periodicRecoveryPeriod=10
cat standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffc0a80141066cd6715eb1b1420000001131_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
https://localhost:8443/wildfly-services
{code}
14:38:10,855 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: UT000065: SSL must be specified to connect to a https URL
at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:213)
at org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:209)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: java.io.IOException: UT000065: SSL must be specified to connect to a https URL
at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:72)
at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:60)
at io.undertow.client.UndertowClient.connect(UndertowClient.java:137)
at org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:151)
at org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83)
at org.wildfly.httpclient.common.HttpTargetContext.sendRequest(HttpTargetContext.java:142)
at org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:73)
... 7 more
14:38:20,860 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:738)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:519)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:270)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:816)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month