[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
[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
[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
[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