[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
[JBoss JIRA] Created: (JBAS-5171) TxConnectionManager is track-connection-by-tx false by default
by Adrian Brock (JIRA)
TxConnectionManager is track-connection-by-tx false by default
--------------------------------------------------------------
Key: JBAS-5171
URL: http://jira.jboss.com/jira/browse/JBAS-5171
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-5.0.0.Beta3
Reporter: Adrian Brock
Assigned To: Alexey Loubyansky
Fix For: JBossAS-5.0.0.Beta4
The TxConnectionManager is always configured to be track-connection-by-tx by default.
The old xslt used to do some complicated logic to try to determine the value
XA with track-connection-by-tx
<xsl:choose>
<xsl:when test="(xa-transaction) and (track-connection-by-tx)">
<attribute name="TrackConnectionByTx">true</attribute>
<attribute name="LocalTransactions">false</attribute>
</xsl:when>
XA with interleaving
<xsl:when test="(xa-transaction)">
<attribute name="TrackConnectionByTx">false</attribute>
<attribute name="LocalTransactions">false</attribute>
</xsl:when>
Non XA MUST BE track-connection-by-tx
<xsl:otherwise>
<attribute name="TrackConnectionByTx">true</attribute>
<attribute name="LocalTransactions">true</attribute>
</xsl:otherwise>
</xsl:choose>
The last part is not being done by the new connection factory deployer/metadata.
In fact, to simplify it (and answer some FAQs), I suggested that <track-connection-by-tx/> should be "dropped" and set to true all the time (with a warning about deprecation when somebody tries to use it).
Instead users of XA should explicity enable <interleaving/>
--
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
[JBoss JIRA] Updated: (JBAS-1436) Improved management
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-1436?page=all ]
Dimitris Andreadis updated JBAS-1436:
-------------------------------------
Fix Version/s: JBossAS-4.2.3.GA
JBossAS-5.1.0.CR1
Assignee: Vicky Kak (was: Weston Price)
Assign to Vicky to look at, if he has cycles, Weston is not working on this anymore.
Maybe first try to add this feature in Branch_4_2 and later to trunk for a future 5.1 release.
> 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: Vicky Kak
> Priority: Minor
> Fix For: JBossAS-4.2.3.GA, JBossAS-5.1.0.CR1
>
>
> 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, 3 months
[JBoss JIRA] Created: (JBAS-5191) Manage JBoss Web runtime lifecycle via a JMX service in deploy
by Brian Stansberry (JIRA)
Manage JBoss Web runtime lifecycle via a JMX service in deploy
--------------------------------------------------------------
Key: JBAS-5191
URL: http://jira.jboss.com/jira/browse/JBAS-5191
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta4
Temporary workaround to support controlling the lifecycle of the webserver runtime portion of TomcatDeployer via a JMX service in the deploy directory.
We want it in deploy so dependencies on services in deploy can be properly expressed. We want it as a JMX service so the ServiceBindingManager can
alter the connector ports.
Solution involves:
* Creating a wrapper mbean for the TomcatDeployer and deploying it via a deploy/jbossweb.sar/jboss-service.xml
* Encapsulating the code in TomcatDeployer that starts and stops the JBossWeb runtime in public start/stopWebserver methods.
* Disable calling those methods from TomcatDeployer.start/stop. Thus starting/stopping the deployer does not effect the runtime.
* Invoke the TomcatDeployer start/stopWebserver methods from the new wrapper mbean's startService/stopService.
A more long term solution involves:
* separating out the JBossWeb runtime aspects from TomcatDeployer and putting them in a separate class
* developing a ProfileService-based alternative to ServiceBindingManager so this doesn't need to be a JMX service
--
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
[JBoss JIRA] Updated: (JBAS-73) Singleton and/or deployer is too brittle
by Brian Stansberry (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-73?page=all ]
Brian Stansberry updated JBAS-73:
---------------------------------
Fix Version/s: JBossAS-5.0.0.CR1
(was: JBossAS-5.0.0.Beta4)
Remaining issue is captured in subtask; for 5.0.0.CR1.
> Singleton and/or deployer is too brittle
> ----------------------------------------
>
> Key: JBAS-73
> URL: http://jira.jboss.com/jira/browse/JBAS-73
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-3.2.6 Final
> Reporter: Adrian Brock
> Assigned To: Brian Stansberry
> Fix For: JBossAS-5.0.0.CR1
>
>
> Trying to bootstrap two JBoss servers, but the cluster join failed
> because the message took too long (long garbage collection/paging on my computer?)
> Server 2:
> GMS: address is htimes2:32925 (additional data: 14 bytes)
> -------------------------------------------------------
> 2004-12-21 15:14:30,909 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Starting channel
> 2004-12-21 15:14:30,910 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] get nodeName
> 2004-12-21 15:14:30,990 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Get current members
> 2004-12-21 15:14:30,991 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Number of cluster members: 1
> 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Other members: 0
> 2004-12-21 15:14:30,992 INFO [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Fetching state (will wait for 60000 milliseconds):
> 2004-12-21 15:14:30,999 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 0, delta:
> 0) : [127.0.0.1:1199]
> 2004-12-21 15:14:31,008 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 1
> 2004-12-21 15:14:31,009 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] Begin notifyListeners, viewID: 0
> 2004-12-21 15:14:31,009 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] I am (null) received membershipChanged event:
> 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] Dead members: 0 ([])
> 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] New Members : 0 ([])
> 2004-12-21 15:14:31,010 INFO [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.DefaultPartition] All Members : 1 ([127.0.0.1:1199])
> 2004-12-21 15:14:31,011 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] End notifyListeners, viewID: 0
> 2004-12-21 15:14:31,058 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] State could not be retrieved, (must be first member of group)
> 2004-12-21 15:14:31,137 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] setState called
> 2004-12-21 15:14:31,138 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] state is null
> 2004-12-21 15:14:31,139 DEBUG [org.jboss.ha.framework.server.ClusterPartition] Started ClusterPartition: DefaultPartition
> The message was rejected by the other server (too late?) but the cluster
> eventually joined together
> Server 1:
> 15:13:05,825 INFO [Server] JBoss (MX MicroKernel) [3.2.7RC2 (build: CVSTag=Branch_3_2 date=200411160220)] Started in 4m:43s:249ms
> 15:15:39,184 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes)
> 15:15:41,080 WARN [NAKACK] [htimes2:32920 (additional data: 14 bytes)] discarded message from non-member htimes2:32925 (additional data: 14 bytes)
> 15:15:55,106 INFO [DefaultPartition] New cluster view for partition DefaultPartition (id: 1, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1199]
> 15:15:55,107 INFO [DefaultPartition] Merging partitions...
> 15:15:55,107 INFO [DefaultPartition] Dead members: 0
> This meant that server2 tried to bootstrap the deploy-hasingleton
> but part way through doing that (when it eventually joined the cluster)
> it was told to undeploy it.
> Since the original deploy hadn't finished, this caused havoc
> in particular trying to use a classloader that no longer existed:
> 2004-12-21 15:16:28,614 ERROR [org.jboss.mq.sm.jdbc.JDBCStateManager] Starting failed JDBCStateManager
> org.jboss.mq.SpyJMSException: Error creating connection to the database.; - nested throwable: (java.lang.NullPointerException)
> at org.jboss.mq.sm.jdbc.JDBCStateManager$JDBCSession.<init>(JDBCStateManager.java:542)
> at org.jboss.mq.sm.jdbc.JDBCStateManager.initDB(JDBCStateManager.java:432)
> at org.jboss.mq.sm.jdbc.JDBCStateManager.startService(JDBCStateManager.java:399)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
> at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
> at $Proxy18.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:414)
> at org.jboss.system.ServiceController.start(ServiceController.java:436)
> at org.jboss.system.ServiceController.start(ServiceController.java:436)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:304)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:478)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:201)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:414)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:588)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:198)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:407)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:311)
> at org.jboss.Main.boot(Main.java:147)
> at org.jboss.Main$1.run(Main.java:422)
> at java.lang.Thread.run(Thread.java:534)
> Caused by: java.lang.NullPointerException
> at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:143)
> at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:186)
> at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:136)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:219)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:637)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
> at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:480)
> at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:420)
> at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:237)
> at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:665)
> at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:496)
> at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:888)
> at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102)
> at org.jboss.mq.sm.jdbc.JDBCStateManager$JDBCSession.<init>(JDBCStateManager.java:518)
> ... 95 more
> I would guess a similar race condition exists on all the HASingleton processing
> and with all attempts to multi-threadedly deploy/undeploy the same url?
--
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