June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2035) Clean the status of testing jars for jboss-vfs

by Marek Goldmann (Created) (JIRA)

Clean the status of testing jars for jboss-vfs ---------------------------------------------- Key: AS7-2035 URL: https://issues.jboss.org/browse/AS7-2035 Project: Application Server 7 Issue Type: Task Components: VFS Reporter: Marek Goldmann Assignee: John Bailey There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior. What's the status of following files? Who wrote them and what is the license of those and where is the upstream code? ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar Can they be replaced with something dummy? -- 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

2
1
0 / 0

[JBoss JIRA] (AS7-2178) Deployment cannot create dependency on unresolved OSGi bundle

by Thomas Diesler (Created) (JIRA)

Deployment cannot create dependency on unresolved OSGi bundle ------------------------------------------------------------- Key: AS7-2178 URL: https://issues.jboss.org/browse/AS7-2178 Project: Application Server 7 Issue Type: Bug Components: OSGi Reporter: Thomas Diesler Assignee: Thomas Diesler The Module related to an OSGi bundle becomes available when the bundle transitions from INSTALLED to RESOLVED. An installed bundle is not visible to the common ModuleLoader. The solution would be to use a common resolver for both OSGi and non-OSGi deployments. -- 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
6
0 / 0

[JBoss JIRA] Created: (AS7-1834) FS deployment scanner uses different order resulting in failing deployments

by Rico Neubauer (JIRA)

FS deployment scanner uses different order resulting in failing deployments --------------------------------------------------------------------------- Key: AS7-1834 URL: https://issues.jboss.org/browse/AS7-1834 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.0.1.Final, 7.1.0.Alpha1 Environment: Windows 7 (most probably not specific to this OS) Reporter: Rico Neubauer Assignee: Jason Greene Experiencing a different behavior in deployment depending upon deployment order. I have some OSGi bundles and one EJB-jar, which defines a dependency upon one of the bundles using: Dependencies: deployment.com.companyname.common.CompUtil:0.0.1.SNAPSHOT This works fine and everything works, when the EJB-jar gets deployed after all the OSGi-bundles are already started, see attached log server_startup_working_due_to_deployment_of_EJBs_delayed.txt However, when re-deploying all deployments, or just on a simple restart, all of the deployments fail, since it seems that this dependency leads some undefined state where in consequence also the VFS loses its mount-points, as can be seen here, where the mount point is in the start-up directory, which obviously causes a FNFEx: FileNotFoundException: D:\test\jboss-as-7.1.0.Alpha1-2011-09-12\bin\content\com.seeburger.lib.ext_1.0.0.jar\axiom-dom.jar See full log attached. Everything also works fine, when replacing the EJB-jar with an EJB-jar, which does not have any dependencies on an OSGi-bundle. In domain-mode, this problem does not arise. Bundles are started first, deployment of EJB-jar comes after. Probably in standalone-mode with manually deployed files instead of using the "deployments" folder, the problem might also not arise (untested). Config: standalone-preview jboss-as-7.1.0.Alpha1 as of 2011-09-12 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBNAME-51) Delay in connecting when first of multiple providers is down can cause performance issue

by Dennis Reed (JIRA)

Delay in connecting when first of multiple providers is down can cause performance issue ---------------------------------------------------------------------------------------- Key: JBNAME-51 URL: https://issues.jboss.org/browse/JBNAME-51 Project: JBoss Naming Issue Type: Bug Components: jnpserver Affects Versions: 5.0.3.GA Reporter: Dennis Reed org.jnp.interfaces.NamingContext.checkRef always loops through the provider list in order, trying to connect to the first before checking for a cached connection to a later provider. This affects performance because it can cause a delay on every context created, waiting for a timeout on a node that is down. For instance, the following takes a very long time when node1 is down. ... env.put ( Context.PROVIDER_URL, "node1:1100,node2:1100" ); for ( int i = 0; i < 1000; ++ i ) { InitialContext ctx = new InitialContext ( env ); ... } If checkRef looked for a cached connection to any of the listed providers before trying to connect to an uncached one, there would only be a timeout delay on the very first connection attempt. Note: This would change the behavior of the client when node1 comes back up in the middle, so would not be eligible for an EAP patch release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
7
0 / 0

[JBoss JIRA] (JBNAME-59) HA-JNDI java.rmi.UnmarshallException doesn't failover

by Dennis Reed (JIRA)

