January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161529|https://bugzilla.redhat.com/show_bug.cgi?id=1161529] from VERIFIED to CLOSED > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: FD_HOSTTest.java, test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1161529|https://bugzilla.redhat.com/show_bug.cgi?id=1161529] from VERIFIED to CLOSED > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: FD_HOSTTest.java, test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1899: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1168329|https://bugzilla.redhat.com/show_bug.cgi?id=1168329] from VERIFIED to CLOSED > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-640: -------------------------------------------------- Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1085500|https://bugzilla.redhat.com/show_bug.cgi?id=1085500] from ON_QA to VERIFIED > Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory. > ------------------------------------------------------------------------------------------------------------------ > > Key: SECURITY-640 > URL: https://issues.jboss.org/browse/SECURITY-640 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1 > Reporter: Hrishi Salvi > Assignee: Derek Horton > Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2 > > > We are trying to configure the single sign on using jboss negotiation. > We are able to login successfully if the user is present in active directory. > But in case if user is not present in active directory users, it throw 401 error page. > Instead of 401 we want user to access login form and authenticate user using different login module. > In our case we have login page we authenticate user on that page. > If we receive user credentials we login the user without asking for password. > Now if the user credentials are not received then we want user to open login form present > on login page, but before that is throws 401 error. > We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation. > Also defined > <web-resource-collection> > <web-resource-name>Restricted</web-resource-name> > <url-pattern>/Request</url-pattern> > <http-method>GET</http-method> > <http-method>POST</http-method> > </web-resource-collection> > in web.xml > Our application is access through Request servlet. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-498) Move logging tests to core

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-498?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-498: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/439, https://github.com/wildfly/wildfly-core/pull/459 (was: https://github.com/wildfly/wildfly-core/pull/439) > Move logging tests to core > -------------------------- > > Key: WFCORE-498 > URL: https://issues.jboss.org/browse/WFCORE-498 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > Fix For: 1.0.0.Alpha16 > > > Integration logging tests from WildFly should be moved to core where applicable. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-524) HTTPSConnectionWithCLITestCase leaves process CLI process

by James Perkins (JIRA)

James Perkins created WFCORE-524: ------------------------------------ Summary: HTTPSConnectionWithCLITestCase leaves process CLI process Key: WFCORE-524 URL: https://issues.jboss.org/browse/WFCORE-524 Project: WildFly Core Issue Type: Bug Components: Test Suite Reporter: James Perkins Assignee: James Perkins The {{testDefaultCLIConfiguration}} test outputs the following which expects a response: {code} INFO [org.jboss.modules] JBoss Modules version 1.4.1.Final INFO [org.xnio] XNIO version 3.3.0.Final INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Final INFO [org.jboss.remoting] JBoss Remoting version 4.0.5.Final INFO [org.jboss.as.cli.CommandContext] Unable to connect due to unrecognised server certificate Unable to connect due to unrecognised server certificate INFO [org.jboss.as.cli.CommandContext] Subject - CN=server Subject - CN=server INFO [org.jboss.as.cli.CommandContext] Issuer - CN=server Issuer - CN=server INFO [org.jboss.as.cli.CommandContext] Valid From - Wed Oct 30 11:06:26 CET 2013 Valid From - Wed Oct 30 11:06:26 CET 2013 INFO [org.jboss.as.cli.CommandContext] Valid To - Tue Oct 25 12:06:26 CEST 2033 Valid To - Tue Oct 25 12:06:26 CEST 2033 INFO [org.jboss.as.cli.CommandContext] MD5 : 70:7a:47:8e:7f:a9:10:7e:3a:98:9e:20:f9:22:1e:0e MD5 : 70:7a:47:8e:7f:a9:10:7e:3a:98:9e:20:f9:22:1e:0e INFO [org.jboss.as.cli.CommandContext] SHA1 : 0b:42:9d:fd:d4:c9:7c:4e:f0:e7:1f:9d:4b:c4:5d:e9:1c:79:12:23 SHA1 : 0b:42:9d:fd:d4:c9:7c:4e:f0:e7:1f:9d:4b:c4:5d:e9:1c:79:12:23 INFO [org.jboss.as.cli.CommandContext] Accept certificate? [N]o, [T]emporarily, [P]ermenantly : {code} On Linux the process is not destroyed and left running in the background. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-699) A not with no constraints is not linked when part of a subnetwork starting from a BetaNode

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-699: ---------------------------------- Summary: A not with no constraints is not linked when part of a subnetwork starting from a BetaNode Key: DROOLS-699 URL: https://issues.jboss.org/browse/DROOLS-699 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco The following test fails: {code} @Test public void testNotExists() { String drl2 = "import " + List.class.getCanonicalName() + ";\n" + "\n\n" + "rule \"NotExists\"\n" + "when\n" + "$l1: List() \n" + "$l2: List() \n" + "exists( String() from $l1 ) \n" + "not( exists( String() ) )\n" + "then end\n"; KieSession ksession = new KieHelper().addContent(drl2, ResourceType.DRL) .build() .newKieSession(); ksession.insert(asList("Mario", "Mark")); ksession.insert(asList("Julie", "Leiti")); assertEquals(4, ksession.fireAllRules()); } {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

