February 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (JBAS-1476) Need to include a notion of cluster instance in the cluster view

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1476?page=all ] Brian Stansberry resolved JBAS-1476. ------------------------------------ Fix Version/s: (was: JBossAS-5.0.0.Beta4) Resolution: Out of Date Resolving this old issue in favor of JBAS-5197. That issue reflects the approach we decided upon on the forum. > Need to include a notion of cluster instance in the cluster view > ---------------------------------------------------------------- > > Key: JBAS-1476 > URL: http://jira.jboss.com/jira/browse/JBAS-1476 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1 > Reporter: Adrian Brock > Assigned To: Brian Stansberry > > We need to include a notion of cluster instance in the cluster view id > to avoid at least the following scenario: > Client serializes a handle to a cluster which is at cluster view 22 > Handle contains key DefaultPartition/HAJNDI/22 > The cluster is totally restarted meaning the view reverts back to one. > The client now has a view id > DefaultPartition/HAJNDI/1 > The client deserializes the handle, which will overwrite the correct cluster > view with the old invalid view. > ---- > This will also avoid the problem where a client talks to different clusters > with the same partition name. > ---- > Proposed solution: > 1) At cluster formation (first node in cluster), create a cluster instance GUID > 2) At cluster join (second+ node in cluster) get the GUID from the coordinator > 3) Include this GUID in cluster view keys, i.e. > GUID/DefaultPartition/HAJNDI/1 -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-1436) Improved management

by Galder Zamarreno (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1436?page=comments#action_12397849 ] Galder Zamarreno commented on JBAS-1436: ---------------------------------------- One of our customers has expressed the interest in this JIRA issue being implemented for the AS/EAP 4.x. The customer has also expressed the desire for the maximum waiting time for a connection in a pool to be provided. Current implementation in trunk does show that average waiting time is calculated. > Improved management > ------------------- > > Key: JBAS-1436 > URL: http://jira.jboss.com/jira/browse/JBAS-1436 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JCA service > Reporter: Adrian Brock > Assigned To: Weston Price > Priority: Minor > > Forum Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48682 > **This is a holder issue. Each section should be raised as a new issue as it is > developed with a link from this issue.** > There are a number of areas in JCA that need better management capabilities. > Some of these stats may also reveal the need for new configuration/tuning parameters. > In core JCA: > 1) Better visibility on the ManagedConnectionFactory. > This is currently a DynamicMBean that provides basic config parameters, but we could also > provide a proxy/wrapper to provide statistics of operations on the factory and its > ManagedConnections. > a) createManagedConnections > b) matchManagedConnections > c) events on from the listeners > 2) Better visibility of the Pool(s) > Only top level statistics are provided (you cannot see the subpools). > The statistics are also not synchronized with the pool (for performance reasons > and also the fact that each stat is retrieved on individual MBean getAttribute requests) > Additional statistics could include wait times when requests are waiting on an empty pool, > idle time of unused connections, etc. > 3) Better visibility of the ConnectionManager > Currently this has no visibility for management. > Its main responsibilties are transactions enlistment and security. > e.g. This could show how long is wasted because <track-connection-by-tx/> does not > return the connection the pool until transaction completion. > 4) JDBC resource adapter > PreparedStatementCache stats > Query time stats > etc. > 5) JMS resource adapter > Message send/receive stats > 6) Inbound messaging > Stats for message delivery > 7) Transaction inflow > Stats for transaction inflow and also display a list of current inbound transactions > 8) Work management > Stats for the work management pools and timers -- 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

16 years, 11 months

1
0
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

16 years, 11 months

3
4
0 / 0

[JBoss JIRA] Commented: (JBAS-2251) Fix JBoss Cache / AS integration issues

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2251?page=comments#action_12397817 ] Brian Stansberry commented on JBAS-2251: ---------------------------------------- Here is the current comparison of common dependencies between JBC/PojoCache 2.1.0.CR3 vs. AS trunk: jgroups.jar: 2.6.1 vs. 2.6.1 jboss-aop 2.0.0.CR3: 2.0.0.CR3 vs. 2.0.0.CR3 jboss-javaee: 5.0.0.Beta3 vs. 5.0.0.Beta3Update1 jboss-common-core: 2.2.1.GA vs. 2.2.3.GA commons-logging: 1.0.4.GA vs. 1.1.0.jboss JBC no longer depends on anything produced by AS trunk. The first two dependencies are the critical ones and are aligned. The latter 3 are minor, but you can see there is drift. If that drift was causing a problem, we'd see it in the AS testsuite, so it's OK. Remaining work I still want to do on this next week is to add a "JBossAS" profile to the JBC/PojoCache pom.xml files where I specify the AS dependencies rather than the standard JBC ones. We can then execute the JBC testsuite with that profile to look for issues. Doing that is more to set up a system to ensure that things don't break down the road; I don't have any concern at all about the current alignment. I want to keep this JIRA open until that is done. By I don't see any reason why the current state of this should be considered as not meeting criteria for a 5.0.0.BETA4 release. > Fix JBoss Cache / AS integration issues > --------------------------------------- > > Key: JBAS-2251 > URL: http://jira.jboss.com/jira/browse/JBAS-2251 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: JBoss Cache > Reporter: Adrian Brock > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-5.0.0.Beta4 > > > The JBossCache standalone build includes: > jboss-aop.jar (ok - should be standalone project) > jboss-common.jar (ok - should be standalone project(s)) > jboss-j2ee.jar (TransactionManager interfaces) > jboss-jmx.jar (only for JBossNotificationBroadcasterSupport leaking from jboss-system.jar?) > jboss-minimal.jar (for MarshalledValue, etc.) > jboss-system.jar (for ServiceMBeanSupport) > We are heading for a fall on this (not to mention the other thirdparty jars that could get out-of-sync) > Some of this will probably have to wait until we have the proper federated build. -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2793) Quick overview wrt. to used modules + version

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2793?page=all ] Dimitris Andreadis updated JBAS-2793: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta4) > Quick overview wrt. to used modules + version > --------------------------------------------- > > Key: JBAS-2793 > URL: http://jira.jboss.com/jira/browse/JBAS-2793 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build System > Environment: JBoss 4.x, OS: *x > Reporter: Jens Elkner > Assigned To: Dimitris Andreadis > Priority: Optional > Fix For: JBossAS-5.0.0.CR1 > > Attachments: components2html.xsl, createComponentList.sh > > > Sometimes one needs to know, which thirdparty modules are used by jboss and especially which version. So a simple html formatted overview would be handy. > Since the info is already there, I made a simple script + stylesheet to create such an html file, which might packaged with the docs ... > Feel free to use/modify it as you want ;-) -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2073) Remove xalan.jar from ./lib/endorsed

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2073?page=all ] Dimitris Andreadis updated JBAS-2073: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta4) > Remove xalan.jar from ./lib/endorsed > ------------------------------------ > > Key: JBAS-2073 > URL: http://jira.jboss.com/jira/browse/JBAS-2073 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Other > Affects Versions: JBossAS-4.0.3RC1 > Reporter: Dimitris Andreadis > Assigned To: Dimitris Andreadis > Fix For: JBossAS-5.0.0.CR1 > > > In 4.0.x/HEAD we have: > lib/endorsed/xalan.jar > While in 3.2.x we have: > server/default/lib/xalan.jar > server/all/lib/xalan.jar > The 3.2.x approach seems more correct, since xalan.jar contains org.apache.* stuff, not any of the following "endosed" packages: > org.w3c.dom > org.xml.sax > org.xml.sax.ext > org.xml.sax.helpers > It should be moved out from the bootstrap libs to the default/all lib dirs. -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5186) Incorrect service name in org.jboss.tutorial.webservice.client.Client

