[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)
10 years, 1 month
[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)
10 years, 1 month
[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)
10 years, 1 month
[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)
10 years, 1 month
[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)
10 years, 1 month
[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)
10 years, 1 month
[JBoss JIRA] (DROOLS-638) KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode
by Hariprasad Taduru (JIRA)
[ https://issues.jboss.org/browse/DROOLS-638?page=com.atlassian.jira.plugin... ]
Hariprasad Taduru commented on DROOLS-638:
------------------------------------------
We are facing the above issue and not able to get a work around as well. Seems like a bug in the engine.
Could you please clarify on this?
> KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-638
> URL: https://issues.jboss.org/browse/DROOLS-638
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: Windows 8 64bit Machine, Java jdk1.7.0_51
> Reporter: Vinay Pareek
> Assignee: Mark Proctor
> Attachments: AgentTest.zip
>
>
> If we have two rules on same condition in Steam mode, first time agent able to pick both and work fine.
> When we update any rule (then part), KnowledgeAgent will stuck infinite after printing below logs.
> [2014-10-24 17:59:04,066:debug] KnowledgeAgent received ChangeSet changed notification
> [2014-10-24 17:59:04,066:info] KnowledgeAgent applying ChangeSet
> [2014-10-24 17:59:04,067:debug] KnowledgeAgent removing mappings for resource=[FileResource file='rule\streamRule.drl'] with unsubscribe=false
> [2014-10-24 17:59:04,067:debug] KnowledgeAgent rebuilding KnowledgeBase using ChangeSet
> [2014-10-24 17:59:04,076:info] KnowledgeAgent performing an incremental build of the ChangeSet
> [2014-10-24 17:59:04,193:debug] KnowledgeAgent: Diffing: [FileResource file='rule\streamRule.drl']
> Below is code snippet for KnowledgeAgent
> KnowledgeAgentConfiguration kaconf = KnowledgeAgentFactory
> .newKnowledgeAgentConfiguration();
> kaconf.setProperty("drools.agent.scanDirectories", "true");
> kaconf.setProperty("drools.agent.newInstance", "false");
> KnowledgeBaseConfiguration config = KnowledgeBaseFactory
> .newKnowledgeBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent(
> "kagent", kbase, kaconf);
> kagent.setSystemEventListener(new PrintStreamSystemEventListener());
> kagent.addEventListener(new KnowledgeAgentEventListener() {
> public void resourceCompilationFailed(
> ResourceCompilationFailedEvent arg0) {
> LOGGER.error("Unable to compile Knowledge" + arg0.toString());
> throw new RuntimeException("Unable to compile Knowledge"
> + arg0.toString());
> }
> public void knowledgeBaseUpdated(KnowledgeBaseUpdatedEvent arg0) {
> LOGGER.info("********** KBase was updated***********");
> }
> public void beforeResourceProcessed(
> BeforeResourceProcessedEvent arg0) {
> }
> public void beforeChangeSetProcessed(
> BeforeChangeSetProcessedEvent arg0) {
> }
> public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent arg0) {
> }
> public void afterResourceProcessed(AfterResourceProcessedEvent arg0) {
> }
> public void afterChangeSetProcessed(
> AfterChangeSetProcessedEvent arg0) {
> }
> public void afterChangeSetApplied(AfterChangeSetAppliedEvent arg0) {
> }
> });
> ResourceChangeScannerConfiguration sconf = ResourceFactory
> .getResourceChangeScannerService()
> .newResourceChangeScannerConfiguration();
> sconf.setProperty("drools.resource.scanner.interval", "2");
> ResourceFactory.getResourceChangeScannerService().configure(sconf);
> kagent.applyChangeSet(ResourceFactory
> .newClassPathResource("changeset/changeSet.xml"));
> ResourceFactory.getResourceChangeNotifierService().start();
> ResourceFactory.getResourceChangeScannerService().start();
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month