May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] David Lloyd updated WFLY-3422: ------------------------------ Component/s: VFS > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, VFS > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3422) VFSResourceLoader is creating too many code sources

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3422?page=com.atlassian.jira.plugin.... ] David Lloyd moved MODULES-193 to WFLY-3422: ------------------------------------------- Project: WildFly (was: JBoss Modules) Key: WFLY-3422 (was: MODULES-193) Security: Public Fix Version/s: 8.1.0.Final 9.0.0.Alpha1 (was: 1.2.5.Final) (was: 1.1.6.GA) (was: 1.4.0.Beta1) (was: 1.3.4.Final) > VFSResourceLoader is creating too many code sources > --------------------------------------------------- > > Key: WFLY-3422 > URL: https://issues.jboss.org/browse/WFLY-3422 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > A new code source is being created for every class. We should be mapping code signer lists to cached code sources instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3421) Rehashing on view change can result in premature session/ejb expiration

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-3421: ---------------------------------- Summary: Rehashing on view change can result in premature session/ejb expiration Key: WFLY-3421 URL: https://issues.jboss.org/browse/WFLY-3421 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.1.0.CR2 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Critical Fix For: 8.1.0.Final, 9.0.0.Alpha1 Session/ejb expiration is scheduled only the the owning node of a given session/ejb. When a node leaves each node that assumes ownership of the sessions/ejbs that were previously owned by the leaving node schedules expiration of those sessions. However, view change can also lead to ownership changes for any session/ejb. We are currently handling this properly. If a session/ejb changes ownership, the expiration scheduling is never cancelled, and that session/ejb will expire prematurely, unless the node reacquires ownership. When using sticky sessions, this issue is not apparent, since subsequent requests will direct to the previous owner, who will cancel expiration on the old owner and reschedule expiration on the new owner properly. However, this will be a problem for web sessions if sticky sessions is disabled - and for @Stateful EJBs, if the ejb client receives updated affinity information prior to subsequent requests. There are 2 ways to address this: # When a request arrives for an existing session/ejb, we immediately cancel any scheduled expiration/eviction. This is currently a unicast, which typically results in a local call - but can go remote if the ownership has changed. Making this a cluster-wide broadcast would fix the issue. # We can allow the scheduler to expose the set of keys that are currently schedule, and, on topology change, cancel those sessions/ejbs for which the current node is no longer the owner - and reschedule on the new owner. Option 1 adds an additional cluster-wide RPC per request. Option 2 adds N*(N-1) unicast RPCs per view change, where N is the cluster size (i.e. each node sends 1 rpc to every other node containing the set of session/ejb IDs to schedule for expiration), Option 2 is the least invasive solution - so we'll go with that. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-508) SpEL support for Kie-Spring

by Vinod Kiran Paidimarry (JIRA)

