July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1858) TP: update the timestamp of an entry in logical_addr_cache when it is removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1858?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1858. ---------------------------- Resolution: Done > TP: update the timestamp of an entry in logical_addr_cache when it is removed > ----------------------------------------------------------------------------- > > Key: JGRP-1858 > URL: https://issues.jboss.org/browse/JGRP-1858 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.5, 3.5 > > > {{TP.logical_addr_cache}} maintains mappings between UUIDs and IP addresses. When an address is removed from it, it is not really removed but only marked as 'removable'. > When the cache exceeds its capacity, all removable values are removed. > However, we also have a cache reaper, which periodically (every {{logical_addr_cache_expiration}} ms) removes all values marked as removable. The default is 2 minutes. This means that the reaper runs every 2 minutes and drops removable entries that are older than 2 minutes. > If we have an entry for member P which was added 2 hours ago, and now member P leaves, then that entry is marked as removable. If the reaper happens to kick in just after P left, P's entry will be removed *immediately* ! > SOLUTION: > * Update the timestamp of an entry when it is marked from normal to removable (don't mark it twice !) > * Allow for 0 as a valid reaper interval (disabling reaping) > * Introduce a {{reaper_interval}} (when the reaper runs) and {{logical_addr_cache_expiration}} (already exists) > ** The former has to be smaller than the latter -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on WFLY-3189: ------------------------------------------- yeah so i'm blind. <xs:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="jboss-ejb3-spec-2_0.xsd"/> refers to http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd which simply does not exist. Can we get that uploaded ? > Error validating jboss-ejb3.xml. > -------------------------------- > > Key: WFLY-3189 > URL: https://issues.jboss.org/browse/WFLY-3189 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > > I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error: > {noformat} > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33] > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37] > src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39] > {noformat} > The jboss-ejb3.xml is quite simple: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss:ejb-jar version="3.1" impl-version="2.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:s="urn:security:1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd > http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> > <assembly-descriptor> > <s:security> > <ejb-name>*</ejb-name> > <s:security-domain>testsd</s:security-domain> > </s:security> > </assembly-descriptor> > </jboss:ejb-jar> > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on WFLY-3189: ------------------------------------------- actually it is more than just the weird import. The types used in these xs:elements are not defined which is what the error is about: <xs:element name="ejb" type="javaee:jboss-ejb-beanType"/> <xs:element name="ejb-jar" type="javaee:jboss-ejb-jarType"/> <xs:element name="enterprise-beans" type="javaee:jboss-enterprise-beansType"/> > Error validating jboss-ejb3.xml. > -------------------------------- > > Key: WFLY-3189 > URL: https://issues.jboss.org/browse/WFLY-3189 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > > I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error: > {noformat} > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33] > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37] > src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39] > {noformat} > The jboss-ejb3.xml is quite simple: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss:ejb-jar version="3.1" impl-version="2.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:s="urn:security:1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd > http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> > <assembly-descriptor> > <s:security> > <ejb-name>*</ejb-name> > <s:security-domain>testsd</s:security-domain> > </s:security> > </assembly-descriptor> > </jboss:ejb-jar> > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3575) Parameterize subsystem version in xsite testsuite xslt stylesheet

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3575?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-3575: ------------------------------------ There is a similar problem with the xslt stylesheets for transforming the jgroups subsystem. These are hardcoded for version 2.0 of the jgroups subsystem schema. > Parameterize subsystem version in xsite testsuite xslt stylesheet > ----------------------------------------------------------------- > > Key: WFLY-3575 > URL: https://issues.jboss.org/browse/WFLY-3575 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > > I wasted a good couple of hours today trying to figure out why my changes broke the xsite tests. It turns out that the xslt scripts have the subsystem schema version hardcoded, and I had created a new schema version. > We should parameterize this, in the same way as the addCacheContainer.xsl stylesheet does. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen reopened WFLY-3189: --------------------------------------- reopening since this now came up again via customer case. The errors are not about the actual content in the users xml but in the xsd schema for our ejb3 schema. The validation complains because it cannot find typedefinition and when I look at http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd I cannot find them either. I think the error is this line: <xs:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="jboss-ejb3-spec-2_0.xsd"/> How can it be importing a schema and use its own location as its source ? This just wont work. Should it not be using what is actually commented out: schemaLocation="http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" then it would *Actually* be able to find the definition it is trying to import. > Error validating jboss-ejb3.xml. > -------------------------------- > > Key: WFLY-3189 > URL: https://issues.jboss.org/browse/WFLY-3189 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > > I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error: > {noformat} > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33] > src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37] > src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35] > src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39] > {noformat} > The jboss-ejb3.xml is quite simple: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss:ejb-jar version="3.1" impl-version="2.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:s="urn:security:1.1" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd > http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd"> > <assembly-descriptor> > <s:security> > <ejb-name>*</ejb-name> > <s:security-domain>testsd</s:security-domain> > </s:security> > </assembly-descriptor> > </jboss:ejb-jar> > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1858) TP: update the timestamp of an entry in logical_addr_cache when it is removed

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1858?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1858: -------------------------------- MERGE3 does update the timestamps: whenever information from a member P is received, P's timestamp will be updated. But this can still happen with MERGE2 or large intervals for MERGE3, so I'll implement this anyway... > TP: update the timestamp of an entry in logical_addr_cache when it is removed > ----------------------------------------------------------------------------- > > Key: JGRP-1858 > URL: https://issues.jboss.org/browse/JGRP-1858 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4.5, 3.5 > > > {{TP.logical_addr_cache}} maintains mappings between UUIDs and IP addresses. When an address is removed from it, it is not really removed but only marked as 'removable'. > When the cache exceeds its capacity, all removable values are removed. > However, we also have a cache reaper, which periodically (every {{logical_addr_cache_expiration}} ms) removes all values marked as removable. The default is 2 minutes. This means that the reaper runs every 2 minutes and drops removable entries that are older than 2 minutes. > If we have an entry for member P which was added 2 hours ago, and now member P leaves, then that entry is marked as removable. If the reaper happens to kick in just after P left, P's entry will be removed *immediately* ! > SOLUTION: > * Update the timestamp of an entry when it is marked from normal to removable (don't mark it twice !) > * Allow for 0 as a valid reaper interval (disabling reaping) > * Introduce a {{reaper_interval}} (when the reaper runs) and {{logical_addr_cache_expiration}} (already exists) > ** The former has to be smaller than the latter -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2511) NPE in QueueReadAttributeHandler if QueueControl does not exist

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2511?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2511: ----------------------------------------------- Martin Svehla <msvehla(a)redhat.com> changed the Status of [bug 1095294|https://bugzilla.redhat.com/show_bug.cgi?id=1095294] from ON_QA to VERIFIED > NPE in QueueReadAttributeHandler if QueueControl does not exist > --------------------------------------------------------------- > > Key: WFLY-2511 > URL: https://issues.jboss.org/browse/WFLY-2511 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMS > Affects Versions: 8.0.0.Beta1 > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Fix For: 8.0.0.CR1 > > > I noticed this in a testsuite server log for EAP, but looking at WF code the same thing could happen there. Basically QueueReadAttributeHandler assumes a QueueControl exists and throws an NPE if that assumption is wrong: > 19:14:25,402 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("read-attribute") failed - address: ([ > ("subsystem" => "messaging"), > ("hornetq-server" => "default"), > ("queue" => "39742e8e-32e7-481d-905a-580fd6b67476") > ]): java.lang.NullPointerException > at org.jboss.as.messaging.QueueReadAttributeHandler.executeRuntimeStep(QueueReadAttributeHandler.java:115) > at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:96) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_25] > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1] > IIRC this kind of thing has been fixed elsewhere??? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1858) TP: update the timestamp of an entry in logical_addr_cache when it is removed

by Bela Ban (JIRA)

Bela Ban created JGRP-1858: ------------------------------ Summary: TP: update the timestamp of an entry in logical_addr_cache when it is removed Key: JGRP-1858 URL: https://issues.jboss.org/browse/JGRP-1858 Project: JGroups Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.4.5, 3.5 {{TP.logical_addr_cache}} maintains mappings between UUIDs and IP addresses. When an address is removed from it, it is not really removed but only marked as 'removable'. When the cache exceeds its capacity, all removable values are removed. However, we also have a cache reaper, which periodically (every {{logical_addr_cache_expiration}} ms) removes all values marked as removable. The default is 2 minutes. This means that the reaper runs every 2 minutes and drops removable entries that are older than 2 minutes. If we have an entry for member P which was added 2 hours ago, and now member P leaves, then that entry is marked as removable. If the reaper happens to kick in just after P left, P's entry will be removed *immediately* ! SOLUTION: * Update the timestamp of an entry when it is marked from normal to removable (don't mark it twice !) * Allow for 0 as a valid reaper interval (disabling reaping) * Introduce a {{reaper_interval}} (when the reaper runs) and {{logical_addr_cache_expiration}} (already exists) ** The former has to be smaller than the latter -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-541) Add an KieBase Option to cache, reset and reuse disposed KieSessions

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-541: ---------------------------------- Summary: Add an KieBase Option to cache, reset and reuse disposed KieSessions Key: DROOLS-541 URL: https://issues.jboss.org/browse/DROOLS-541 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco This Option will be disabled by default but can be enabled using the "drools.sessionCacheEnabled=true" system property. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

1
0
0 / 0

[JBoss JIRA] (WFLY-2482) Enable/disable statistics for JCA deployments

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-2482?page=com.atlassian.jira.plugin.... ] Stefano Maestri resolved WFLY-2482. ----------------------------------- Resolution: Done > Enable/disable statistics for JCA deployments > --------------------------------------------- > > Key: WFLY-2482 > URL: https://issues.jboss.org/browse/WFLY-2482 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Fix For: 9.0.0.CR1 > > > Add operations to enable/disable statistics for JCA deployments. > For datasources it would be > {noformat} > statistics=jdbc > statistics=pool > {noformat} > For resource adapters it would be > {noformat} > statistics=pool > {noformat} > and all components that implement the statistics plugin extension -- This message was sent by Atlassian JIRA (v6.2.6#6264)

12 years

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