December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4926) IncompleteDeploymentException prevents further deployments

by Thomas Diesler (JIRA)

IncompleteDeploymentException prevents further deployments ---------------------------------------------------------- Key: JBAS-4926 URL: http://jira.jboss.com/jira/browse/JBAS-4926 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

4
9
0 / 0

[JBoss JIRA] Created: (JGRP-638) Look at IP multicasting and IPv6

by Bela Ban (JIRA)

Look at IP multicasting and IPv6 -------------------------------- Key: JGRP-638 URL: http://jira.jboss.com/jira/browse/JGRP-638 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.7 Attachments: SimpleMulticast.java [Carlo DeWolf's email] Bug 1: Aha, in IPv6 mode the incorrect interface is chosen to send out packets. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4742177 So to actually get the right sender into the packet you must bind to the address. MultiSocket senderSocket = new MultiSocket(new InetSocketAddress(sendFrom, 0)); Loopback must always be false. I'm not sure why, but if falls apart if you set it to true. (Might be because of the above.) senderSocket.setLoopback(false); The receiving socket must be bound to INADDR_ANY (because of Windows): receiverSocket = new MultiSocket(port); Bug 2: The receiver socket must join with an interface, because else the packets sent from the sendSocket are immediately blocked by the interface (not a member of the group). receiverSocket.joinGroup(mcastaddr, netIf); // Note that port in mcastaddr is ignored. I think it's also possible to have the sendSocket join, but I'm done. The effect here was that as long as nobody joins on the default multicast interface, nobody receives packets. This would seldomly occur, because there is always someone who joins the default interface. I've attached by own multicast tester. Which works in every config except on Windows with the counterfeit, doubtful, dubious, equivocal, fake, false, fictitious, inaccurate, mythical, spurious, unauthenticated, ungenuine, unsubstantiated, untrue, unverified, wrong "MS TCP loopback" device. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-801) Release 2.4.0.Beta1

by Ron Sigal (JIRA)

Release 2.4.0.Beta1 ------------------- Key: JBREM-801 URL: http://jira.jboss.com/jira/browse/JBREM-801 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5076) Loglevel TRACE doesn't work when defined in a SAR file

by Juergen Zimmermann (JIRA)

Loglevel TRACE doesn't work when defined in a SAR file ------------------------------------------------------ Key: JBAS-5076 URL: http://jira.jboss.com/jira/browse/JBAS-5076 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-4.2.2.GA Environment: WinXP SP2, JDK 1.6.0_03, JBossAS 4.2.2, JBossWS 2.0.2 Reporter: Juergen Zimmermann Assigned To: Scott M Stark I've a SAR archive included in an EAR archive. The SAR archive contains log4j.xml (plus log4j.dtd): <?xml version="1.0"?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false"> <category name="de.hska"> <priority value="TRACE"/> </category> </log4j:configuration> However, the TRACE level cannot be utilized in a servlet class. Using DEBUG there is no problem. I also tried to add class="org.jboss.logging.XLevel", but the issue remains. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4313) Cluster looses his master

by Bernd Köcke (JIRA)

