[JBoss JIRA] (AG-73) Change pool metrics implementation to use LongAccumulator
by Luis Barreiro (JIRA)
Luis Barreiro created AG-73:
-------------------------------
Summary: Change pool metrics implementation to use LongAccumulator
Key: AG-73
URL: https://issues.jboss.org/browse/AG-73
Project: Agroal
Issue Type: Enhancement
Components: pool
Affects Versions: 0.4
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 0.5
This changes semantics slightly, as the available metrics will be 'on-line' and not calculated on demand
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Marek Posolda commented on WFLY-10269:
--------------------------------------
Workaround: Restart SSO pod (the easiest is to do it by scale down number of pods to 0 and then back to 1). Complete re-deploy of SSO is fortunately not needed.
> 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)
8 years
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Marek Posolda updated WFLY-10269:
---------------------------------
Comment: was deleted
(was: Workaround: Restart SSO pod (the easiest is to do it by scale down number of pods to 0 and then back to 1). Complete re-deploy of SSO is fortunately not needed.)
> 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)
8 years
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev updated ELY-1295:
-------------------------------
Attachment: oracle_java_1.8.0.77_trace
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Peter Palaga
> Assignee: Priyanka Nag
> Priority: Critical
> Labels: ibm-java
> Fix For: 1.2.0.Beta12
>
> Attachments: oracle_java_1.8.0.77_trace
>
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev commented on ELY-1295:
------------------------------------
NoSuchAlgorithmException also occurs on old versions on Oracle JDK 8 like version 1.8.0_77 (see attached trace). The latest version 1.8.0_171 runs fine.
> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
> Key: ELY-1295
> URL: https://issues.jboss.org/browse/ELY-1295
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Peter Palaga
> Assignee: Priyanka Nag
> Priority: Critical
> Labels: ibm-java
> Fix For: 1.2.0.Beta12
>
> Attachments: oracle_java_1.8.0.77_trace
>
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT - tr.r14.java.green_20160818_122998
> GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> at java.lang.Class.forNameImpl(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> at java.security.KeyStore.getEntry(KeyStore.java:1532)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> ... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> ... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10109:
------------------------------------
thanks, your failure occurs when the RA on node2 tries to connect to Artemis on node1:
{code}
13:59:19,581 WARN [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ152005: Failure in broker activation org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@e77d2b4c destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:761) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:307) [artemis-ra-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:696) [artemis-ra-2.5.0.jar:2.5.0]
at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
at org.jboss.as.connector.services.workmanager.WildflyWorkWrapper.runWork(WildflyWorkWrapper.java:69)
at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:29)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:789)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:44)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:809)
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162]
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{code}
It is not an issue with JGroups as we have logs on node2 that says that nodes are in the same cluster:
{code}
13:58:17,574 INFO [org.infinispan.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
{code}
I'll investigate further why the RA on node2 does not receive the broadcast from node1.
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10269?page=com.atlassian.jira.plugin... ]
Marek Posolda updated WFLY-10269:
---------------------------------
Description:
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.
was:
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:
Socker 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 .
> 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)
8 years
[JBoss JIRA] (WFLY-10269) Option for RemoteStoreBuilder to send unresolved hostname to RemoteStoreConfigurationBuilder
by Marek Posolda (JIRA)
Marek Posolda created WFLY-10269:
------------------------------------
Summary: 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:
Socker 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 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years