[ https://issues.jboss.org/browse/DROOLS-508?page=com.atlassian.jira.plugin... ] Vinod Kiran Paidimarry updated DROOLS-508: ------------------------------------------ Forum Reference: http://lists.jboss.org/pipermail/rules-users/2014-May/035938.html > SpEL support for Kie-Spring > --------------------------- > > Key: DROOLS-508 > URL: https://issues.jboss.org/browse/DROOLS-508 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Vinod Kiran Paidimarry > Assignee: Mark Proctor > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2912) Generic JMS adapter does not deploy correctly in domain mode.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2912: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106, https://bugzilla.redhat.com/show_bug.cgi?id=1074569, https://bugzilla.redhat.com/show_bug.cgi?id=1103238 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1064299, https://bugzilla.redhat.com/show_bug.cgi?id=1070106, https://bugzilla.redhat.com/show_bug.cgi?id=1074569) > Generic JMS adapter does not deploy correctly in domain mode. > ------------------------------------------------------------- > > Key: WFLY-2912 > URL: https://issues.jboss.org/browse/WFLY-2912 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Tom Ross > Assignee: Stefano Maestri > Fix For: 8.1.0.CR1 > > > When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3345: ------------------------------- Priority: Blocker (was: Major) > Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows > ---------------------------------------------------------------------- > > Key: WFLY-3345 > URL: https://issues.jboss.org/browse/WFLY-3345 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Juergen Zimmermann > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error: > {code} > [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3345) Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3345?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-3345: ------------------------------------ I'm escalating this to blocker, to encourage this to be merged for 8.1.0.Final. > Compilation error in clustering/web/infinispan w/ JDK 8u20 and Windows > ---------------------------------------------------------------------- > > Key: WFLY-3345 > URL: https://issues.jboss.org/browse/WFLY-3345 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.CR2 > Reporter: Juergen Zimmermann > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > In clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java I'm getting the following compilation error which IMHO is also a logical error: > {code} > [ERROR] /C:/temp/wildfly-8.1.0.CR2/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SimpleImmutableSessionAttributes.java:[42,17] variable attributes might not have been initialized > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-508) SpEL support for Kie-Spring

by Vinod Kiran Paidimarry (JIRA)

Vinod Kiran Paidimarry created DROOLS-508: --------------------------------------------- Summary: SpEL support for Kie-Spring Key: DROOLS-508 URL: https://issues.jboss.org/browse/DROOLS-508 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Vinod Kiran Paidimarry Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3386) Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-3386: ------------------------------------ [~andriese] FYI since CDI 1.1 the conversation context is active during any Servlet request. Do you know when is the {{BusinessProcess.startTask()}} method called? Also what versions of CDI does Activiti support? > Nullpointer exception on AbstractSessionBeanStore.getLockStore from within Activiti CDI > --------------------------------------------------------------------------------------- > > Key: WFLY-3386 > URL: https://issues.jboss.org/browse/WFLY-3386 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final > Environment: CentOS, Mac (Mountain Lion). > Reporter: Andries Ehlers > Assignee: Martin Kouba > > Background: > The actual exception seems to be very close the one in issue: WFLY-3001 but we are not using JSF at all, but Activiti CDI. > Not sure if this is a Wildfly or Activiti issue - it could very well be that there is a bug in Activiti with how it manages the CDI scopes. Unfortunately we're at a loss and seeing that the nullpointer is thrown from within a weld AbstractSessionBeanStore, I decided to post it here. Please advise. > Error: > We use Activiti CDI within Wildfly 8.0.0.Final. We randomly encounter an issue (sometimes immediately after a redeploy, other times after a few hours of inactivity on the server) the following issue. When Activiti attempts to retrieve the ContextBeanInstance from its ConversationScopedAssociationProxy, a NullPointer exception is thrown while attempting to retrieve the lock store within Weld (see below). > ----------------------------- > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) java.lang.NullPointerException: null > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,430 INFO [stdout] (default task-12) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:90) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) ~[weld-core-impl-2.1.2.Final.jar!/:2014-01-09 09:23] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager$ConversationScopedAssociation$Proxy$_$$_WeldClientProxy.getTask(Unknown Source) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,431 INFO [stdout] (default task-12) at org.activiti.cdi.impl.context.DefaultContextAssociationManager.getTask(DefaultContextAssociationManager.java:237) ~[activiti-cdi-5.15.jar:na] > 2014-05-21 10:05:34,432 INFO [stdout] (default task-12) at org.activiti.cdi.BusinessProcess.startTask(BusinessProcess.java:332) ~[activiti-cdi-5.15.jar:na] -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-479) Pseudo Clock doesn't work for 2 not statements

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-479?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-479: --------------------------------------- As you pointed out, this test will work if you use the real time clock - there is no concept of "frozen time" there :) > Pseudo Clock doesn't work for 2 not statements > ---------------------------------------------- > > Key: DROOLS-479 > URL: https://issues.jboss.org/browse/DROOLS-479 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.1.Final, 6.1.0.Beta3 > Environment: linux 14.04 > Reporter: Richard Ambridge > Assignee: Mark Proctor > Labels: pseudoclock > > If a rule (event) has the following: > + "when\n" > + " $s : Cheese(type==\"stinky\")\n" > + " not( Cheese(type==\"a\", this after [0s,3s] $s ) )\n" > + " not( Cheese(type==\"b\", this after [0s,5s] $s ) )\n" //2 * not > and pseudo clock is used, the rule doesn't fire. > If realtime clock is used, the rule works. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 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 2014