November 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change

by Tero Leppikangas (JIRA)

Tero Leppikangas created JGRP-1897: -------------------------------------- Summary: ENCRYPT might drop messages during key change Key: JGRP-1897 URL: https://issues.jboss.org/browse/JGRP-1897 Project: JGroups Issue Type: Bug Reporter: Tero Leppikangas Assignee: Bela Ban ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. This problem was noticed while doing some stress testing on the fix for JGRP-1893. When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. We thought of possible solutions to be. 1. Sender specific queue holding the messages received. 2. Starting to queue up messages until new view has been received I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623, https://bugzilla.redhat.com/show_bug.cgi?id=1149621 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from ASSIGNED to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-211) HC is over eager to remove its content

by Emmanuel Hugonnet (JIRA)

Emmanuel Hugonnet created WFCORE-211: ---------------------------------------- Summary: HC is over eager to remove its content Key: WFCORE-211 URL: https://issues.jboss.org/browse/WFCORE-211 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha10 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor If you deploy the same war twice (same hash with different names) on a domain then undeploy one the content is removed from the HC while it is still referenced and potentially useable. The content is not removed from the servers content directory. To reproduce : deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=first.war --server-groups=main-server-group --name=first.war deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=second.war --server-groups=main-server-group --name=second.war undeploy first.war --all-relevant-server-groups -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue

by Josef Cacek (JIRA)

Josef Cacek created WFLY-4045: --------------------------------- Summary: Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue Key: WFLY-4045 URL: https://issues.jboss.org/browse/WFLY-4045 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Josef Cacek Assignee: Josef Cacek Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes

by Tero Leppikangas (JIRA)

[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ] Tero Leppikangas commented on JGRP-1893: ---------------------------------------- I believe that the implementation has been the same from Java 6 (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-...) and the implementation is the same in Java 8 (also with Sun's own JDK) The problem is that for multicast use, the ip_ttl is vital part of the configuration, thus cannot be removed from the config. Although the issue causes no problems, it is not nice to have such an exception printed out on every init of a stack. If the discussion about the TTL issue continues, I suppose the proper place for the conversation is under JGRP-1880. > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3978) PicketLink Subsystem EAP 6.4 Issues

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3978?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3978: ----------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1151002|https://bugzilla.redhat.com/show_bug.cgi?id=1151002] from ON_QA to VERIFIED > PicketLink Subsystem EAP 6.4 Issues > ----------------------------------- > > Key: WFLY-3978 > URL: https://issues.jboss.org/browse/WFLY-3978 > Project: WildFly > Issue Type: Task > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1893: -------------------------------- Apparently, the JDK on Windows doesn't implement {{DatagramSocketImpl.setTimeToLive()}}. Can you try a different JDK (e.g. JDK 8), to see if it implements this method ? If not, Windows users will have to live with this until JGroups 4.0 (which switches to NIO.2). You can make the error message go away though by removing {{ip_ttl}} from the config. > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest

by Marcial Atiénzar Navarro (JIRA)

[ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.... ] Marcial Atiénzar Navarro commented on WFLY-4037: ------------------------------------------------ If I activate sso betweens apps,it's cluster activated by default? > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Atiénzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin... ] James Livingston commented on WFCORE-201: ----------------------------------------- Any preference for adding a core-threads parameter (so schema change etc), or just setting the executor's core-threads to 0? > UnboundedQueueThreadPool's keep-alive param is currently useless > ---------------------------------------------------------------- > > Key: WFCORE-201 > URL: https://issues.jboss.org/browse/WFCORE-201 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > > UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless. > Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2014