May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1845) Null pointer exception in Samsung Q1 using 3G connection

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1845?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1845. ---------------------------- Resolution: Done OK, checking for null value in master and 3.4 > Null pointer exception in Samsung Q1 using 3G connection > -------------------------------------------------------- > > Key: JGRP-1845 > URL: https://issues.jboss.org/browse/JGRP-1845 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.1, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.2.8, 3.2.9, 3.2.10, 3.2.12, 3.2.13, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4, 3.4.1, 3.4.2, 3.4.3, 3.4.4 > Environment: Samsung Q1 with Windows XP Tablet Edition and 3G connection. Java 6 or Java 7. > Reporter: Denis Lamela > Assignee: Bela Ban > Priority: Minor > Fix For: 3.3.6, 3.4.5, 3.5 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Null pointer exception in method "bindToInterfaces" of class "org.jgroups.stack.DiagnosticsHandler". The exception is thrown while executing "i.getInterfaceAddresses().isEmpty()". "i.getInterfaceAddresses()" returns null. > This bug can be fixed checking if "i.getInterfaceAddresses()" returns null. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-195) Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-195: ------------------------------------------------ ppecka <ppecka(a)redhat.com> changed the Status of [bug 1031099|https://bugzilla.redhat.com/show_bug.cgi?id=1031099] from ON_QA to VERIFIED > Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-195 > URL: https://issues.jboss.org/browse/DROOLS-195 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Alessandro Lazarotti > Assignee: Mario Fusco > Attachments: LoopTest.java > > > When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes > Attached unit test > Version: 5.3.0 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-72) Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-72?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on DROOLS-72: ----------------------------------------------- ppecka <ppecka(a)redhat.com> changed the Status of [bug 1036126|https://bugzilla.redhat.com/show_bug.cgi?id=1036126] from ON_QA to VERIFIED > Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-72 > URL: https://issues.jboss.org/browse/DROOLS-72 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Trung Nguyen > Assignee: Mario Fusco > Fix For: 5.5.1.Final, 6.0.0.Alpha9 > > > when {{ksession.fireAllRules()}} throws RuntimeException, it cause {{ksession}} never gets released. > {code:lang=java} > public void execute(Object object) { > StatefulKnowledgeSession ksession = newWorkingMemory(); > ksession.insert( object ); > ksession.fireAllRules( ); > ksession.dispose(); > } > public void execute(Iterable objects) { > StatefulKnowledgeSession ksession = newWorkingMemory(); > for ( Object object : objects ) { > ksession.insert( object ); > } > ksession.fireAllRules( ); > ksession.dispose(); > } > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1845) Null pointer exception in Samsung Q1 using 3G connection

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1845?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1845: -------------------------------- This is interesting... I checked {{NetworkInterface.getInterfaceAddresses()}} and it always return a non-null value. Which JDK did you use (I checked JDK 7) > Null pointer exception in Samsung Q1 using 3G connection > -------------------------------------------------------- > > Key: JGRP-1845 > URL: https://issues.jboss.org/browse/JGRP-1845 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.1, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7, 3.2.8, 3.2.9, 3.2.10, 3.2.12, 3.2.13, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4, 3.4.1, 3.4.2, 3.4.3, 3.4.4 > Environment: Samsung Q1 with Windows XP Tablet Edition and 3G connection. Java 6 or Java 7. > Reporter: Denis Lamela > Assignee: Bela Ban > Priority: Minor > Fix For: 3.3.6, 3.4.5, 3.5 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > Null pointer exception in method "bindToInterfaces" of class "org.jgroups.stack.DiagnosticsHandler". The exception is thrown while executing "i.getInterfaceAddresses().isEmpty()". "i.getInterfaceAddresses()" returns null. > This bug can be fixed checking if "i.getInterfaceAddresses()" returns null. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3411) EJB/JPA error when call to persist

by Wilber Saca (JIRA)

Wilber Saca created WFLY-3411: --------------------------------- Summary: EJB/JPA error when call to persist Key: WFLY-3411 URL: https://issues.jboss.org/browse/WFLY-3411 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB Affects Versions: 8.1.0.CR2, 8.1.0.CR1 Environment: - WildFly 8.1.0.CR2 - EclipseLink 2.5.1 (Added) - JSF - Netbeans 8 Reporter: Wilber Saca Assignee: David Lloyd Fix For: 8.1.0.Final I'm getting an exception when I try to persist an object for second time, after get an exception because of duplicate primary key. I have tested the same application on GlassFish 4 with JSF(Mojarra) 2.2.6, EclipsLink 2.5.1 and this error is not fired, all works fine. I also tried changing the default datasource setting in Wildfly. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1832) Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups

by Shay Matasaro (JIRA)

