[JBoss JIRA] Updated: (JBAS-3355) DetachedHANamingService does not register its ObjectName with Registry
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3355?page=all ]
Brian Stansberry updated JBAS-3355:
-----------------------------------
Fix Version/s: JBossAS-5.0.1.CR1
(was: JBossAS-5.0.0.Beta4)
Assignee: Brian Stansberry (was: Jerry Gauthier)
> DetachedHANamingService does not register its ObjectName with Registry
> ----------------------------------------------------------------------
>
> Key: JBAS-3355
> URL: http://jira.jboss.com/jira/browse/JBAS-3355
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Naming
> Affects Versions: JBossAS-4.0.4.GA
> Reporter: Brian Stansberry
> Assigned To: Brian Stansberry
> Priority: Minor
> Fix For: JBossAS-5.0.1.CR1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> DetachedHANamingService does not register its ObjectName with Registry. Because of this, if it is used with ProxyFactoryHA and JRMPInvokerHA, calls to it will fail in JRMPInvokerHA.invoke due to a failure lookup the ObjectName in the registry.
> The purpose of having DetachedHANamingService as a distinct base class from HANamingService is to allow use with the detached invokers, so not having this work kind of defeats the point.
--
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, 5 months
[JBoss JIRA] Updated: (JBAS-772) HA-JNDI multicast reply not reaching client
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-772?page=all ]
Brian Stansberry updated JBAS-772:
----------------------------------
Fix Version/s: JBossAS-5.0.0.CR1
(was: JBossAS-5.0.0.Beta4)
Assignee: Brian Stansberry (was: Jerry Gauthier)
> HA-JNDI multicast reply not reaching client
> -------------------------------------------
>
> Key: JBAS-772
> URL: http://jira.jboss.com/jira/browse/JBAS-772
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assigned To: Brian Stansberry
> Fix For: JBossAS-5.0.0.CR1
>
> Attachments: DeviceManager.jsp, DeviceModule.java, TelematicsJNDI.java
>
>
> SourceForge Submitter: rmontag .
> I just made some expiriences with the HA-JNDI multicast
> and running multiple instances on a single machine. I
> encountered some problems...
> My setup:
> - JBoss 3.2.2
> - JDK 1.4.2
> - Two instances running on a single W2K-PC,
> alternatively I 'm using two instances running on a
> single SUN solaris. instance 1 using 1200 as HA-JNDI
> port, instance 2 using 1300.
> - "JBoss Clustering" documentation, 4. edition
> - Standalone testclient (JUnit) on PC or SUN,
> configured for Multicast (url-property not set)
> The problem:
> Case A: Testclient and server instances on PC
> Case B: Testclient on PC, server instances on SUN
> When starting my testclient and making a lookup via
> multicast, both instances receive the GET_ADDRESS
> datagram. Then each server send a datagram packet back
> NOT using a multcast. Since the testclient opens a
> MulticastSocket on the Multigroup port 1102, each
> server sends a response datagramm back to <client-ip>:1102.
> I encountered two problems with this approach:
> 1) If client and server are one the same instance like
> in case A, they have the same ip-address. In my
> environment one server instance always "catches" all
> the answers, so the client timed-out with no answers
> (Note: On W2K, I set "loopback" to true, on SUN to
> false as described in the cluster document).
> 2) Same problem if two clients on one instance make a
> concurrent multicast call (servers on other machine):
> Both waiting for responses, only one client catches all
> the responses. The second client ever lose.
> Two possible solutions come to my mind:
> 1) Currently the NamingContext opens a MulticastSocket
> on the multicast group port. If the client would use a
> different dedicated port, he can send his call with the
> multicast group address and the server could reply to
> <client-ip>:<dedicated client-port> with his answer. No
> one else (another client or server) would "catch" the
> server response if using different port numbers
> (Disadvantage: One additional HA-JNDI JNP property like
> "jnp.multicastPort").
> 2) HANamingService currently sends a response datagram
> back to a dedicated IP:port address (Unicast). Why
> doesn't the server also sends a multicast call using
> the well-known multicast group address to propagate his
> answer ? A multicast answer seems to be a clean
> solution because: a) All clients waiting for an answer
> will receive them and b) other server(s) receiving the
> answer will ignore them as they already do now.
> Solution 2 simply means exchanging one line in
> HANamingService.java:
> Instead of
> DatagramPacket p = new DatagramPacket (ipAddress,
> ipAddress.length, packet.getAddress(), packet.getPort());
> do this one:
> DatagramPacket p = new DatagramPacket(ipAddress,
> ipAddress.length, group, adGroupPort);
> Solution 1, as stated above would need one additinal
> config property for the client port.
--
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, 5 months
[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, 5 months
[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
18 years, 5 months
[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
18 years, 5 months
[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, 5 months
[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
18 years, 5 months
[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
18 years, 5 months
[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
18 years, 5 months