September 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4889) Subsequent create/close of javax.naming.Context leads to IllegalStateException

by Miroslav Novak (JIRA)

Miroslav Novak created AS7-4889: ----------------------------------- Summary: Subsequent create/close of javax.naming.Context leads to IllegalStateException Key: AS7-4889 URL: https://issues.jboss.org/browse/AS7-4889 Project: Application Server 7 Issue Type: Bug Components: Remoting Affects Versions: 7.1.2.Final (EAP) Reporter: Miroslav Novak Assignee: David Lloyd Priority: Minor Fix For: 7.1.3.Final (EAP) When standalone client tries to create/close javax.naming.Context multiple times in a row then IllegalStateException will occur. Exception: {code} ERROR: A channel event listener threw an exception java.lang.IllegalStateException at org.xnio.Buffers$4.getResource(Buffers.java:1782) at org.xnio.Buffers$4.getResource(Buffers.java:1768) at org.xnio.channels.FramedMessageChannel.receive(FramedMessageChannel.java:84) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:72) at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.nio.NioHandle.run(NioHandle.java:90) at org.xnio.nio.WorkerThread.run(WorkerThread.java:184) {code} I hit this problem for 28th iteration. There is 500ms sleep between subsequent tries. Reproducer attached. I'm setting lower priority because this is not common use case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
7
0 / 0

[JBoss JIRA] (AS7-5367) ApplicationClientStructureProcessor does not clean up mounts in undeploy()

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5367: ------------------------------------- Summary: ApplicationClientStructureProcessor does not clean up mounts in undeploy() Key: AS7-5367 URL: https://issues.jboss.org/browse/AS7-5367 Project: Application Server 7 Issue Type: Bug Components: Application Client Affects Versions: 7.1.2.Final (EAP) Reporter: Brian Stansberry Assignee: Stuart Douglas Fix For: 7.2.0.CR1, 7.1.4.Final (EAP) We're seeing temp files left behind in appclient/tmp when testsuites that use appclient run. Theory is this is because there is no cleanup in ApplicationClientStructureProcessor.undeploy(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
7
0 / 0

[JBoss JIRA] (AS7-5545) Upgrade to Remoting JMX 1.1.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-5545: ------------------------------------- Summary: Upgrade to Remoting JMX 1.1.0.Beta1 Key: AS7-5545 URL: https://issues.jboss.org/browse/AS7-5545 Project: Application Server 7 Issue Type: Task Components: JMX, Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1511) Relaying node does not connect bridge bus if another cluster exists

by Jiri Pechanec (JIRA)

Jiri Pechanec created JGRP-1511: ----------------------------------- Summary: Relaying node does not connect bridge bus if another cluster exists Key: JGRP-1511 URL: https://issues.jboss.org/browse/JGRP-1511 Project: JGroups Issue Type: Bug Affects Versions: 3.2 Environment: jgroups-3.2.0.Alpha1.jar Fedora 14 java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10) (fedora-55.1.9.10.fc14-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) Reporter: Jiri Pechanec Assignee: Bela Ban I tried to simulate geo cluster using RELAY2. Configuration files are attached and were developed from vanilla udp.xml and tcp.xml. The cluster setup two machines 10.34.3.135 10.34.40.20 Each machines run two instances of Chat demo. One with plain UDP stack bound to localhost, second with mixed UDP stack bound to localhost and RELAY2 bridge to the other machine. When relaying instance is started first it prints {noformat} ------------------------------------------------------------------- GMS: address=jpechane-16703, cluster=ChatCluster, physical address=127.0.0.1:47331 ------------------------------------------------------------------- ------------------------------------------------------------------- GMS: address=_jpechane-16703:NTB, cluster=global, physical address=10.34.3.135:7800 ------------------------------------------------------------------- ** view: [jpechane-16703|0] [jpechane-16703] {noformat} and the geo cluster is properly formed. If a UDP-only instance is started first and then the relaying instace, it prints {noformat} ------------------------------------------------------------------- GMS: address=jpechane-36521, cluster=ChatCluster, physical address=127.0.0.1:52324 ------------------------------------------------------------------- ** view: [jpechane-64562|1] [jpechane-64562, jpechane-36521] > {noformat} As you can see only local part of the cluster and not the geo bus was started. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
8
0 / 0

[JBoss JIRA] (JGRP-1512) RELAY2: Invalid message type when delivered from a node in one geo location to a node in another

by Jiri Pechanec (JIRA)