[ https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin.... ] Shay Matasaro commented on JGRP-1832: ------------------------------------- The current test focuses mainly on identifying mcast issues which is a great diagnostics start , and we use the largestate test to identify issues such as dropped packets etc.. But the largestate test uses a much bigger stack, is more complex to configure and run, and it uses unicast. 1) It would be great if the mcast sender had a feature , that will fire a stream of sequentially numbered datagrams(for example 1,2,3,...100) to the mcast address , and the receiver will identify and log any gaps in sequence. This will also allow us to run multiple receivers, one on each node, with one sender and complete testing of multiple nodes in one shot , rather then running the test multiple times on "node couples" 2) Can the test detect inefficient mtu fragmentation and defragmantation along a route? 3) In order to track packet loss issues , we sometimes use jgroups at debug or trace log level. But, enabling jgroups debug/trace logging in a production environment , is tricky and can slow down the server, especially if debug level is enabled on multiple servers. It would be great if we can run a receiver instance(lets call it listener) that will listen to the mcast cluster traffic and log relevant data(but obviously will not interfere) This allows us to trace mcast in a separate process or even a different machine without any impact to the prod server. The important aspect here is the ability to correlate the receiver log lines to the log lines on servers for which we did enable jgroups debug. 4) The information that the listener is recording could be further improved , and provide great help , I have quiet a few suggestions on that front but i don’t want to make this comment too long one example would be that the listener log can be further precessed by an analysis tool to detect split-brain , or cluster collisions. let me know what you think? more suggestions to come ;) > Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups > ------------------------------------------------------------------------------------------ > > Key: JGRP-1832 > URL: https://issues.jboss.org/browse/JGRP-1832 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4.3 > Reporter: Dennis Reed > Assignee: Dennis Reed > Priority: Optional > Fix For: 3.4.5, 3.5 > > > JGroups binds multicast sockets using specific MulticastSocket constructors depending on the operating system (to avoid crosstalk issues). > McastSenderTest and McastReceiverTest always bind the socket using the basic MulticastSocket(port) constructor. > In order to more closely test the way JGroups will be sending and receiving the packets, these tests will be updated to bind the sockets the same way. -- 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 Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3386?page=com.atlassian.jira.plugin.... ] Jozef Hartinger reassigned WFLY-3386: ------------------------------------- Assignee: Martin Kouba (was: Jozef Hartinger) > 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] (WFLY-3329) EJBs with same Java class name not intercepted by CDI interceptors

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/WFLY-3329?page=com.atlassian.jira.plugin.... ] Jozef Hartinger reassigned WFLY-3329: ------------------------------------- Assignee: Martin Kouba (was: Stuart Douglas) > EJBs with same Java class name not intercepted by CDI interceptors > ------------------------------------------------------------------ > > Key: WFLY-3329 > URL: https://issues.jboss.org/browse/WFLY-3329 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 8.0.0.Final > Reporter: Maxim Frolov > Assignee: Martin Kouba > Labels: ejb, ejb3.1, interceptor > > h3. Given > Two or more EJBs with the same Java class name but from different Java deployments. > h3. Problem > Interceptor intercepts method calls to only one of the EJBs. > An EJB to be intercepted seems to be chosen randomly after each redeployment. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2867) Reduce usage of Apache DS components

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2867?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2867: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 1012354|https://bugzilla.redhat.com/show_bug.cgi?id=1012354] from ON_QA to VERIFIED > Reduce usage of Apache DS components > ------------------------------------ > > Key: WFLY-2867 > URL: https://issues.jboss.org/browse/WFLY-2867 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: Carlo de Wolf > Assignee: Carlo de Wolf > Priority: Critical > Fix For: 8.0.0.Final > > > To mitigate https://bugzilla.redhat.com/show_bug.cgi?id=1012354 reduce the actual usage of Apache DS components. This result in less classes being applicable during annotation scanning. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2789) Remote client transaction timeout values are overwrote by hardcoded values

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2789?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2789: ----------------------------------------------- Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1093752|https://bugzilla.redhat.com/show_bug.cgi?id=1093752] from POST to MODIFIED > Remote client transaction timeout values are overwrote by hardcoded values > -------------------------------------------------------------------------- > > Key: WFLY-2789 > URL: https://issues.jboss.org/browse/WFLY-2789 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Johnathon Lee > Assignee: David Lloyd > Fix For: 8.1.0.Final, 9.0.0.Alpha1 > > > The EJB3 interceptor is not using client values for timeouts, this is a problem for users trying to use EJB for transaction propagation. > Refer to the code in https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...: > private void createOrResumeXidTransaction(final XidTransactionID xidTransactionID) throws Exception { > final TransactionManager transactionManager = this.ejbRemoteTransactionsRepository.getTransactionManager(); > final Transaction alreadyCreatedTx = this.ejbRemoteTransactionsRepository.getImportedTransaction(xidTransactionID); > if (alreadyCreatedTx != null) { > // resume the already created tx > transactionManager.resume(alreadyCreatedTx); > } else { > // begin a new tx and add it to the tx repository > // TODO: Fix the tx timeout (which currently is passed as 300 seconds) > final Transaction newSubOrdinateTx = this.ejbRemoteTransactionsRepository.importTransaction(xidTransactionID, 300); > // associate this tx with the thread > transactionManager.resume(newSubOrdinateTx); > } > } -- 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