[JBoss JIRA] (JGRP-1992) GOOGLE_PING discovery fails if port 443 isn't used
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1992?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1992:
---------------------------
Fix Version/s: 3.6.7
This might get pushed into 4.0, as I don't currently have acess to a GCE env. Also, we probably need to switch to the GCE native API, rather then subclassing {{S3_PING}}...
> GOOGLE_PING discovery fails if port 443 isn't used
> --------------------------------------------------
>
> Key: JGRP-1992
> URL: https://issues.jboss.org/browse/JGRP-1992
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Reporter: Alan Field
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> I was doing some testing with GCE, and I ran into the following issue. I have the following in my JGroups configuration file:
> <GOOGLE_PING access_key="access_key"
> secret_access_key="secret_access_key"
> location="jdg-cluster" />
> But I was getting the following exception when starting the JChannel:
> caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
> at org.jgroups.protocols.S3_PING$AWSAuthConnection.checkBucketExists(S3_PING.java:485)
> at org.jgroups.protocols.S3_PING.init(S3_PING.java:98)
> at org.jgroups.protocols.GOOGLE_PING.init(GOOGLE_PING.java:16)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:415)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:316)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:360)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420)
> at org.radargun.service.InfinispanEmbeddedService.startCaches(InfinispanEmbeddedService.java:119)
> at org.radargun.service.Infinispan51EmbeddedService.startCaches(Infinispan51EmbeddedService.java:100)
> at org.radargun.service.InfinispanLifecycle.start(InfinispanLifecycle.java:45)
> at org.radargun.service.InfinispanKillableLifecycle.start(InfinispanKillableLifecycle.java:51)
> at org.radargun.stages.lifecycle.LifecycleHelper.start(LifecycleHelper.java:59)
> at org.radargun.stages.lifecycle.ServiceStartStage.executeOnSlave(ServiceStartStage.java:83)
> at org.radargun.SlaveBase.scenarioLoop(SlaveBase.java:87)
> at org.radargun.SlaveBase$ScenarioRunner.run(SlaveBase.java:151)
> If I skip the check for the existence of the bucket, I get the same exception when trying to read or write the file. I worked around it by making GOOGLE_PING use the SSL port:
> <GOOGLE_PING access_key="access_key"
> secret_access_key="secret_access_key"
> location="jdg-cluster"
> port="443" />
> I have looked at the docs for migrating from S3 to Google Cloud Storage (https://cloud.google.com/storage/docs/migrating?hl=en), and they don't mention this requirement. I also verified that S3_PING works without any changes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5307) CacheException: Initial state transfer timed out for cache
by Thiago Presa (JIRA)
[ https://issues.jboss.org/browse/WFLY-5307?page=com.atlassian.jira.plugin.... ]
Thiago Presa commented on WFLY-5307:
------------------------------------
I think I'm seeing this on 10.0.0.CR4, I don't know if changes to 7.0.0.ER2 are already included. Is there any workaround for this?
> CacheException: Initial state transfer timed out for cache
> ----------------------------------------------------------
>
> Key: WFLY-5307
> URL: https://issues.jboss.org/browse/WFLY-5307
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta1, 10.0.0.CR2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Critical
> Labels: clean_undeploy, clustering_revalidate
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf18 logged this error (besides the Replication timeout WARN message):
> {code}
> [JBossINF] [0m[0m15:29:55,511 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:29:55,513 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 86) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> [JBossINF] [0m[0m15:29:55,516 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> [JBossINF] [0m[0m15:29:55,538 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:55,539 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (ServerService Thread Pool -- 87) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> [JBossINF] [0m[0m15:29:56,499 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 87) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> [JBossINF] [0m[0m15:30:00,507 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 1) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@5293c097.
> [JBossINF] [0m[0m15:30:01,323 INFO [org.jboss.test.clusterbench.common.ejb.CommonStatefulSBImpl] (EJB default - 2) New SFSB created: org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl@4dfb0a03.
> [JBossINF] [0m[33m15:30:55,461 WARN [org.infinispan.statetransfer.StateConsumerImpl] (ServerService Thread Pool -- 84) ISPN000286: Issue when retrieving cluster listeners from perf19: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:755)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$79(JGroupsTransport.java:589)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$$Lambda$22/1199733093.apply(Unknown Source)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1954)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,467 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 84) MSC000001: Failed to start service jboss.infinispan.web.dist: org.jboss.msc.service.StartException in service jboss.infinispan.web.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> [JBossINF] at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> [JBossINF] at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:839)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:464)
> [JBossINF] at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:120)
> [JBossINF] at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:111)
> [JBossINF] at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80)
> [JBossINF] at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102)
> [JBossINF] ... 4 more
> [JBossINF] Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache dist on perf18
> [JBossINF] at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:225)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:497)
> [JBossINF] at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> [JBossINF] ... 19 more
> [JBossINF]
> [JBossINF] [0m[31m15:31:55,476 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message: undefined
> {code}
> Which ends up with WFLYSRV0021: *Deploy of deployment "clusterbench-ee7.ear" was rolled back*.
> In this very same testrun, there was another issue with application deployment on perf20, may be related: JBEAP-1043
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> This issue is similar to this EAP6 bug: [BZ927948|https://bugzilla.redhat.com/show_bug.cgi?id=927948]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5678) [Migration operation] :migrate operation should return outcome success when migrating expressions jgroup stack in discovery group
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5678?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil reopened WFLY-5678:
-------------------------------
> [Migration operation] :migrate operation should return outcome success when migrating expressions jgroup stack in discovery group
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5678
> URL: https://issues.jboss.org/browse/WFLY-5678
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
>
> If configuration for jgroups stack in discovery group contains expression:
> {code}
> <discovery-group name="groupU">
> <jgroups-stack>${jgroups.stack:udp}</jgroups-stack>
> <jgroups-channel>${jgroups.channel:udp}</jgroups-channel>
> </discovery-group>
> {code}
> then :migrate operation has {{outcome => failed}}:
> {code}
> [standalone@127.0.0.1:9999 /] /subsystem=messaging:migrate
> {
> "outcome" => "failed",
> "result" => {
> "migration-warnings" => [],
> "migration-error" => {
> "operation" => {
> "jgroups-stack" => expression "${jgroups.stack:udp}",
> "jgroups-channel" => expression "${jgroups.channel:udp}",
> "operation" => "add",
> "address" => [
> ("subsystem" => "messaging-activemq"),
> ("server" => "default"),
> ("discovery-group" => "groupU")
> ],
> "operation-headers" => {
> "caller-type" => "user",
> "access-mechanism" => "NATIVE"
> }
> },
> "result" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0264: jgroups-stack may not be ModelType.EXPRESSION",
> "rolled-back" => true
> }
> }
> },
> "failure-description" => "WFLYMSG0081: Migration failed, see results for more details.",
> "rolled-back" => true
> }
> {code}
> Based on my understanding there should be outcome success with warning.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5154) DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
by Jan Tymel (JIRA)
[ https://issues.jboss.org/browse/WFLY-5154?page=com.atlassian.jira.plugin.... ]
Jan Tymel reassigned WFLY-5154:
-------------------------------
Assignee: Jan Tymel (was: Josef Cacek)
> DenyModulePermissionsTestCase, GrantModulePermissionsTestCase, LimitedModulePermissionsTestCase cannot deploy jar
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5154
> URL: https://issues.jboss.org/browse/WFLY-5154
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Jan Tymel
> Fix For: 10.0.0.CR2
>
> Attachments: GrantModulePermissionsTestCase.stacktrace.txt
>
>
> *Description of problem*
> * org.jboss.as.testsuite.integration.secman.module.DenyModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-deny.jar
> * org.jboss.as.testsuite.integration.secman.module.GrantModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-grant.jar
> * org.jboss.as.testsuite.integration.secman.module.LimitedModulePermissionsTestCase
> ** fails with Cannot deploy: modperm-limited.jar
> *How reproducible*
> * 15%
> * OpenJDK, IBM JDK, Oracle JDK
> * Solaris, Windows, RHEL
>
> *Expected results*
> No failures in test case.
> *Additional info*
> See for server logs for DenyModulePermissionsTestCase in attachment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1005) kie-test-util enhancements
by Marco Rietveld (JIRA)
Marco Rietveld created DROOLS-1005:
--------------------------------------
Summary: kie-test-util enhancements
Key: DROOLS-1005
URL: https://issues.jboss.org/browse/DROOLS-1005
Project: Drools
Issue Type: Task
Components: tools
Affects Versions: 6.3.0.Final
Reporter: Marco Rietveld
Assignee: Mario Fusco
There were 2 frameworks that grew out of the "compare" and "marshalling" test code. This issue is for their inclusion into {{kie-test-util}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from POST to MODIFIED
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: David Lloyd
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months