[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
[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
[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
[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
[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
[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