[JBoss JIRA] (WFLY-4730) Undertow mod_cluster proxy does not offer any Client HTTPS configuration
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4730?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4730.
----------------------------
> Undertow mod_cluster proxy does not offer any Client HTTPS configuration
> ------------------------------------------------------------------------
>
> Key: WFLY-4730
> URL: https://issues.jboss.org/browse/WFLY-4730
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.Alpha3
>
>
> Undertow mod_cluster proxy acts both as a *server* and as a *client* in relation to its workers.
> While the *server* configuration is quite straightforward:
> {code:xml}
> +++
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/vault/ca-cert.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> </system-properties>
> +++
> <security-realm name="UndertowRealm">
> <server-identities>
> <ssl>
> <keystore path="/vault/server-cert-key.jks" keystore-password="tomcat" alias="javaserver" key-password="tomcat"/>
> </ssl>
> </server-identities>
> </security-realm>
> +++
> <https-listener name="https" socket-binding="https" security-realm="UndertowRealm"/>
> +++
> {code}
> with having {{management-socket-binding="https"}} and {{advertise-protocol="https"}} set; it seems there is no way to configure certs and keys for the *client* role of the Undertow mod_cluster proxy implementation.
> With the current implementation, *worker* can connect to the Undertow mod_cluster proxy, i.e. it can send {{CONFIG}} and {{STATUS}} MCMP messages, but when the Undertow mod_cluster proxy needs to act as a *client*, sending {{STATUS-RSP}} message to the *worker*, it does not have the necessary HTTPS setup:
> {noformat}
> DEBUG [io.undertow] (default I/O-5) UT005055: HttpClientPingTask run for connection: https://192.168.0.122:8544/?#
> DEBUG [io.undertow.server.handlers.proxy.ProxyHandler] (default I/O-5) No proxy target for request to https://192.168.0.122:8443/
> DEBUG [io.undertow] (default task-7) UT005056: Received node load in STATUS message, node jvmRoute: worker-1, load: 80
> DEBUG [io.undertow.request] (default I/O-5) Failed to connect: java.io.IOException: UT000065: SSL must be specified to connect to a https URL
> at io.undertow.client.http.HttpClientProvider.connect(HttpClientProvider.java:93)
> at io.undertow.client.UndertowClient.connect(UndertowClient.java:158)
> at io.undertow.server.handlers.proxy.ProxyConnectionPool.openConnection(ProxyConnectionPool.java:233)
> at io.undertow.server.handlers.proxy.ProxyConnectionPool.connect(ProxyConnectionPool.java:446)
> at io.undertow.server.handlers.proxy.mod_cluster.NodePingUtil$1.run(NodePingUtil.java:140)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
> The HTTPS communication between Undertow mod_cluster proxy and its workers needs to be bidirectional.
> If I'm just missing any obvious configuration option, please, shout, throw rocks and close this JIRA :)
> Thank you for your time looking into it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4602) HttpServletRequest#logout doesn't fully clear security context
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4602?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4602.
----------------------------
> HttpServletRequest#logout doesn't fully clear security context
> --------------------------------------------------------------
>
> Key: WFLY-4602
> URL: https://issues.jboss.org/browse/WFLY-4602
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1
> Reporter: Arjan t
> Assignee: Stuart Douglas
> Labels: authentication, security, security-context
> Fix For: 9.0.0.CR2, 10.0.0.Alpha1
>
>
> After having authenticated (via JASPIC or otherwise), calling {{HttpServletRequest#logout}} and then requesting the caller/user principal (all within the same request), Undertow (via e.g. WildFly 8.2 or 9.0rc1) will correctly clear out the principal for the web context, but will NOT clear out the principal for the EJB context.
> The problem seems to be that {{io.undertow.security.impl.SecurityContextImpl.logout()}} doesn't do anything with the security context that is used by the EJB container among others.
> It now just contains the following:
> {code:java}
> this.account = null;
> this.mechanismName = null;
> this.authenticationState = AuthenticationState.NOT_ATTEMPTED;
> {code}
> Added the following code just before this seems to work:
> {code:java}
> // Clear old context
> SecurityContextAssociation.clearSecurityContext();
> SecurityRolesAssociation.setSecurityRoles(null);
>
> // Set a new one in case re-authentication is done within the same thread
> SecurityContext securityContext = SecurityContextFactory.createSecurityContext("other");
> exchange.putAttachment(SECURITY_CONTEXT_ATTACHMENT, securityContext);
> SecurityContextAssociation.setSecurityContext(securityContext);
> // (existing clearing code)
> this.account = null;
> this.mechanismName = null;
> this.authenticationState = AuthenticationState.NOT_ATTEMPTED;
> {code}
> Do note that this code uses the hardcoded domain "other". Except by using reflection I couldn't obtain the actual domain name at this point. The reflective code I used was:
> {code:java}
> String securityDomain = "other";
> if (identityManager instanceof JAASIdentityManagerImpl) {
> try {
> Field securityDomainContextField = JAASIdentityManagerImpl.class.getDeclaredField("securityDomainContext");
> securityDomainContextField.setAccessible(true);
> SecurityDomainContext securityDomainContext = (SecurityDomainContext) securityDomainContextField.get(identityManager);
> securityDomain = securityDomainContext.getAuthenticationManager().getSecurityDomain();
> } catch (NoSuchFieldException | SecurityException | IllegalArgumentException | IllegalAccessException e) {
> logger.log(Level.SEVERE, "Can't obtain name of security domain, using 'other' now", e);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5061) Tables for JDBC Batch repository are created twice
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5061?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5061.
----------------------------
> Tables for JDBC Batch repository are created twice
> --------------------------------------------------
>
> Key: WFLY-5061
> URL: https://issues.jboss.org/browse/WFLY-5061
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Jan Martiska
> Assignee: Jan Martiska
> Priority: Critical
> Fix For: 10.0.0.Beta1
>
>
> The constructor of org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService is called twice: https://github.com/wildfly/wildfly/blob/80247ada8e7daa46660c732c4fc927e26... (both lines 56 and 69 typically get executed). Two threads then race to create the tables.
> Some databases can deal with it (those which support IF NOT EXISTS clause in the CREATE TABLE query). But where this is not used, creating a JDBC Batch repository fails with
> {noformat}
> 15:21:31,526 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 29) MSC000001: Failed to start service org.wildfy.batch.job.repository.jdbc: org.jboss.msc.service.StartException in service org.wildfy.batch.job.repository.jdbc: WFLYBATCH000011: Failed to create JDBC job repository.
> at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService.lambda$start$1(JdbcJobRepositoryService.java:59)
> at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService$$Lambda$12/1223050080.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.batch.operations.BatchRuntimeException: JBERET000624: Failed to create tables for batch job repository database product name Adaptive Server Enterprise with DDL sql/jberet-sybase.ddl
> at org.jberet.repository.JdbcRepository.createTables(JdbcRepository.java:281)
> at org.jberet.repository.JdbcRepository.<init>(JdbcRepository.java:205)
> at org.jberet.repository.JdbcRepository.<init>(JdbcRepository.java:167)
> at org.wildfly.extension.batch.jberet.job.repository.JdbcJobRepositoryService.lambda$start$1(JdbcJobRepositoryService.java:56)
> ... 5 more
> Caused by: java.sql.BatchUpdateException: JZ0BE: BatchUpdateException: Error occurred while executing batch statement: There is already an object named 'JOB_INSTANCE' in the database.
> at com.sybase.jdbc4.jdbc.ErrorMessage.raiseBatchUpdateException(ErrorMessage.java:1300)
> at com.sybase.jdbc4.jdbc.SybStatement.batchLoop(SybStatement.java:2134)
> at com.sybase.jdbc4.jdbc.SybStatement.sendBatch(SybStatement.java:1924)
> at com.sybase.jdbc4.jdbc.SybStatement.executeBatch(SybStatement.java:1882)
> at com.sybase.jdbc4.jdbc.SybStatement.executeBatch(SybStatement.java:1691)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1174)
> at org.jberet.repository.JdbcRepository.createTables(JdbcRepository.java:279)
> ... 8 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-5308) Failed to start service due to IllegalStateException: Duplicate key during application deployment
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5308?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-5308.
----------------------------
> Failed to start service due to IllegalStateException: Duplicate key during application deployment
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-5308
> URL: https://issues.jboss.org/browse/WFLY-5308
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> EAP 7.0.0.DR9
> Scenario: failover-ejb-ejbremote-undeploy-dist-async
> During application deployment (after failover), perf20 logged this error:
> {code}
> [JBossINF] [0m[0m15:36:10,604 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 85) WFLYCLINF0002: Started dist cache from ejb container
> [JBossINF] [0m[0m15:36:10,608 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:36:10,611 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 84) WFLYCLINF0002: Started dist cache from web container
> [JBossINF] [0m[0m15:36:10,612 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[31m15:36:10,613 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ejb.remoting.connector.client-mappings.installer: org.jboss.msc.service.StartException in service jboss.ejb.remoting.connector.client-mappings.installer: Failed to start service
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [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] Caused by: java.lang.IllegalStateException: Duplicate key [org.jboss.as.network.ClientMapping@44b990d8]
> [JBossINF] at java.util.stream.Collectors.lambda$throwingMerger$152(Collectors.java:133)
> [JBossINF] at java.util.stream.Collectors$$Lambda$58/796953906.apply(Unknown Source)
> [JBossINF] at java.util.HashMap.merge(HashMap.java:1245)
> [JBossINF] at java.util.stream.Collectors.lambda$toMap$210(Collectors.java:1320)
> [JBossINF] at java.util.stream.Collectors$$Lambda$60/415494469.accept(Unknown Source)
> [JBossINF] at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> [JBossINF] at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> [JBossINF] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> [JBossINF] at java.util.Iterator.forEachRemaining(Iterator.java:116)
> [JBossINF] at org.infinispan.stream.impl.spliterators.IteratorAsSpliterator.forEachRemaining(IteratorAsSpliterator.java:150)
> [JBossINF] at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)
> [JBossINF] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
> [JBossINF] at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [JBossINF] at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [JBossINF] at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [JBossINF] at org.infinispan.stream.impl.local.AbstractLocalCacheStream.collect(AbstractLocalCacheStream.java:256)
> [JBossINF] at org.infinispan.stream.impl.TerminalFunctions$CollectorFunction.apply(TerminalFunctions.java:1035)
> [JBossINF] at org.infinispan.stream.impl.TerminalFunctions$CollectorFunction.apply(TerminalFunctions.java:1025)
> [JBossINF] at org.infinispan.stream.impl.termop.SegmentRetryingOperation.innerPerformOperation(SegmentRetryingOperation.java:68)
> [JBossINF] at org.infinispan.stream.impl.termop.SegmentRetryingOperation.performOperation(SegmentRetryingOperation.java:79)
> [JBossINF] at org.infinispan.stream.impl.AbstractCacheStream.performOperationRehashAware(AbstractCacheStream.java:306)
> [JBossINF] at org.infinispan.stream.impl.AbstractCacheStream.performOperation(AbstractCacheStream.java:252)
> [JBossINF] at org.infinispan.stream.impl.DistributedCacheStream.collect(DistributedCacheStream.java:324)
> [JBossINF] at org.wildfly.clustering.server.registry.CacheRegistry.getEntries(CacheRegistry.java:110)
> [JBossINF] at org.jboss.as.ejb3.remote.LocalEjbReceiver.registryAdded(LocalEjbReceiver.java:447)
> [JBossINF] at org.jboss.as.ejb3.remote.RegistryCollectorService.add(RegistryCollectorService.java:54)
> [JBossINF] at org.jboss.as.ejb3.remote.RegistryInstallerService.start(RegistryInstallerService.java:60)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [JBossINF] ... 3 more
> [JBossINF]
> [JBossINF] [0m[31m15:36:10,625 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "clusterbench-ee7.ear")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> [JBossINF] "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.cache]",
> [JBossINF] "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.cache]"
> [JBossINF] ]}
> [JBossINF] [0m[31m15:36:10,627 ERROR [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment "clusterbench-ee7.ear" was rolled back with the following failure message:
> [JBossINF] {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> [JBossINF] "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.LocalStatefulSB.cache]",
> [JBossINF] "jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.START is missing [jboss.deployment.subunit.\"clusterbench-ee7.ear\".\"clusterbench-ee7-ejb.jar\".component.RemoteStatefulSBImpl.cache]"
> [JBossINF] ]}
> {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 perf18, may be related: JBEAP-1041
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4748) Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4748?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4748.
----------------------------
> Singleton service fails to start after repetitive cluster split with "Failed to reach quorum of 1"
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4748
> URL: https://issues.jboss.org/browse/WFLY-4748
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Alpha6
>
>
> When cluster of two nodes with deployed singleton service (f.i. cluster-ha-singleton quickstart app) splits, merges, and splits again, one of the nodes fails to run the singleton service with error message "WFLYCLSV0006: Failed to reach *quorum of 1* for jboss.quickstart.ha.singleton.default2 service. No singleton master will be elected." - note the "quorum of 1".
> This only happens after the second and other successive splits. After the first split both nodes execute the service correctly.
> After analysis, it appears that nodes are never being added back to service providers cache upon cluster merge, because CacheServiceProviderRegistrationFactory#membershipChanged() is never called with 'merged' attribute set to 'true'.
> I presume that call should come from ChannelCommandDispatcherFactory#viewAccepted():
> {code}
> public void viewAccepted(View view) {
> // ...
> for (Listener listener: this.listeners) {
> listener.membershipChanged(oldNodes, newNodes, view instanceof MergeView);
> }
> }
> {code}
> This method gets called, but the problem is that the 'listeners' list is empty, so no listener is actually notified.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-4709) Invalid Last-Modified header
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4709?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4709.
----------------------------
> Invalid Last-Modified header
> ----------------------------
>
> Key: WFLY-4709
> URL: https://issues.jboss.org/browse/WFLY-4709
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows Server 2008
> Reporter: Davy De Durpel
> Assignee: Stuart Douglas
> Fix For: 9.0.0.CR2, 10.0.0.Alpha3
>
>
> After 2 months of use Wildfly suddenly started to send an invalid Last-Modified header. Normally it should be in the format:
> Fri, 10 Oct 2014 19:35:55 GMT
> But sometimes it sends:
> Fri, 10 Oct 2014 21:35:55 CEST
> Or even:
> Fri, 10 Oct 2014 21:35:55 CEST GMT
> The URLConnection.getLastModified() method cannot handle these 2 last formats as it uses an old and deprecated Date.parse(..) method.
> A restart of the service fixes the issue for a few hours after which it reappears but not for all requests. We switched back to JBoss 7.1.1 and the issue disappeared completely so we're pretty sure that it's a bug in WildFly. No updates were done to windows, java and Wildfly that could have triggered the issue. We noticed the issue because we have a java applet running at the customer side. We use URLConnection to download some files based on the last modification date of these files. Browsers don't seem to be affected by the issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month