Cluster looses his master ------------------------- Key: JBAS-4313 URL: http://jira.jboss.com/jira/browse/JBAS-4313 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.0.CR1, JBossAS-4.0.5.GA, JBossAS-4.0.4.GA, JBossAS-4.0.2 Final Environment: Linux 2.6.x, Sun-JVM 1.5.0_11-b03, 1.6.0-b105, JBoss 4.0.2.final, but the code which causes the problem seems to be present up to version 4.2.0.CR1, cluster with two or more nodes. Reporter: Bernd Köcke Assigned To: Brian Stansberry In a cluster with two nodes (node_a and node_b) under a high workload it is possible that a restarted node, which is not the master, rejoins the cluster before the master recognised that the old node has gone away. The result is, that the restarted node seems to appear in the clusterview twice. The problem is the DistributedReplicantManagerImpl (DRMI) and ClusterPartition. Via the setCurrentState-method of DRMI on node_b the replicants-map is set, this map contains the old dead node node_bo. The key for the new node_b (node_bn) and the old one is the same: node_b:1199. When the master recognised that node_bo is dead he sends a new clusterview without the old node: node_a, node_b(n). But because of the implementation in HAPartitionImpl.getDeadMembers and DRMI.membershipChanged node_bo is never removed from the replicants map of node_bn's DRMI. If after this node_a is restarted, node_bn is the new master. JGroups knows this, but not the DRMI not and because of the old node in the replicants-map he returns 'false' from 'isMasterReplica' for every service. The restarted node_a is not the first in the clusterview and so there is no master. This situation is stable until node_bn is restarted. The cause of the problem is the method ClusterPartition.generateUniqueNodeName. If the JNDI-Subsystem is working, the method generates this nodename: <server name>:<JNDI port>. This is not unique across a node restart. To 'solve' the problem I commented out the return statement for the JNDI-based nodename. Then the method generates a name like this: <server name>:<generated UID>. This is set as additional data in JGroups and in turn used as key in the various maps in DRMI. With this fix node_bo is removed from the replicants map. But the clusterview looks a little bit ugly because of the UID. May be that others want to stay with the JNDI-Port. So my suggestion would be to make it a configuration option, to use always the UID instead of the JNDI-Port and the default can be the JNDI-Port. Because it could be that someone uses the nodenames of the clusterview to determine the JNDI-Port of the other members. But by changing this, I found a deadlock condition in DRMI. I will post another bugreport for this, it seems to affect only version 4.0.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-4292) Legacy MainDeployer.deploy use of checkIncomplete causes leaks/test failures

by Scott M Stark (JIRA)

Legacy MainDeployer.deploy use of checkIncomplete causes leaks/test failures ---------------------------------------------------------------------------- Key: JBAS-4292 URL: http://jira.jboss.com/jira/browse/JBAS-4292 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services, Test Suite Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Scott M Stark Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 If one adds a checkIncomplete call to validate a deployment in the legacy org.jboss.deployment.MainDeployer used by the testsuite deploy calls, there are additional failures and memory leaks that prevent the run from completing. It appears that tests are not cleaning up after failed deployments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

6
12
0 / 0

[JBoss JIRA] Created: (JBAS-4647) Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.CR1

by Dimitris Andreadis (JIRA)

Track jboss and thirdparty dependencies upgrades for JBoss 5.0.0.CR1 -------------------------------------------------------------------- Key: JBAS-4647 URL: http://jira.jboss.com/jira/browse/JBAS-4647 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Other Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.CR1 Create subtasks to track jboss and thirdparty dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-5077) Messaging SeverPeer refactories for better JBossAS integration

by Scott M Stark (JIRA)

Messaging SeverPeer refactories for better JBossAS integration -------------------------------------------------------------- Key: JBAS-5077 URL: http://jira.jboss.com/jira/browse/JBAS-5077 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-5.0.0.Beta3 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.CR1 This task links to the JBMESSAGING-1189 ServerPeer refactorings that we need to have better control of the messaging integration. Subtasks are needed for overriding the security aspects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4706) Deployer to synchronize meta data after the unguaranteed parsing deployers

by Anil Saldhana (JIRA)

Deployer to synchronize meta data after the unguaranteed parsing deployers -------------------------------------------------------------------------- Key: JBAS-4706 URL: http://jira.jboss.com/jira/browse/JBAS-4706 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 As indicated on the forums, the parsing deployers are not guaranteed to run always. So any modifications to the meta data need to be performed in a separate deployer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-557) need to include all the transports within the tests.versioning ant target

by Tom Elrod (JIRA)

need to include all the transports within the tests.versioning ant target ------------------------------------------------------------------------- Key: JBREM-557 URL: http://jira.jboss.com/jira/browse/JBREM-557 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Due to a problem with the test setup, some of the versioning tests (for rmi and socket) do not pass when running the versioning tests. Know these actually work when run manually, so need to investigate why automated tests are failing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 3 months

2
4
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 December 2007