June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3432) Perm Gen Memory, overflow of memory, Java heap space

by Thiago Hernandes (JIRA)

Thiago Hernandes created WFLY-3432: -------------------------------------- Summary: Perm Gen Memory, overflow of memory, Java heap space Key: WFLY-3432 URL: https://issues.jboss.org/browse/WFLY-3432 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Thiago Hernandes Assignee: Jason Greene I´ve a recent problem with Heap Memory. This: -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3431) outbound connection to remote ejbs attempts to use http upgrade even if protocol="remote" is specified.

by Jason Essington (JIRA)

Jason Essington created WFLY-3431: ------------------------------------- Summary: outbound connection to remote ejbs attempts to use http upgrade even if protocol="remote" is specified. Key: WFLY-3431 URL: https://issues.jboss.org/browse/WFLY-3431 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Remoting Affects Versions: 8.0.0.Final Reporter: Jason Essington Assignee: David Lloyd When attempting to connect to remote EJBs running on JBoss AS 7.2.0.Final from WildFly 8.0.0.Final, WildFly chooses to use http upgrade even though the outbound connection specifies protocol="remote" Outbound remoting connections in the wildfly config are defined like: {code:xml} <remote-outbound-connection name="remote-ds-connection" outbound-socket-binding-ref="remote-dataserver" username="calypso_user" security-realm="engine-security-realm" protocol="remote"> <properties> <property name="SASL_POLICY_NOANONYMOUS" value="false"/> <property name="SSL_ENABLED" value="false"/> </properties> </remote-outbound-connection> {code} Yet, when attempting to connect to remote EJBs located on the JBoss AS 7.2.0.Final server, the jboss log shows: {noformat} 11:10:21,581 ERROR [org.jboss.remoting.remote.connection] (Remoting "standalone-dataserver" read-1) JBREM000200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856 {noformat} and the stacktrace on wildfly shows: {noformat} 2014-06-02 11:10:21,506 WARN [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (ServerService Thread Pool -- 67) Could not register a EJB receiver for connection to localhost:4447: java.lang.RuntimeException: java.io.EOFException: XNIO000812: Connection closed unexpectedly at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final] ... clipped ... Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:298) [xnio-api-3.2.0.Final.jar:3.2.0.Final] at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:281) [xnio-api-3.2.0.Final.jar:3.2.0.Final] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.0.Final.jar:3.2.0.Final] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.0.Final.jar:3.2.0.Final] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) at org.xnio.nio.WorkerThread.run(WorkerThread.java:531) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) [jboss-remoting-4.0.0.Final.jar:4.0.0.Final] at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:187) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final] at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final] at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final] at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75) [jboss-ejb-client-2.0.0.Final.jar:2.0.0.Final] ... 110 more {noformat} and ultimately shows: {noformat} Caused by: java.lang.RuntimeException: Unable to connect to ejb:/dataserver//com.xxxx.yy.service.SomeService!com.xxxx.yy.service.SomeService at remote://localhost:4447 .... clipped ... {noformat} Which shows that it should be using a remote URL (as well as remote protocol rather than http-remoting) and is the same host/port on the connection defined in configuration. Yet the errors seem to indicate that WildFly is attempting to use http upgrade. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBWEB-300) High CPU in concurrent access to the JSSESupport keySizeCache map

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWEB-300?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWEB-300: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103018, https://bugzilla.redhat.com/show_bug.cgi?id=1103019, https://bugzilla.redhat.com/show_bug.cgi?id=1103808 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1103018, https://bugzilla.redhat.com/show_bug.cgi?id=1103019) > High CPU in concurrent access to the JSSESupport keySizeCache map > ----------------------------------------------------------------- > > Key: JBWEB-300 > URL: https://issues.jboss.org/browse/JBWEB-300 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > > The keySizeCache map in JSSESupport isn't protected from concurrent access and so can cause high CPU loops. The complete fix from the tomcat bug that had this map access synchronized wasn't used: > https://issues.apache.org/bugzilla/show_bug.cgi?id=47744 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3430) Recurring Timers are called concurrently

by Carlos Barragan (JIRA)