Dennis Reed created JBNAME-59: --------------------------------- Summary: HA-JNDI java.rmi.UnmarshallException doesn't failover Key: JBNAME-59 URL: https://issues.jboss.org/browse/JBNAME-59 Project: JBoss Naming Issue Type: Bug Components: jnpserver Affects Versions: 5.0.3.GA Reporter: Dennis Reed Assignee: Dennis Reed During intensive HA-JNDI failover testing (constantly running "new InitialContext().lookup(...)" while starting and stopping JBoss instances, sometimes an HA-JNDI lookup just before the server goes down is throwing an exception without trying to fail over to the other HA-JNDI instance: ... Caused by: javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.net.SocketException: Connection reset] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:863) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:710) at javax.naming.InitialContext.lookup(InitialContext.java:351) at xxx.CustomCode (CustomCode.java:XXX) ... 25 more Caused by: java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.net.SocketException: Connection reset at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:203) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.ha.framework.server.HARMIServerImpl_Stub.invoke(Unknown Source) at org.jboss.ha.framework.interfaces.HARMIClient.invokeRemote(HARMIClient.java:225) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:327) at $Proxy4.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:750) ... 28 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.DataInputStream.readByte(DataInputStream.java:241) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:189) ... 34 more Also a similar exception: Caused by: java.net.SocketException: socket write error: Connection reset by peer. at jrockit.net.SocketNativeIO.writeBytesPinned(Native Method) at jrockit.net.SocketNativeIO.socketWrite(SocketNativeIO.java:73) at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:137) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1632) at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:667) at sun.rmi.transport.StreamRemoteCall.releaseOutputStream(StreamRemoteCall.java:92) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:188) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at org.jboss.ha.framework.server.HARMIServerImpl_Stub.invoke(Unknown Source) at org.jboss.ha.framework.interfaces.HARMIClient.invokeRemote(HARMIClient.java:225) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:327) at $Proxy4.lookup(Unknown Source) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:750) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:710) at javax.naming.InitialContext.lookup(InitialContext.java:351) ... Also javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.io.EOFException] ... Root cause is that java.rmi.UnmarshallException is not caught as an exception eligible for failover. -- 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

1
6
0 / 0

[JBoss JIRA] (JBNAME-60) Retry HAJNDI call on ServiceUnavailableException

by Dennis Reed (JIRA)

Dennis Reed created JBNAME-60: --------------------------------- Summary: Retry HAJNDI call on ServiceUnavailableException Key: JBNAME-60 URL: https://issues.jboss.org/browse/JBNAME-60 Project: JBoss Naming Issue Type: Bug Components: jnp-client Affects Versions: 5.0.3.GA Reporter: Dennis Reed Assignee: Dennis Reed Retry a context.lookup call when a ServiceUnavailableException is received. This is a new exception added in HAJNDI for JBPAPP-8152/JBPAPP-8305 when the server is not ready to handle requests (starting up/shutting down). -- 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

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-9177) Launch script does not work on Windows

by Max Rydahl Andersen (JIRA)

Launch script does not work on Windows --------------------------------------- Key: JBAS-9177 URL: https://issues.jboss.org/browse/JBAS-9177 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Max Rydahl Andersen Priority: Critical Launching AS 7 does not work on windows. Several issues: Quoting java_home causes error: set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_24" Y:\products\jboss 7.0.0.Beta1\bin>standalone.bat Config file not found Y:\products\jboss 7.0.0.Beta1\bin\standalone.conf.bat Files\Java\jdk1.6.0_24"" was unexpected at this time. Non quoting and you get this: Y:\products\jboss 7.0.0.Beta1\bin>set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_2 4 Y:\products\jboss 7.0.0.Beta1\bin>standalone.bat Config file not found Y:\products\jboss 7.0.0.Beta1\bin\standalone.conf.bat =============================================================================== JBoss Bootstrap Environment JBOSS_HOME: Y:\products\jboss 7.0.0.Beta1 JAVA: C:\Program Files\Java\jdk1.6.0_24\bin\java JAVA_OPTS: -Dprogram.name=standalone.bat -server =============================================================================== Exception in thread "main" java.lang.NoClassDefFoundError: 7/0/0/Beta1\standalon e\log\boot/log Caused by: java.lang.ClassNotFoundException: 7.0.0.Beta1\standalone\log\boot.log at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: 7.0.0.Beta1\standalone\log\boot.log. Program wil l exit. Press any key to continue . . . And it seem to be looking for standalone.conf.bat which does not exist. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

6
13
0 / 0

[JBoss JIRA] (AS7-5009) Cannot invoke remote EJB3 from OSGi Bundle

by Thomas Diesler (JIRA)

13 years, 9 months

1
7
0 / 0

[JBoss JIRA] (JBRULES-3544) nullSafeEqualityComparison in PackageBuilder is not null safe

by Davide Grohmann (JIRA)

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] (JGRP-1457) TimeScheduler2 loses tasks

by David Hotham (JIRA)

David Hotham created JGRP-1457: ---------------------------------- Summary: TimeScheduler2 loses tasks Key: JGRP-1457 URL: https://issues.jboss.org/browse/JGRP-1457 Project: JGroups Issue Type: Bug Affects Versions: 3.0.9 Reporter: David Hotham Assignee: Bela Ban The symptoms I sometime see are: broadcast messages not being delivered to a member. I've tracked this down to being because NAKACK2 has gaps in its record of sequence numbers, and its RetransmitTask is not running. I've confirmed that the task is not running by calling stack.getTransport().dumpTimerTasks() and seeing that it is not among the scheduled tasks. So far, so definite. I also have a theory about how this happens. Suppose thread 1 is in TimeScheduler2._run(), and has got as far as executing some tasks but has not yet reached the line tasks.keySet().removeAll(keys). Meanwhile, suppose thread 2 is in TimeScheduler2.schedule(), adding a task that has the same key as the just-executed task. It can reach the branch task.remove(key) ("// entry has completed; remove it"), go round the loop again, and successfully call tasks.putIfAbsent(key, task). Now thread 1 picks up again, calls removeAll(keys), and removes the task that has just been scheduled. Oops. I suggest that a likely fix is to delete the "else tasks.remove(key)" branch from schedule() altogether. (If we're in that branch then we're blocked by a completed entry. That entry will be removed shortly by the run() thread, and then we'll be able to progress). -- 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

2
3
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 June 2012