August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9235) @Resource injection does not fail in a servlet when the resource is missing

by Stephen Coy (JIRA)

Stephen Coy created WFLY-9235: --------------------------------- Summary: @Resource injection does not fail in a servlet when the resource is missing Key: WFLY-9235 URL: https://issues.jboss.org/browse/WFLY-9235 Project: WildFly Issue Type: Bug Reporter: Stephen Coy Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-8954: ------------------------------- Forum Reference: https://developer.jboss.org/message/975253?et=watches.email.thread#975253 > Wildfly 10 with eclipselink Onscucess observer gets stale entity > ---------------------------------------------------------------- > > Key: WFLY-8954 > URL: https://issues.jboss.org/browse/WFLY-8954 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Nuno Godinho de Matos > Assignee: Scott Marlow > > Hi, > In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. > When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. > Then the observer will be working with stale entities that do not reflect the modifications done to the entity. > A sample application for this issue is available in: > https://github.com/99sono/wildfly10-observe-on-success-stale-entity > The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. > Many thanks for taking a look. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-8954: ------------------------------------ Excellent progress! I think it would be better if you start with adding the test to upstream (current master), as that would be where we would want to merge the fix. To ensure that the issue is fixed in some future release. If you start a WildFly branch that is based on the master branch, I can try running that locally and when I have time, can try making the change that I suggested. I'm also fine with you making the code change as well, just not sure if I explained enough yet. I didn't mention before, but one risk is that there could be some parts of EclipseLink that might need changing as well, to deal with the change that we are making. Specifically, we will be using [http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron...] instead of [http://docs.oracle.com/javaee/5/api/javax/transaction/Transaction.html#re...]. If we later discover that there are any parts of EclipseLink that need adjustment, that will impact our effort. For now, we should continue forward with resolving this issue on the WildFly side. [https://developer.jboss.org/wiki/HackingOnWildFly] may be useful to read as well. > Wildfly 10 with eclipselink Onscucess observer gets stale entity > ---------------------------------------------------------------- > > Key: WFLY-8954 > URL: https://issues.jboss.org/browse/WFLY-8954 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Nuno Godinho de Matos > Assignee: Scott Marlow > > Hi, > In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. > When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. > Then the observer will be working with stale entities that do not reflect the modifications done to the entity. > A sample application for this issue is available in: > https://github.com/99sono/wildfly10-observe-on-success-stale-entity > The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. > Many thanks for taking a look. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-106) Resources leak when an exception is thrown in "connect"

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/REMJMX-106?page=com.atlassian.jira.plugin... ] Yeray Borges resolved REMJMX-106. --------------------------------- Resolution: Duplicate Issue Duplicated by REMJMX-153 > Resources leak when an exception is thrown in "connect" > ------------------------------------------------------- > > Key: REMJMX-106 > URL: https://issues.jboss.org/browse/REMJMX-106 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.1.Final > Environment: Wildfly 10.0.0.Final > Reporter: Dominique Toupin > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-153) Remoting "endpoint" threads not existing after application stopped

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/REMJMX-153?page=com.atlassian.jira.plugin... ] Yeray Borges updated REMJMX-153: -------------------------------- Affects Version/s: 2.0.1.Final > Remoting "endpoint" threads not existing after application stopped > ------------------------------------------------------------------ > > Key: REMJMX-153 > URL: https://issues.jboss.org/browse/REMJMX-153 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 2.0.1.Final > Environment: - EAP 7.0.z > - JDK 8 > Reporter: Yeray Borges > Assignee: Yeray Borges > > Customer wrote a monitoring tool for JBoss which uses JMX, his env is EAP 7.0.6. When the jmx url is set to an invalid port, we are noticing the number of threads growing in EAP as the test run over the time. I can replicate his issue on my machine. The threads are > "Remoting "endpoint" I/O-1" > "Remoting "endpoint" task-1" > "Remoting "endpoint" Accept" > For example: > "Remoting "endpoint" Accept" #878 daemon prio=5 os_prio=0 tid=0x00007fe6dc1cf800 nid=0x4c2f runnable [0x00007fe66fbfe000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0x00000000e6f3a1f8> (a sun.nio.ch.Util$3) > - locked <0x00000000e6f3a1e8> (a java.util.Collections$UnmodifiableSet) > - locked <0x00000000e6f3a0d0> (a sun.nio.ch.EPollSelectorImpl) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > for the 200 loop, I can see 798 live threads, and 616 Daemon threads in JBoss. > The test scripts are: > run_test.sh is > for i in {1..200}; do curl -H "Content-Type: application/json" -X POST --data-binary "@jbmonitorRequestdata.txt" test1.redhat.com:8080/infra.jbossmonitor-0.0.4/beaninfo; done > and the jbmonitorRequestdata.txt is > [ > { > "user": "admin", > "password": "password", > "url": "service:jmx:remote+http://test1.redhat.com:1990", > "measurements": { > "jboss_web_ajp": "jboss.as:subsystem=web,connector=ajp", > "jboss_web_http": "jboss.as:subsystem=web,connector=http", > "jboss_datasource": "jboss.as:subsystem=datasources,data-source=*,statistics=pool" > }, > "tags": { > "host": "test1.redhat.com", > "application": "apiplatform", > "env": "dev" > } > } > ] > I will attach the customer code to this jira -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-153) Remoting "endpoint" threads not existing after application stopped

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/REMJMX-153?page=com.atlassian.jira.plugin... ] Yeray Borges moved JBEAP-12764 to REMJMX-153: --------------------------------------------- Project: Remoting JMX (was: JBoss Enterprise Application Platform) Key: REMJMX-153 (was: JBEAP-12764) Workflow: classic default workflow (was: CDW with loose statuses v1) Component/s: (was: Remoting) > Remoting "endpoint" threads not existing after application stopped > ------------------------------------------------------------------ > > Key: REMJMX-153 > URL: https://issues.jboss.org/browse/REMJMX-153 > Project: Remoting JMX > Issue Type: Bug > Environment: - EAP 7.0.z > - JDK 8 > Reporter: Yeray Borges > Assignee: Yeray Borges > > Customer wrote a monitoring tool for JBoss which uses JMX, his env is EAP 7.0.6. When the jmx url is set to an invalid port, we are noticing the number of threads growing in EAP as the test run over the time. I can replicate his issue on my machine. The threads are > "Remoting "endpoint" I/O-1" > "Remoting "endpoint" task-1" > "Remoting "endpoint" Accept" > For example: > "Remoting "endpoint" Accept" #878 daemon prio=5 os_prio=0 tid=0x00007fe6dc1cf800 nid=0x4c2f runnable [0x00007fe66fbfe000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) > at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) > at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0x00000000e6f3a1f8> (a sun.nio.ch.Util$3) > - locked <0x00000000e6f3a1e8> (a java.util.Collections$UnmodifiableSet) > - locked <0x00000000e6f3a0d0> (a sun.nio.ch.EPollSelectorImpl) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:515) > for the 200 loop, I can see 798 live threads, and 616 Daemon threads in JBoss. > The test scripts are: > run_test.sh is > for i in {1..200}; do curl -H "Content-Type: application/json" -X POST --data-binary "@jbmonitorRequestdata.txt" test1.redhat.com:8080/infra.jbossmonitor-0.0.4/beaninfo; done > and the jbmonitorRequestdata.txt is > [ > { > "user": "admin", > "password": "password", > "url": "service:jmx:remote+http://test1.redhat.com:1990", > "measurements": { > "jboss_web_ajp": "jboss.as:subsystem=web,connector=ajp", > "jboss_web_http": "jboss.as:subsystem=web,connector=http", > "jboss_datasource": "jboss.as:subsystem=datasources,data-source=*,statistics=pool" > }, > "tags": { > "host": "test1.redhat.com", > "application": "apiplatform", > "env": "dev" > } > } > ] > I will attach the customer code to this jira -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3190) CLI autocompletion handles incorrectly spaces in front of attribute name

