December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5756) Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5756?page=com.atlassian.jira.plugin.... ] Radoslav Husar edited comment on WFLY-5756 at 12/2/15 10:12 AM: ---------------------------------------------------------------- -Unfortunately, org.jboss.modcluster.config.impl.ModClusterConfig#setExcludedContexts processes in a way that "ROOT" becomes "" internally and "/" becomes "//" because its prepended but the actual get context returns "/" in WF.- Settled down on MODCLUSTER-473 that this is a contract of the API, MODCLUSTER-473 is making that explicit via JavaDoc. The actual fix will happen in WF code. was (Author: rhusar): Unfortunately, org.jboss.modcluster.config.impl.ModClusterConfig#setExcludedContexts processes in a way that "ROOT" becomes "" internally and "/" becomes "//" because its prepended but the actual get context returns "/" in WF. > Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem > --------------------------------------------------------------------------------- > > Key: WFLY-5756 > URL: https://issues.jboss.org/browse/WFLY-5756 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {noformat}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value="ROOT,/"{noformat} > but no luck > {noformat} > mod_cluster/1.3.2.Alpha1-SNAPSHOT > Auto Refresh show DUMP output show INFO output > Node localhost (ajp://127.0.0.1:8009): > Enable Contexts Disable Contexts Stop Contexts > Balancer: syrah-cluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 77 > Virtual Host 1: > Contexts: > /clusterbench-passivating, Status: ENABLED Request: 0 Disable Stop > /, Status: ENABLED Request: 0 Disable Stop > Aliases: > localhost > default-host > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-993) Drools throws CCE when using global SessionClock in temporal operator

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-993: ----------------------------------- Summary: Drools throws CCE when using global SessionClock in temporal operator Key: DROOLS-993 URL: https://issues.jboss.org/browse/DROOLS-993 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Environment: Max OS X 10.11.1, Oracle Hotspot 1.8.0_45 Reporter: Duncan Doyle Assignee: Mario Fusco When I insert the PseudoClock as a global in my KieSession, and I use the clock in combination with a temporal operator in a rule, I get the following CCE: {code} Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Date at org.drools.core.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluate(BeforeEvaluatorDefinition.java:301) at org.drools.core.base.EvaluatorWrapper.evaluate(EvaluatorWrapper.java:94) ... 61 more {code} The interesting thing is that this line works: {code} $s: SimpleEvent(clock.currentTime after[300s] timestamp) {code} while this one fails: {code} $s: SimpleEvent(timestamp before[300s] clock.currentTime) {code} Reproducer can be found here: https://github.com/DuncanDoyle/drools-cce-issue Just run 'mvn clean test'. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5763) Upgrade JBossWS from 5.1.0.Final to 5.1.1.Final

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-5763: ------------------------------------- Summary: Upgrade JBossWS from 5.1.0.Final to 5.1.1.Final Key: WFLY-5763 URL: https://issues.jboss.org/browse/WFLY-5763 Project: WildFly Issue Type: Component Upgrade Components: Web Services Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 10.0.0.CR5 Upgrade to JBossWS 5.1.1.Final, Apache CXF 3.1.4, Apache WSS4J 2.1.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5762) Messaging replication fails to check-for-live-server on restart

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5762?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-2115 to WFLY-5762: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5762 (was: JBEAP-2115) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: JMS (was: ActiveMQ) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR4 (was: 7.0.0.ER1) > Messaging replication fails to check-for-live-server on restart > --------------------------------------------------------------- > > Key: WFLY-5762 > URL: https://issues.jboss.org/browse/WFLY-5762 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Jeff Mesnil > Assignee: Andy Taylor > > The attached configuration use JGroups. > I had a look at the code and I suspect the issue is located somewhere when the server1 is restarted and calls its SharedNothingLiveActivation#isNodeIdUsed(). > This method returns false and the server completes its live activation instead of setting its HA policy to replicaPolicy. > Digging into the code, I looks like DiscoveryGroup#received boolean is never set to true because its corresponding JGroupsBroadcastEndpoint never receives any JGroups message. > I confirm that server2 is working at that time and does send JGroups message. > I suspect that there is a bug in the wrapping of JGroups receiver/channel/etc. in org.apache.activemq.artemis.api.core.JGroupsBroadcastEndpoint and the endpoint in DiscoveryGroup never receives the message that is actually received by JGroups in the ReceiverAdapter instantiated by JGroupsBroadcastEndpoint.JChannelWrapper#connect. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5761) Update transformers & tests for EAP 6.2, 6.3 & 6.4

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-5761: --------------------------------- Summary: Update transformers & tests for EAP 6.2, 6.3 & 6.4 Key: WFLY-5761 URL: https://issues.jboss.org/browse/WFLY-5761 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar Transformers tests need to be updated to test for compatibility of: - EAP 6.2 - EAP 6.3 - EAP 6.4 And possibly also micro releases of each. But that should be handled as separate task. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-977) Error in combining str[contains] with OR results

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-977?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-977. -------------------------------- Resolution: Out of Date The problem is not caused by OR. We never had a str[contains] operator. Only supported operators are startsWith, endsWith and length. However the str[] operators are legacy stuff that has been introduced when Drools didn't have free form expressions. For this reason they have to be considered deprecated. Instead of them use the native methods of the java.lang.String object and then instead of name str[contains] "test1" just write name.contains( "test1" ) > Error in combining str[contains] with OR results > ------------------------------------------------ > > Key: DROOLS-977 > URL: https://issues.jboss.org/browse/DROOLS-977 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: CentOS 6.4, WildFly > Reporter: hoon lee > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ] Ivo Studensky closed WFLY-4608. ------------------------------- Resolution: Won't Fix > Omit no-op transaction if lifecycle method is missing > ----------------------------------------------------- > > Key: WFLY-4608 > URL: https://issues.jboss.org/browse/WFLY-4608 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 10.0.0.CR5 > > > LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4608) Omit no-op transaction if lifecycle method is missing

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-4608?page=com.atlassian.jira.plugin.... ] Ivo Studensky commented on WFLY-4608: ------------------------------------- Ok. It looks like we are fine in terms of EJB spec. As long as {{interceptorConfig}} does not cover all possible interceptor configs (like interceptors in deployment descriptors - see details in comments of the declined PR), we cannot safely avoid these no-op transactions. One issue related to this has been fixed by WFLY-4635. > Omit no-op transaction if lifecycle method is missing > ----------------------------------------------------- > > Key: WFLY-4608 > URL: https://issues.jboss.org/browse/WFLY-4608 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.CR1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 10.0.0.CR5 > > > LifecycleCMTTxInterceptor creates a no-op transaction even if there is no lifecycle method defined in the bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3549) Deadlock during shutdown

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3549?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3549: ----------------------------------------------- Richa <rmarwaha(a)redhat.com> changed the Status of [bug 1184532|https://bugzilla.redhat.com/show_bug.cgi?id=1184532] from NEW to CLOSED > Deadlock during shutdown > ------------------------ > > Key: WFLY-3549 > URL: https://issues.jboss.org/browse/WFLY-3549 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: David Lloyd > Fix For: 8.2.0.Final > > > This deadlock appeared in an Arquillian test: > {noformat} > Found one Java-level deadlock: > ============================= > "undefined": > waiting to lock monitor 0x00007f67a421bfa8 (object 0x00000000e0700480, a org.jboss.as.threads.ScheduledThreadPoolService), > which is held by "MSC service thread 1-2" > "MSC service thread 1-2": > waiting for ownable synchronizer 0x00000000e0700618, (a java.util.concurrent.locks.ReentrantLock$NonfairSync), > which is held by "undefined" > Java stack information for the threads listed above: > =================================================== > "undefined": > at org.jboss.as.threads.ScheduledThreadPoolService$ExecutorImpl.terminated(ScheduledThreadPoolService.java:121) > - waiting to lock <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:704) > at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1006) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1163) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > "MSC service thread 1-2": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000e0700618> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) > at java.util.concurrent.ThreadPoolExecutor.interruptIdleWorkers(ThreadPoolExecutor.java:781) > at java.util.concurrent.ThreadPoolExecutor.tryTerminate(ThreadPoolExecutor.java:695) > at java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:1397) > at java.util.concurrent.ScheduledThreadPoolExecutor.shutdown(ScheduledThreadPoolExecutor.java:759) > at org.jboss.as.threads.ManagedScheduledExecutorService.internalShutdown(ManagedScheduledExecutorService.java:53) > at org.jboss.as.threads.ScheduledThreadPoolService.stop(ScheduledThreadPoolService.java:67) > - locked <0x00000000e0700480> (a org.jboss.as.threads.ScheduledThreadPoolService) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056) > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Found 1 deadlock. > {noformat} > Looks like two MSC service threads exited and tried to terminate the thread pool at the same time. And because the MSC threads are not daemon threads, the entire JVM hangs and blocks the Arquillian test that was waiting for the container to shut down. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-954) Removal of a rule having a sub-sub-network doesn't cleanup the outermost subnetwork

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-954?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-954: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to VERIFIED > Removal of a rule having a sub-sub-network doesn't cleanup the outermost subnetwork > ----------------------------------------------------------------------------------- > > Key: DROOLS-954 > URL: https://issues.jboss.org/browse/DROOLS-954 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.x > > > Removal of a rule having a sub-sub-network (as in the following drl) doesn't cleanup the outermost subnetwork > {code} > rule R when > $l : List() > exists Integer( this == 1 ) from $l > exists Integer( this == 2 ) from $l > then > end > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2015