Jiri Pechanec created JGRP-1512: ----------------------------------- Summary: RELAY2: Invalid message type when delivered from a node in one geo location to a node in another Key: JGRP-1512 URL: https://issues.jboss.org/browse/JGRP-1512 Project: JGroups Issue Type: Bug Affects Versions: 3.2 Environment: jgroups-3.2.0.Alpha1.jar Fedora 14, Solaris 10 java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10) (fedora-55.1.9.10.fc14-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) java version "1.6.0_17" Java(TM) SE Runtime Environment (build 1.6.0_17-b04) Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode) Reporter: Jiri Pechanec Assignee: Bela Ban I tried to simulate geo cluster using RELAY2. Configuration files are attached and were developed from vanilla udp.xml and tcp.xml. The cluster setup two machines 10.34.3.135 10.34.40.20 Each machines run two instances of Chat demo. One with plain UDP stack bound to localhost (node1 and node2), second with mixed UDP stack bound to localhost and RELAY2 bridge (bridge1 and bridge2) to the other machine. When the cluster is formed I tried to send a message 'testmessage' from node2 (Solaris machine) to node1 (Fedora machine). The message was properly delivered to bridge2 (Solaris) and bridge1 (Fedora) but on the node1 (Fedora) an exception is thrown {noformat} SEVERE: couldn't deliver message [dst: <null>, src: jpechane-28748 (3 headers), size=21 bytes] java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: type 4 is invalid at org.jgroups.Message.getObject(Message.java:378) at org.jgroups.demos.Chat.receive(Chat.java:19) at org.jgroups.JChannel.invokeCallback(JChannel.java:757) at org.jgroups.JChannel.up(JChannel.java:718) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:178) at org.jgroups.protocols.RSVP.up(RSVP.java:188) at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:899) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) at org.jgroups.protocols.UNICAST.up(UNICAST.java:414) at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:742) at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:536) at org.jgroups.protocols.BARRIER.up(BARRIER.java:126) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) at org.jgroups.protocols.Discovery.up(Discovery.java:359) at org.jgroups.protocols.TP.passMessageUp(TP.java:1210) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1774) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1742) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: java.lang.IllegalArgumentException: type 4 is invalid at org.jgroups.util.Util.objectFromByteBuffer(Util.java:463) at org.jgroups.Message.getObject(Message.java:375) ... 26 more {noformat} Log files for all instances are attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
4
0 / 0

[JBoss JIRA] (AS7-5343) SAR MBean attribute whose string attribute uses ${} are not replaced with sysprop values

by John Mazzitelli (JIRA)

John Mazzitelli created AS7-5343: ------------------------------------ Summary: SAR MBean attribute whose string attribute uses ${} are not replaced with sysprop values Key: AS7-5343 URL: https://issues.jboss.org/browse/AS7-5343 Project: Application Server 7 Issue Type: Bug Reporter: John Mazzitelli Fix For: 7.1.1.Final Attachments: test.sar See the attached .sar as a test to replicate this - just deploy it in a 7.1.1.Final standalone/deployments directory and run it as explained below. This SAR has a String attribute. Its value is made up of some ${x} with some static text: <attribute name="MyStr">my.sys.prop=${my.sys.prop} jboss.home.dir=${jboss.home.dir} java.version=${java.version}</attribute> Start the AS7 server with the cmd line option "-Dmy.sys.prop=boo" (I also tried this with my.sys.prop=boo in a "my.properties" file and I passed in "-P my.properties" - same problem happens). When you look in the logs, the MBean will print out the value it gets in its setting method: 15:19:41,448 INFO [stdout] (MSC service thread 1-5) STR attribute being set to=my.sys.prop=${my.sys.prop} jboss.home.dir=${jboss.home.dir} java.version=${java.version} Notice none of the ${x} tokens are replaced. Not even the JVM sysprop "java.version" - nor the JBoss "jboss.home.dir" - nor the one I passed into AS7 (my.sys.prop). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
11
0 / 0

[JBoss JIRA] (AS7-5543) [7.1] Intermittent failure due to missing OSGi service

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5543: ----------------------------------- Summary: [7.1] Intermittent failure due to missing OSGi service Key: AS7-5543 URL: https://issues.jboss.org/browse/AS7-5543 Project: Application Server 7 Issue Type: Bug Components: OSGi, Server Reporter: Thomas Diesler Assignee: David Lloyd Priority: Critical Fix For: 7.2.0.Alpha1 For the first OSGi related deployments we intermittently see {code} Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER {code} which is due to a race condition at subsystem startup. h4. Background At startup the framework goes through various phases # Framework.CREATE # Framework.INIT # Framework.ACTIVE During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings. In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down. Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services. AFAICS, there is currently no way to model this type of dependency properly without having this race condition. A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed) h4. Example * serviceA depends on serviceB with DependencyType.WEAK * serviceA starts when serviceB has started * serviceA stays UP when serviceB gets removed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] (AS7-4746) DuplicateServiceException: Service jbosgi.integration.PersistentBundlesHandler is already registered

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-4746: ----------------------------------- Summary: DuplicateServiceException: Service jbosgi.integration.PersistentBundlesHandler is already registered Key: AS7-4746 URL: https://issues.jboss.org/browse/AS7-4746 Project: Application Server 7 Issue Type: Bug Reporter: Thomas Diesler Fix For: 7.1.2.Final (EAP) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
15
0 / 0

[JBoss JIRA] (REMJMX-54) Release 1.1.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-54: -------------------------------------- Summary: Release 1.1.0.Beta1 Key: REMJMX-54 URL: https://issues.jboss.org/browse/REMJMX-54 Project: Remoting JMX Issue Type: Task Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-53) Release 1.0.5.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-53: -------------------------------------- Summary: Release 1.0.5.Final Key: REMJMX-53 URL: https://issues.jboss.org/browse/REMJMX-53 Project: Remoting JMX Issue Type: Task Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.5.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
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 September 2012