by Martin Stefanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3190?page=com.atlassian.jira.plugi... ] Martin Stefanko commented on WFCORE-3190: ----------------------------------------- I can confirm, issue is still present, PR is working solution > CLI autocompletion handles incorrectly spaces in front of attribute name > ------------------------------------------------------------------------ > > Key: WFCORE-3190 > URL: https://issues.jboss.org/browse/WFCORE-3190 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 3.0.0.Beta31 > Reporter: Martin Stefanko > Assignee: Martin Stefanko > > CLI autocompletion behavior wrongly depends on space characters used in front of an attribute name. > See Steps to reproduce for details. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2210) EOFException[JGRP000030] : failed handling incoming message

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2210?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2210. ---------------------------- Resolution: Done > EOFException[JGRP000030] : failed handling incoming message > ----------------------------------------------------------- > > Key: JGRP-2210 > URL: https://issues.jboss.org/browse/JGRP-2210 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Dharam Thacker > Assignee: Bela Ban > Priority: Optional > Fix For: 3.6.14, 4.0.6 > > > Hi Team, > I am using Apache geode as our distributed caching solution which internally using JGroups 3.6.10.Final version. > I see this exception almost daily 5-6 times but we don't know the root cause for that. I tried reaching with Apache Geode community as well. As per their suggestion, it could be due to empty datagrams being sent to process. > I confirm that both of my client and server processes are using same version as 3.6.10.Final. > I would request you to look into the same. > *+Exception Stack Trace:+* > [error 2017/07/28 00:13:30.521 EDT EventServer <unicast receiver,hostXXX> tid=0x45] > JGRP000030: hostXXX<v2>:1025: failed handling incoming message: java.io.EOFException > java.io.EOFException > at org.jgroups.util.ByteArrayDataInputStream.readShort(ByteArrayDataInputStream.java:138) > at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1705) > at org.jgroups.protocols.TP.receive(TP.java:1654) > at org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160) > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701) > at java.lang.Thread.run(Thread.java:745) > Within our company, there is some cyber security server which keeps hitting our process & I get below warning as well, > [warning 2017/08/16 22:05:51.334 EDT EventServer <unicast receiver,hostXXX> tid=0x46] JGRP000010: packet from *hostYYY*:45482 has different version (0.0.2) than ours (3.6.10); packet is discarded > *hostYYY* is not a part of my cluster process [Neither client not server] but some cyber security scanner which knows about all hosts and have its own way to check for security violations > Response from Geode community: > https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9234) @Dependent bean instance created through javax.enterprise.inject.spi.CDI not always destroyed during shutdown

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9234?page=com.atlassian.jira.plugin.... ] Martin Kouba reassigned WFLY-9234: ---------------------------------- Assignee: Matej Novotny (was: Stuart Douglas) > @Dependent bean instance created through javax.enterprise.inject.spi.CDI not always destroyed during shutdown > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9234 > URL: https://issues.jboss.org/browse/WFLY-9234 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 11.0.0.Beta1 > Reporter: Matej Novotny > Assignee: Matej Novotny > Priority: Minor > > Doing {{CDI.current().select(MyDependentBean.class)}} gives you a bean which might not always be correctly destroyed on shutdown. > The spec does not clearly state what should happen with these instances but it makes sense to properly dispose of them on shutdown. See WELD-2413 for background information. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9234) @Dependent bean instance created through javax.enterprise.inject.spi.CDI not always destroyed during shutdown

by Matej Novotny (JIRA)

Matej Novotny created WFLY-9234: ----------------------------------- Summary: @Dependent bean instance created through javax.enterprise.inject.spi.CDI not always destroyed during shutdown Key: WFLY-9234 URL: https://issues.jboss.org/browse/WFLY-9234 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 11.0.0.Beta1 Reporter: Matej Novotny Assignee: Stuart Douglas Priority: Minor Doing {{CDI.current().select(MyDependentBean.class)}} gives you a bean which might not always be correctly destroyed on shutdown. The spec does not clearly state what should happen with these instances but it makes sense to properly dispose of them on shutdown. See WELD-2413 for background information. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 August 2017