March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1082) Querying for objects before any have been inserted prevents Class Aware Object Store from working properly

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1082?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1082: ----------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Querying for objects before any have been inserted prevents Class Aware Object Store from working properly > ---------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1082 > URL: https://issues.jboss.org/browse/DROOLS-1082 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: James Elford > Assignee: Mario Fusco > > In the presence of a class heirarchy, the {{ClassAwareObjectStore}} doesn't properly manage the relationships between {{SingleClassStores}} - specifically, it can become permanently corrupt if the following order of events occurs: > * Insert object of type {{BaseClass}} > * Query for objects of type {{SubClass}} > ** Note that it's important this query is fully evaluated (e.g. copy it into a list) > * Insert object of type {{SubClass}} > Subsequent queries for objects of type {{BaseClass}} will _not_ return objects of type {{SubClass}}. If the intervening query for {{SubClass}} is left out, they would. > The problem's in {{ClassAwareObjectStore#getOrCreateConcreteClass}}, where it tries to concretize an existing (non-concrete) store. It should go through the same "linking" process that gets done in the {{existingStore == null}} case (and half of which is done already in {{#getOrCreateClassStore}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1311) emptyManagedConnectionPool can cause dead lock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1311?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1311: ------------------------------------------------ Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1310671|https://bugzilla.redhat.com/show_bug.cgi?id=1310671] from ON_QA to VERIFIED > emptyManagedConnectionPool can cause dead lock > ---------------------------------------------- > > Key: JBJCA-1311 > URL: https://issues.jboss.org/browse/JBJCA-1311 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: WildFly/IronJacamar 1.3.2.Final, 1.0.35.Final, 1.2.6.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Blocker > Fix For: WildFly/IronJacamar 1.3.3.Final, 1.0.36.Final, 1.2.7.Final > > > Can happen in scenarios where multiple credentials are used for the pool (PoolByCri / PoolByCRIAndSubject) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2023) Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2023?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2023. ---------------------------- Resolution: Won't Fix Root cause was an incorrectly configured IPv6 routing table > Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified > ----------------------------------------------------------------------------------------------- > > Key: JGRP-2023 > URL: https://issues.jboss.org/browse/JGRP-2023 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7, 3.6.8 > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Reporter: Richard Janík > Assignee: Bela Ban > > When setting {{-bind_addr}} to localhost (either 127.0.0.1 or ::1) without specifying {{-Djava.net.preferIPv4Stack=true}}, JGroups fail to connect. The following errors are logged: > {code} > ------------------------------------------------------------------- > GMS: address=rjanik-24069, cluster=draw, physical address=0:0:0:0:0:0:0:1:37921 > ------------------------------------------------------------------- > Mar 03, 2016 11:41:12 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (108 bytes): java.io.IOException: Network is unreachable, headers: PING: [type=GET_MBRS_REQ, cluster=draw], TP: [cluster_name=draw] > ** View=[rjanik-24069|0] (1) [rjanik-24069] > Mar 03, 2016 11:41:15 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (56 bytes): java.io.IOException: Network is unreachable, headers: NAKACK2: [MSG, seqno=1], TP: [cluster_name=draw] > {code} > I'm not sure if there's some other configuration option that I forgot to add, but the example (in Steps to Reproduce) works with previous versions (3.6.6 for example), so I assume not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2023) Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2023?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2023: -------------------------------- OK. IPv6 multicasting over loopback does work on my Mac Mini, MacbookPro laptop and Fedora workstation, without problems. Closing this issue now... > Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified > ----------------------------------------------------------------------------------------------- > > Key: JGRP-2023 > URL: https://issues.jboss.org/browse/JGRP-2023 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7, 3.6.8 > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Reporter: Richard Janík > Assignee: Bela Ban > > When setting {{-bind_addr}} to localhost (either 127.0.0.1 or ::1) without specifying {{-Djava.net.preferIPv4Stack=true}}, JGroups fail to connect. The following errors are logged: > {code} > ------------------------------------------------------------------- > GMS: address=rjanik-24069, cluster=draw, physical address=0:0:0:0:0:0:0:1:37921 > ------------------------------------------------------------------- > Mar 03, 2016 11:41:12 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (108 bytes): java.io.IOException: Network is unreachable, headers: PING: [type=GET_MBRS_REQ, cluster=draw], TP: [cluster_name=draw] > ** View=[rjanik-24069|0] (1) [rjanik-24069] > Mar 03, 2016 11:41:15 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (56 bytes): java.io.IOException: Network is unreachable, headers: NAKACK2: [MSG, seqno=1], TP: [cluster_name=draw] > {code} > I'm not sure if there's some other configuration option that I forgot to add, but the example (in Steps to Reproduce) works with previous versions (3.6.6 for example), so I assume not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1083) Drools eclipse rule editor throws an error when opening or saving a drools file