by Scott Dickerson (JIRA)

Incorrect service name in org.jboss.tutorial.webservice.client.Client --------------------------------------------------------------------- Key: JBAS-5186 URL: http://jira.jboss.com/jira/browse/JBAS-5186 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-5.0.0.Beta3 Environment: windows xp; jbossas-5.0.0.Beta3-src Reporter: Scott Dickerson Assigned To: Carlo de Wolf Priority: Minor Fix For: JBossAS-5.0.0.Beta4 Change QName qname = new QName("http://bean.webservice.tutorial.jboss.org/jaws", "CalculatorService"); to QName qname = new QName("http://bean.webservice.tutorial.jboss.org/", "CalculatorBeanService"); -- 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

16 years, 11 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBAS-2577) isolating Hibernate as an internal impl detail

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2577?page=all ] Dimitris Andreadis updated JBAS-2577: ------------------------------------- Fix Version/s: JBossAS-5.0.0.CR1 (was: JBossAS-5.0.0.Beta4) Move to CR1. > isolating Hibernate as an internal impl detail > ---------------------------------------------- > > Key: JBAS-2577 > URL: http://jira.jboss.com/jira/browse/JBAS-2577 > Project: JBoss Application Server > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Steve Ebersole > Assigned To: Steve Ebersole > Fix For: JBossAS-5.0.0.CR1 > > > Currently Hibernate is used within JBossAS for EJB3 as well as the Hibernate-intg code, with plans/discussions to expand usage to JBoss Messaging and JBossMQ. This represents Hibernate usage as an internal implementation detail > Additionally, Hibernate is also used within JBossAS by user applications. This represents Hibernate usage as a deployment detail. > Currently, the two are not isolated from each other. Thus, a user attempting to bundle Hibernate with their application is actually using the Hibernate bundled with EJB3 and/or the integration code. This can cause problems when we have internal usage and external usage needing to rely on different releases of Hibernate. > Need to devise a scheme to isolate the internal usages of Hibernate. Two potential solutions: > 1) source-level import and package renaming of Hibernate code (i.e. org.jboss.hibernate) > 2) some form of classloader isolation -- 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

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2505) Hibernate integration in JBoss5

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2505?page=all ] Dimitris Andreadis resolved JBAS-2505. -------------------------------------- Resolution: Done Close the parent issue. > Hibernate integration in JBoss5 > ------------------------------- > > Key: JBAS-2505 > URL: http://jira.jboss.com/jira/browse/JBAS-2505 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott M Stark > Assigned To: Steve Ebersole > Fix For: JBossAS-5.0.0.Beta4 > > > A containing task for Hiberate integration issues for the JBoss5 release -- 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

16 years, 11 months

1
0
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

16 years, 11 months

6
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2008