[JBoss JIRA] (WFLY-10269) RemoteStore should use unresolved hostnames to accommodate dynamic environments
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10269:
---------------------------------------
[~kabirkhan] I noticed the title was misleading, implying like this would be a new option. Fixed the title now.
> RemoteStore should use unresolved hostnames to accommodate dynamic environments
> -------------------------------------------------------------------------------
>
> Key: WFLY-10269
> URL: https://issues.jboss.org/browse/WFLY-10269
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this:
> Socket binding in standalone-ha.xml
> {code}
> <outbound-socket-binding name="remote-cache">
> <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/>
> </outbound-socket-binding>
> {code}
> And remote-store something like this:
> {code}
> <replicated-cache name="work" mode="SYNC">
> <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
> </remote-store>
> </replicated-cache>
> {code}
> Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" .
> The issue is, that HotRod client won't be able to see this change and will still try to connect to old address.
> Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address.
> If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10269) RemoteStore should use unresolved hostnames to accommodate dynamic environments
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10269:
----------------------------------
Summary: RemoteStore should use unresolved hostnames to accommodate dynamic environments (was: Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder)
> RemoteStore should use unresolved hostnames to accommodate dynamic environments
> -------------------------------------------------------------------------------
>
> Key: WFLY-10269
> URL: https://issues.jboss.org/browse/WFLY-10269
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this:
> Socket binding in standalone-ha.xml
> {code}
> <outbound-socket-binding name="remote-cache">
> <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/>
> </outbound-socket-binding>
> {code}
> And remote-store something like this:
> {code}
> <replicated-cache name="work" mode="SYNC">
> <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
> </remote-store>
> </replicated-cache>
> {code}
> Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" .
> The issue is, that HotRod client won't be able to see this change and will still try to connect to old address.
> Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address.
> If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10280:
----------------------------------
Summary: Can't enable stateful EJB passivation when EJB remote service is removed (was: can't enable stateful EJB passivation when EJB remote service is removed)
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> Steps to reproduce:
> {code}
> unzip wildfly-12.0.0.Final.zip
> cd wildfly-12.0.0.Final
> cp tinyEjbPassivation.war standalone/deployments # any EJB deployment should do
> ./bin/jboss-cli.sh
> embed-server --admin-only --std-out=echo --server-config=standalone-full.xml
> /subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=passivating)
> /subsystem=ejb3/service=remote:remove
> reload --start-mode=normal
> {code}
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10286) Consider to add secmgr options to CLI and JDR
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-10286:
------------------------------------
Summary: Consider to add secmgr options to CLI and JDR
Key: WFLY-10286
URL: https://issues.jboss.org/browse/WFLY-10286
Project: WildFly
Issue Type: Bug
Components: CLI, Scripts
Reporter: Marek Kopecký
Assignee: Jean-Francois Denise
Wildfly standalone/domain/appclient scripts allows two ways for start EAP with security manager:
* -secmgr command line argument ({{./standalone.sh -secmgr}})
** This is described in documentation only in Configuration guide in "A.1. Server Runtime Arguments"
* SECMGR=true env property
** This is not described in documentation at all.
Does it make sence to add secmgr parameter to CLI script? CLI allows to start embedded server, and standalone.sh (non-embedded server) script has the secmgr option. Does it make sence to add secmgr parameter to the jdr script too? JDR tool uses embedded cli server too in some cases.
Cc: [~eduda], [~mnovak])
See [this my command|https://issues.jboss.org/browse/WFLY-10242?focusedCommentId=13561...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10269:
---------------------------------------
[~mposolda] any chance you would like to pretest this before merge?
> Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-10269
> URL: https://issues.jboss.org/browse/WFLY-10269
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this:
> Socket binding in standalone-ha.xml
> {code}
> <outbound-socket-binding name="remote-cache">
> <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/>
> </outbound-socket-binding>
> {code}
> And remote-store something like this:
> {code}
> <replicated-cache name="work" mode="SYNC">
> <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
> </remote-store>
> </replicated-cache>
> {code}
> Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" .
> The issue is, that HotRod client won't be able to see this change and will still try to connect to old address.
> Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address.
> If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10269:
---------------------------------------
[~kabirkhan] No changes to user configuration, its only delegating resolution from WildFly codebase into Infinispan which already supports this with ISPN-7955.
> Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-10269
> URL: https://issues.jboss.org/browse/WFLY-10269
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this:
> Socket binding in standalone-ha.xml
> {code}
> <outbound-socket-binding name="remote-cache">
> <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/>
> </outbound-socket-binding>
> {code}
> And remote-store something like this:
> {code}
> <replicated-cache name="work" mode="SYNC">
> <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
> </remote-store>
> </replicated-cache>
> {code}
> Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" .
> The issue is, that HotRod client won't be able to see this change and will still try to connect to old address.
> Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address.
> If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFLY-10269:
---------------------------------------
[~mposolda] is https://github.com/mposolda on GitHub.
> Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-10269
> URL: https://issues.jboss.org/browse/WFLY-10269
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Marek Posolda
> Assignee: Paul Ferraro
>
> Use-case: We have openshift environment with RHSSO server connected to JDG server through HotRod protocol. RHSSO is connected to JDG through the RemoteStore . Configuration on RHSSO side is like this:
> Socket binding in standalone-ha.xml
> {code}
> <outbound-socket-binding name="remote-cache">
> <remote-destination host="jdg-app-hotrod.infinispan.svc" port="11222"/>
> </outbound-socket-binding>
> {code}
> And remote-store something like this:
> {code}
> <replicated-cache name="work" mode="SYNC">
> <remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
> </remote-store>
> </replicated-cache>
> {code}
> Let's assume that JDG needs to be restarted. This usually causes that service "jdg-app-hotrod.infinispan.svc" will be available under different IP address. For example previous IP of "jdg-app-hotrod.infinispan.svc" is "172.30.247.78" . After restart, it is changed to "172.30.28.27" .
> The issue is, that HotRod client won't be able to see this change and will still try to connect to old address.
> Why?: The org.jboss.as.clustering.infinispan.subsystem.RemoteStoreBuilder method "accept" always pass resolved address to infinispan: https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/exte... . So infinispan will receive just static IP address.
> If there is an option for RemoteStoreBuilder to pass the "unresolved" hostname, it will help. Infinispan itself has support for "unresolved" dynamic hostnames thanks to the JIRA: ISPN-7955 , so it is already able to dynamically adapt to changed IP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months