by Ido Flax (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1083?page=com.atlassian.jira.plugi... ] Ido Flax updated DROOLS-1083: ----------------------------- Issue Type: Bug (was: Feature Request) > Drools eclipse rule editor throws an error when opening or saving a drools file > ------------------------------------------------------------------------------- > > Key: DROOLS-1083 > URL: https://issues.jboss.org/browse/DROOLS-1083 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.CR1 > Environment: Spring Tool Suite > Version: 3.6.4.RELEASE > Build Id: 201503100339 > Platform: Eclipse Luna SR1 (4.4.2) > MacBook Pro (Retina, 15-inch, Late 2013) OSX 10.10.2 > Reporter: Ido Flax > Assignee: Robert (Bob) Brodt > Attachments: Screen Shot 2016-03-08 at 10.25.26.png > > > I downloaded the Red hat jboss developer studio tools plugin for eclipse and since then whenever i open or save my drools file or switch to it's open tab i get this error: > {code:java} > An error has occurred. See error log for more details. > Could not initialize class org.kie.internal.utils.ServiceRegistryImpl > {code} > This also prevents the drools compiler from showing me errors or problems with my drools code. > I'll also mention that it randomly stopped doing it at some point but when i closed and reopened my eclipse it started again -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2023) Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/JGRP-2023?page=com.atlassian.jira.plugin.... ] Richard Janík commented on JGRP-2023: ------------------------------------- I have an update. After examining my routing tables with {{route -6}} and adding a new route for IPv6 localhost with {{sudo route -6 add ::1/0 dev lo}}, I was able to get rid of the error message. I still didn't manage to actually create a cluster when binding to localhost (IPv6). That makes sense though, since the only line in my routing table pertaining to the multicast address JGroups communicate on, is this: {code} Destination Next Hop Flag Met Ref Use If ff00::/8 [::] U 256 1 1133 enp0s25 {code} Any attempt to add a similar route that sends messages to loopback interface, results in a route being added with "!" flag - which means the network is unreachable. I've added the multicast flag to my {{lo}} interface too: {{ifconfig lo multicast}}. I'm sure that there's something I don't know about IPv6 that's getting in the way. I'd like to dig some more in it, but I don't think I'll be able to find much more time. Anyway, I now believe the problem is with my default configuration so I think this can be closed. Thanks. > Network unreachable with localhost addresses if -Djava.net.preferIPv4Stack=true isn't specified > ----------------------------------------------------------------------------------------------- > > Key: JGRP-2023 > URL: https://issues.jboss.org/browse/JGRP-2023 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.7, 3.6.8 > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > Reporter: Richard Janík > Assignee: Bela Ban > > When setting {{-bind_addr}} to localhost (either 127.0.0.1 or ::1) without specifying {{-Djava.net.preferIPv4Stack=true}}, JGroups fail to connect. The following errors are logged: > {code} > ------------------------------------------------------------------- > GMS: address=rjanik-24069, cluster=draw, physical address=0:0:0:0:0:0:0:1:37921 > ------------------------------------------------------------------- > Mar 03, 2016 11:41:12 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (108 bytes): java.io.IOException: Network is unreachable, headers: PING: [type=GET_MBRS_REQ, cluster=draw], TP: [cluster_name=draw] > ** View=[rjanik-24069|0] (1) [rjanik-24069] > Mar 03, 2016 11:41:15 AM org.jgroups.protocols.TP$BaseBundler sendSingleMessage > SEVERE: JGRP000029: rjanik-24069: failed sending message to cluster (56 bytes): java.io.IOException: Network is unreachable, headers: NAKACK2: [MSG, seqno=1], TP: [cluster_name=draw] > {code} > I'm not sure if there's some other configuration option that I forgot to add, but the example (in Steps to Reproduce) works with previous versions (3.6.6 for example), so I assume not. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5565) JMSBridge executor service is oblivious to TCCL

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5565?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski resolved WFLY-5565. -------------------------------------- Resolution: Cannot Reproduce > JMSBridge executor service is oblivious to TCCL > ----------------------------------------------- > > Key: WFLY-5565 > URL: https://issues.jboss.org/browse/WFLY-5565 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > > In certain conditions( time sensitive) TCCL of JMS Bridge handle failure use artemis module, rather than custom one provided to bridge. Check BZ. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5565) JMSBridge executor service is oblivious to TCCL

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5565?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski reassigned WFLY-5565: ---------------------------------------- Assignee: Bartosz Baranowski (was: Jeff Mesnil) > JMSBridge executor service is oblivious to TCCL > ----------------------------------------------- > > Key: WFLY-5565 > URL: https://issues.jboss.org/browse/WFLY-5565 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > > In certain conditions( time sensitive) TCCL of JMS Bridge handle failure use artemis module, rather than custom one provided to bridge. Check BZ. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6104) Too many invocations to a remote EJB from multiple threads cause infinite wait

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-6104: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1302181, https://bugzilla.redhat.com/show_bug.cgi?id=1316380 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1302181) > Too many invocations to a remote EJB from multiple threads cause infinite wait > ------------------------------------------------------------------------------ > > Key: WFLY-6104 > URL: https://issues.jboss.org/browse/WFLY-6104 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1302181 > While a thread (1) of EJB client invokes a remote EJB which needs long > processing time and wait for the response, if the other threads complete > more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like > below occurs in EJB client side and the waiting thread (1) falls into > infinite wait for the response. > INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no > waiting context found > All invocations should successfully complete regardless of the number of > invocations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBEE-163) org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-163?page=com.atlassian.jira.plugin.s... ] Scott Marlow closed JBEE-163. ----------------------------- Resolution: Done > org.jboss.el.cache.BeanPropertiesCache leaks memory in static void clear(ClassLoader classLoader) > ------------------------------------------------------------------------------------------------- > > Key: JBEE-163 > URL: https://issues.jboss.org/browse/JBEE-163 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Blocker > Fix For: 1.0.6 > > > Originally reported via https://github.com/jboss/jboss-el-api_spec/issues/19 (which includes the suggested fix). > To recreate, run the WildFly org.jboss.as.test.integration.jsf.beanvalidation.cdi.BeanValidationCdiIntegrationTestCase test and set a break point in org.jboss.el.cache.BeanPropertiesCache.clear(ClassLoader) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 March 2016