Carlos Barragan created WFLY-3430: ------------------------------------- Summary: Recurring Timers are called concurrently Key: WFLY-3430 URL: https://issues.jboss.org/browse/WFLY-3430 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 8.1.0.Final Reporter: Carlos Barragan Assignee: Jason Greene According to https://docs.jboss.org/author/display/WFLY8/EJB+3+Reference+Guide recurring timers should not be executed concurrently. That is not the case. I don't think the current behavior is actually expected. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3423) EJB timer create table code fails on postgresql

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3423?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3423. ---------------------------------- Fix Version/s: 9.0.0.Alpha1 Resolution: Done > EJB timer create table code fails on postgresql > ----------------------------------------------- > > Key: WFLY-3423 > URL: https://issues.jboss.org/browse/WFLY-3423 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-511) KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a pacakge doesn't exist

by Mike Wilson (JIRA)

Mike Wilson created DROOLS-511: ---------------------------------- Summary: KieContainerImpl.updateResourcesIncrementally throws NullPointerException when a pacakge doesn't exist Key: DROOLS-511 URL: https://issues.jboss.org/browse/DROOLS-511 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Mike Wilson Assignee: Mark Proctor When calling KieContainerImpl.updateToVersion(ReleaseId), we sometimes experience a NullPointerException during a chained set of method calls that try to obtain a package, and then a rule within it. If the package is null, a NullPointerException is thrown, because there is no check in place before that call to get the rule from the package. To prevent this, a null check should be added to the package before trying to get the rule from it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3409) Incorrect port number for commented out domain controller

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3409?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-3409. ------------------------------------ Resolution: Duplicate Issue > Incorrect port number for commented out domain controller > --------------------------------------------------------- > > Key: WFLY-3409 > URL: https://issues.jboss.org/browse/WFLY-3409 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Arun Gupta > Assignee: Jason Greene > > domain/configuration/host.xml has the following fragment: > <domain-controller> > <local/> >  >  > </domain-controller> > Even though the fragment is commented, the port number should be updated to 9990 anyway. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3410) Old “remote://“ protocol is hard coded RemoteDomainConnectionService

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3410?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-3410. ------------------------------------ Assignee: (was: Jason Greene) Resolution: Duplicate Issue > Old “remote://“ protocol is hard coded RemoteDomainConnectionService > -------------------------------------------------------------------- > > Key: WFLY-3410 > URL: https://issues.jboss.org/browse/WFLY-3410 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Arun Gupta > > Email conversation on wildfly-dev: > http://lists.jboss.org/pipermail/wildfly-dev/2014-May/002157.html > > 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ? > > > > <domain-controller> > > <remote host="10.211.55.7" port="9999"/> > > </domain-controller> > > > > FTR it only works with 9999, not with 9990. > > > > Domain Controller shows the message: > > > > [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host > > Controller Service Threads - 28) JBAS010918: Registered remote slave > > host "slave", WildFly 8.1.0.CR2 “Kenny” > It looks like we hardcode the old “remote://“ protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the <remote> element take a ‘protocol’ attribute? -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1438) Add support for listing WebSocket ServerEndpoints in the CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-1438?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-1438: ----------------------------------- Component/s: Web (Undertow) (was: CLI) (was: Web Services) I've removed the Web Services component and added Undertow, as I believe that's what's relevant here. Please correct if I am wrong. The CLI will expose as a low-level op whatever the server side exposes, so there's no CLI task here. > Add support for listing WebSocket ServerEndpoints in the CLI > ------------------------------------------------------------ > > Key: WFLY-1438 > URL: https://issues.jboss.org/browse/WFLY-1438 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management, Web (Undertow) > Affects Versions: 8.0.0.Alpha1 > Reporter: Rich Midwinter > Priority: Minor > > It would be useful to be able to list ServerEndpoints in the cli. This was available in AS7. > https://community.jboss.org/thread/228658 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-568) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-568?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-568: ---------------------------------- Assignee: Emanuel Muckenhuber > Consider using a "describe" notion for providing the model to slaves on registration > ------------------------------------------------------------------------------------ > > Key: WFLY-568 > URL: https://issues.jboss.org/browse/WFLY-568 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 9.0.0.CR1 > > > When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave. > Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC. > This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014