by Liu Yan (JIRA)

[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ] Liu Yan commented on DROOLS-185: -------------------------------- Thank you for your suggestion. I bypassed this issue by replacing ClassB() with this $B: BaseClass() exists ClassB() from $B We will upgrade when we have to :) > ClassCastException at ConditionEvaluator > ---------------------------------------- > > Key: DROOLS-185 > URL: https://issues.jboss.org/browse/DROOLS-185 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Sergey Alaev > Assignee: Mario Fusco > > Stacktrace: > Caused by: java.lang.ClassCastException: ***** cannot be cast to ****** > at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318) > at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116) > at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > Reason: > ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments. > Given following: > interface A { > String getString(); > } > interface B { > String getString(); > } > class X implements B, A {} > class Y implements A{} > rule "test rule" > when: > A(string != null) > then: > end > When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B. > Thus second call with instance of class Y will cause ClassCastException of casting Y to B. > Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A. > Quickfix: use following declaration of class X: > class X implements A, B {} > Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1909) Add an AZURE_PING protocol

by Tristan Tarrant (JIRA)

Tristan Tarrant created JGRP-1909: ------------------------------------- Summary: Add an AZURE_PING protocol Key: JGRP-1909 URL: https://issues.jboss.org/browse/JGRP-1909 Project: JGroups Issue Type: Feature Request Reporter: Tristan Tarrant Assignee: Bela Ban Similar to the existing S3_PING and GOOGLE_PING, add an AZURE_PING which suppors node discovery using Azure's blob storage. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3698) Could not inject persistence unit into CDI managed bean

by Stanley Hillner (JIRA)

[ https://issues.jboss.org/browse/WFLY-3698?page=com.atlassian.jira.plugin.... ] Stanley Hillner commented on WFLY-3698: --------------------------------------- I don't understand why this issue has been marked as resolved. Was there any solution other than deactivating CDI for the whole deployment? I'm struggling with the same issue and deactivating DI for the module in which my DAO reside is no (or better an unacceptable) option since it is then not possible to inject these DAO into another module without using EJBs and JNDI-lookups. And this is exactly what I try to eliminate in the project. I will open a new issue for that problem since I think this is a bug in the implementation of Weld. > Could not inject persistence unit into CDI managed bean > ------------------------------------------------------- > > Key: WFLY-3698 > URL: https://issues.jboss.org/browse/WFLY-3698 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, JPA / Hibernate > Affects Versions: 8.1.0.Final > Environment: Windows 8.1 64 bits, Notebook Lenovo Z570 Intel Core i7 (2nd Gen) 2670QM / 2.2 GHz , 8GB RAM, using Eclipse Luna to develop > Reporter: Oscar Calderon > Assignee: Stuart Douglas > Original Estimate: 1 week > Remaining Estimate: 1 week > > I have a project running Spring 4 & JSF 2.1 using Primefaces 5 and Hibernate JPA 2.0. I use Wildfly 8.1 and configured a datasource pointing to an Oracle 10 database. The Wildfly datasource works fine (i've tested using plain JDBC) but when i try to create a LocalContainerEntityManagerFactoryBean through Spring i set the property persistenceUnitName to specify the name of my PU and then injecting in my DAOs using @PersistenceContext(unitName="myPersUnit"). > Using JBoss AS 7.1.1 Final works fine and even i don't need to specify persistenceUnitName and it creates as "default" and injects it to my DAOs without specifying name, but with JBoss 8.1 Final it doesn't work. With the same configuration, it shows me the next error: > Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named persUnit in deployment > But, when i remove the @PersistenceContext annotation from my property in my DAO, strangely it initializes the persistenceUnit as i can see in server log: > 08:19:57,144 INFO [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-13) HHH000204: Processing PersistenceUnitInfo [ > name: persUnit > ...] > But when i try to inject it, it doesn't -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015