May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes NPE

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ] Geoffrey De Smet moved PLANNER-488 to DROOLS-1186: -------------------------------------------------- Project: Drools (was: OptaPlanner) Key: DROOLS-1186 (was: PLANNER-488) Workflow: GIT Pull Request workflow (was: classic default workflow) Component/s: core engine (was: optaplanner-examples) Affects Version/s: 6.3.0.Final 6.2.0.Final (was: 6.2.0.Final) (was: 6.3.0.Final) Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Beta1) > Setting the planning variable nullable in nurserostering examples causes NPE > ---------------------------------------------------------------------------- > > Key: DROOLS-1186 > URL: https://issues.jboss.org/browse/DROOLS-1186 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final, 6.2.0.Final > Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1. > Reporter: Julio Bellon Aguilera > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: PLANNER_488.patch > > > If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException. > fixed that, causes the first NPE, and fixed that, causes other NPE unfixed: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: > Caused by: java.lang.NullPointerException > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1564) Upgrade Undertow to 1.3.22.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1564?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1564: ------------------------------------- Git Pull Request: (was: https://github.com/jbossas/wildfly-core-eap/pull/239) > Upgrade Undertow to 1.3.22.Final > -------------------------------- > > Key: WFCORE-1564 > URL: https://issues.jboss.org/browse/WFCORE-1564 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Ingo Weiss > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha2, 2.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1564) Upgrade Undertow to 1.3.22.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1564?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1564: ------------------------------------- Sprint: (was: EAP 7.0.1) > Upgrade Undertow to 1.3.22.Final > -------------------------------- > > Key: WFCORE-1564 > URL: https://issues.jboss.org/browse/WFCORE-1564 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Ingo Weiss > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha2, 2.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-547) Update OTPTest to use real callback handlers

by Farah Juma (JIRA)

Farah Juma created ELY-547: ------------------------------ Summary: Update OTPTest to use real callback handlers Key: ELY-547 URL: https://issues.jboss.org/browse/ELY-547 Project: WildFly Elytron Issue Type: Feature Request Components: SASL Reporter: Farah Juma Assignee: Farah Juma Go through the commits in [PR #277|https://github.com/wildfly-security/wildfly-elytron/pull/277], determine which ones are still relevant, and what else needs to be done in order to be able to use real callback handlers in {{OTPTest}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6591) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6591?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6591: ------------------------------------ Great. The fix is in the PR queue awaiting merge. I can't say yet when it'll be merged as our queue is quite long atm. > Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation > ------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-6591 > URL: https://issues.jboss.org/browse/WFLY-6591 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Gabriel Lavoie > Assignee: Paul Ferraro > > When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever. > Session seems to be invalidated correctly and isn't accessible anymore. > After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped. > We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following: > {code} > private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) { > SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id); > if (this.properties.isLockOnWrite()) { > if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) { > creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key); > this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id)); > return true; > } > return false; > } else { > creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key); > this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id)); > return true; > } > } > {code} > With that change, the memory leaks disappears. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6632) Unable to create replicated cache

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6632?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-6632: ------------------------------------ I need to see the application source, not just the war. > Unable to create replicated cache > ---------------------------------- > > Key: WFLY-6632 > URL: https://issues.jboss.org/browse/WFLY-6632 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.2.Final > Reporter: Vinay Lodha > Assignee: Paul Ferraro > Attachments: server.log, spring2-mvc-xml-hello-world-1.0-SNAPSHOT.war > > > servers is unable to create replicated or distributed infinispan cache, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-86) Create an exception filter

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-86?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-86: -------------------------------- Fix Version/s: 2.1.0.Beta1 > Create an exception filter > -------------------------- > > Key: LOGMGR-86 > URL: https://issues.jboss.org/browse/LOGMGR-86 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Perkins > Fix For: 2.1.0.Beta1 > > > For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-86) Create an exception filter

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-86?page=com.atlassian.jira.plugin.... ] James Perkins updated LOGMGR-86: -------------------------------- Priority: Major (was: Optional) > Create an exception filter > -------------------------- > > Key: LOGMGR-86 > URL: https://issues.jboss.org/browse/LOGMGR-86 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Perkins > Fix For: 2.1.0.Beta1 > > > For now this is just a thought so that users can filter messages based on an exception in the stack trace. Currently it's not possible to use a regex filter as the stack trace is not used in when testing for matches and it probably shouldn't be used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1121) Use script name for file related to Wildfly to allow multiple instances easily

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1121?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1121: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1225 (was: https://github.com/jbossas/jboss-eap/pull/2625) > Use script name for file related to Wildfly to allow multiple instances easily > ------------------------------------------------------------------------------ > > Key: WFCORE-1121 > URL: https://issues.jboss.org/browse/WFCORE-1121 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 2.0.1.Final > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Priority: Optional > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > With the current provided init.d script, one cannot start several instances of Wildfly. Indeed, the script will associate the same files (pid file, log) to both instance. If we rename those files using, for instance, the name of the script we can easily use the *exact same script* for all local instances: > {code:bash} > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-1 > # ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-2 > {code} > And to take the example of the PIDFILE: > {code:bash} > JBOSS_PIDFILE=/var/run/$(basename $0)/jboss-as-domain.pid > {code} > Each links will then look up and creates its own separate file: > /var/run/wildfly-1/jboss-as-domain.pid > /var/run/wildfly-2/jboss-as-domain.pid -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1565) Upgrade JBoss Remoting from 4.0.18 to 4.0.20

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1565?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1565: ---------------------------------------- Assignee: Brian Stansberry (was: Vladimir Dosoudil) > Upgrade JBoss Remoting from 4.0.18 to 4.0.20 > -------------------------------------------- > > Key: WFCORE-1565 > URL: https://issues.jboss.org/browse/WFCORE-1565 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Bartosz Baranowski > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha2, 2.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016