[JBoss JIRA] Created: (JBAS-3780) Deploying empty file to farm directory causes ScannerThread to hang
by Brian Stansberry (JIRA)
Deploying empty file to farm directory causes ScannerThread to hang
-------------------------------------------------------------------
Key: JBAS-3780
URL: http://jira.jboss.com/jira/browse/JBAS-3780
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Environment: Fedora Core 5
JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
As reported by Dan Delany in JBCLUSTER-151:
Creating a 0 byte long file in the farm directory causes the server to stop scanning the farm directory.
To reproduce:
Deploy a fresh instance of JBoss.
Do not deploy any applications to it.
Configure it to be part of a cluster.
Launch JBoss.
After it is running, touch farm/foo.xml
The log will show
07:45:34,555 INFO [JkMain] Jk running ID=0 time=0/33 config=null
07:45:34,562 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 42s:633ms
07:45:48,664 INFO [ClusterFileTransfer] Start push of file foo.xml to cluster.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3798) EJB Interceptors Initialised Before Dependent Services Started
by Darran Lofthouse (JIRA)
EJB Interceptors Initialised Before Dependent Services Started
--------------------------------------------------------------
Key: JBAS-3798
URL: http://jira.jboss.com/jira/browse/JBAS-3798
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, EJB2
Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA
Reporter: Darran Lofthouse
Assigned To: Dimitris Andreadis
Fix For: JBossAS-4.0.6.CR1
The interceptors for an EJB are initialised in the create step of EJB deployment, this means that they can be initialised before the services the EJB depends on have been started.
This can be reproduced by deploying a sar that contains a jar that contains a MDB and then starting JBoss, the CachedConnectionInterceptor is initialised before the CachedConnectionManager is available and the following warning is logged: -
12:27:54,179 WARN [EjbModule] Could not load the org.jboss.resource.connectionmanager.CachedConnectionInterceptor interceptor for this container
javax.management.InstanceNotFoundException: jboss.jca:service=CachedConnectionManager is not registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:550)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.<init>(CachedConnectionInterceptor.java:78)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at org.jboss.ejb.EjbModule.addInterceptors(EjbModule.java:930)
at org.jboss.ejb.EjbModule.initializeContainer(EjbModule.java:816)
at org.jboss.ejb.EjbModule.createMessageDrivenContainer(EjbModule.java:602)
at org.jboss.ejb.EjbModule.createContainer(EjbModule.java:569)
at org.jboss.ejb.EjbModule.createService(EjbModule.java:342)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-4283) JBoss application server appears to be matching on *ra.xml inside the .rar file when deploying
by Marie Rizzo (JIRA)
JBoss application server appears to be matching on *ra.xml inside the .rar file when deploying
----------------------------------------------------------------------------------------------
Key: JBAS-4283
URL: http://jira.jboss.com/jira/browse/JBAS-4283
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services
Affects Versions: JBossAS-4.0.5.GA
Environment: Windows XP, JDK 5, Mule 1.3.3/ 1.4 SNAPSHOT
Reporter: Marie Rizzo
Assigned To: Dimitris Andreadis
In attempting to deploy Mule on JBoss using the rar deployment, I noticed that although a proper ra-xml file exists for JBoss deployment inside the rar file, JBoss rejects anything that contains any other file which matches the pattern but does not pertain to JBoss deployment. In my case this occurs in the resource adapter jar file which has a file called oc4j-ra.xml file inside it. It seems to me that JBoss is matching on *ra.xml which may be the cause of the problem. Below is the relevant extract from the log file.
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.JARDeployer] Found entry: 'META-INF/oc4j-ra.xml', matching: 'ra.xml', rejecting jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] No deployer found for url: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
2007-03-30 16:16:48,734 DEBUG [org.jboss.deployment.MainDeployer] deployment waiting for deployer: file:/C:/Downloads/jboss-4.0.5.GAR/server/default/tmp/deploy/tmp37913mule-jca-1.4-SNAPSHOT.rar-contents/mule-module-jca-1.4-SNAPSHOT.jar
Consequently, a ClassLoaderNotFound exception is thrown because the resource adapter was never deployed.
11:57:17,203 WARN [ServiceController] Problem starting service jboss.jca:service=RARDeployment,name='mule-jca-1.3.3.rar'
java.lang.ClassNotFoundException: No ClassLoaders found for: org.mule.ra.MuleResourceAdapter
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.resource.deployment.ResourceAdapterFactory.createResourceAdapter(ResourceAdapterFactory.java:66)
at org.jboss.resource.deployment.RARDeployment.startService(RARDeployment.java:108)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
Please could you check up on this? If JBoss is indeed matching on the *ra.xml, it would be very restrictive with regards to naming conventions.
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBXB-99) marshalDate appends timezone
by Thomas Diesler (JIRA)
marshalDate appends timezone
----------------------------
Key: JBXB-99
URL: http://jira.jboss.com/jira/browse/JBXB-99
Project: JBoss XML Binding (JBossXB)
Issue Type: Bug
Affects Versions: JBossXB-1.0.0.CR9
Reporter: Thomas Diesler
/**
* [-]yyyy-mm-dd
*
* @param value string date value
* @return equivalent date as an instance of java.util.Calendar.
*/
public static String marshalDate(Calendar value)
{
String result = String.valueOf(value.get(Calendar.YEAR));
result += '-';
result += marshalInt(value.get(Calendar.MONTH) + 1, 2);
result += '-';
result += marshalInt(value.get(Calendar.DAY_OF_MONTH), 2);
result += marshalTimeZone(value);
return result;
}
Given these CTS calendars
public final static GregorianCalendar GregorianCalendar_data[] = {
new GregorianCalendar(6,5,1,10,0,0),
new GregorianCalendar(9,10,25,1,30,0),
new GregorianCalendar(96,5,1,2,0,30),
new GregorianCalendar(99,10,25,3,15,15),
new GregorianCalendar(996,5,1,6,6,6),
new GregorianCalendar(999,10,25,7,7,7),
new GregorianCalendar(1996,5,1,8,8,8),
new GregorianCalendar(1999,10,25,9,9,9),
null
};
jbossxb generates a string that cannot be parsed on the server side
12:12:36,027 ERROR [SOAPFaultHelperJAXRPC] SOAP request exception
org.jboss.xb.binding.JBossXBValueFormatException: Date value does not follow the format '-'? yyyy '-' mm '-' dd: 6-06-01-05:00
at org.jboss.xb.binding.SimpleTypeBindings.parseDate(SimpleTypeBindings.java:2088)
at org.jboss.xb.binding.SimpleTypeBindings.unmarshalDate(SimpleTypeBindings.java:1701)
at org.jboss.ws.core.jaxrpc.binding.CalendarDeserializer.deserialize(CalendarDeserializer.java:61)
at org.jboss.ws.core.jaxrpc.binding.CalendarDeserializer.deserialize(CalendarDeserializer.java:47)
at org.jboss.ws.core.soap.XMLContent.unmarshallObjectContents(XMLContent.java:175)
--
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
19 years, 3 months
[JBoss JIRA] Created: (JBAS-3757) Support for PostgreSQL 8.2beta1
by Juergen Zimmermann (JIRA)
Support for PostgreSQL 8.2beta1
-------------------------------
Key: JBAS-3757
URL: http://jira.jboss.com/jira/browse/JBAS-3757
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: PostgreSQL 8.2beta1, JDK 5.0_09, JDBC driver 8.2dev-503.jdbc3, JBoss 4.0.5cr1
Reporter: Juergen Zimmermann
Fix For: JBossAS-4.0.5.GA
Starting JBoss with PostgreSQL 8.2beta1 fails (no problem with 8.1.4).
Here is the log message:
09:11:48,067 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
09:11:48,778 WARN [ServiceController] Problem starting service jboss.mq:service=PersistenceManager
org.jboss.mq.SpyJMSException: Could not resolve uncommited transactions. Message recovery may not be accurate; - nested throwable: (org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:489)
at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1807)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy39.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.postgresql.util.PSQLException: Eingabe/Ausgabe-Fehler {0} beim Senden an das Backend.
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:216)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:308)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java:441)
... 111 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 org.postgresql.core.PGStream.ReceiveChar(PGStream.java:256)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1164)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:190)
... 116 more
--
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
19 years, 3 months
[JBoss JIRA] Created: (JGRP-341) Extend FLUSH to fully support virtual synchrony
by Bela Ban (JIRA)
Extend FLUSH to fully support virtual synchrony
-----------------------------------------------
Key: JGRP-341
URL: http://jira.jboss.com/jira/browse/JGRP-341
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Vladimir Blagojevic
Fix For: 2.5
Currently, FLUSH makes sure that all members 'flush' their pending messages and then stop sending new ones until the join or state transfer is over. However, FLUSH does *not* (unlike the old version) make sure that - on JOIN - all members have seen the same set of messages before installing a new view. Example: P sends M, but immediately after sending M crashes. If another member Q received M, but R didn't see M, then - with the current FLUSH - R will *not* see M.
We need to run a messages exchange phase, as part of FLUSH, which makes sure that all member have seen the same set of messages in the same view, before installing a new view. Whether to run this or not could be made configurable. If enabled, we could piggyback the message exchange on START_FLUSH/FLUSH_OK etc.
A simple (but costly) solution would be to simply multicast all messages received from other members before multicasting the FLUSH_OK. A better solution would be to exchange digests with highest sequence numbers seen for all members, and then only multicast the missing messages. This *might* require an additional phase though.
--
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
19 years, 3 months
[JBoss JIRA] Commented: (JBCACHE-97) ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
by Bela Ban (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-97?page=comments#action_12358167 ]
Bela Ban commented on JBCACHE-97:
---------------------------------
See my question and the suggested answer at http://www.nabble.com/Upgrading-a-RL-to-WL-in-ReentrantReadWriteLock-tf27...
> ReadWriteLockWithUpgrade: UpgradeException with more than 1 reader/writer waiting to upgrade lock
> -------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-97
> URL: http://jira.jboss.com/jira/browse/JBCACHE-97
> Project: JBoss Cache
> Issue Type: Bug
> Reporter: Bela Ban
> Assigned To: Jason T. Greene
> Fix For: 2.1.0.GA
>
>
> TxDeadlockUnitTestCase has 2 methods that show the following stack traces:
> testMoreThanOneUpgrader:
> Upgrader#0: get(/a/b/c)
> Upgrader#1: get(/a/b/c)
> main: locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> Upgrader#0: put(/a/b/c)
> Upgrader#1: put(/a/b/c)
> Upgrader#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:2); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> Upgrader#0: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:2]
> Write lock owner: null
> (caller=<null>:1)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyUpgrader._run(TxDeadlockUnitTestCase.java:346)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> and
> testConcurrentUpgrade():
> MyThread#1: get(/a/b/c)
> MyThread#2: get(/a/b/c)
> MyThread#2: done, locks:
> /a (read owners=[<null>:2])
> /b (read owners=[<null>:2])
> /c (read owners=[<null>:2])
> MyThread#1: done, locks:
> /a (read owners=[<null>:2, <null>:1])
> /b (read owners=[<null>:2, <null>:1])
> /c (read owners=[<null>:2, <null>:1])
> MyThread#2: put(/a/b/c)
> MyThread#1: put(/a/b/c)
> MyThread#1: org.jboss.cache.lock.LockingException: acquireWriteLock(): lock upgrade failed for /a/b/c (caller=<null>:1); - nested throwable: (org.jboss.cache.lock.UpgradeException: upgradeLockAttempt(): more than one reader trying to simultaneously upgrade to write lock)
> MyThread#2: org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> org.jboss.cache.lock.TimeoutException: upgrade lock for /a/b/c could not be acquired after 3000 ms. Lock map ownership Read lock owners: [<null>:1]
> Write lock owner: null
> (caller=<null>:2)
> at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:155)
> at org.jboss.cache.Node.acquireWriteLock(Node.java:448)
> at org.jboss.cache.Node.acquire(Node.java:417)
> at org.jboss.cache.interceptors.LockInterceptor.lock(LockInterceptor.java:199)
> at org.jboss.cache.interceptors.LockInterceptor.invoke(LockInterceptor.java:144)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.CreateIfNotExistsInterceptor.invoke(CreateIfNotExistsInterceptor.java:145)
> at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:40)
> at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:35)
> at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:2998)
> at org.jboss.cache.TreeCache.put(TreeCache.java:1657)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$MyThread._run(TxDeadlockUnitTestCase.java:317)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
> at org.jboss.test.cache.test.local.TxDeadlockUnitTestCase$GenericThread.run(TxDeadlockUnitTestCase.java:213)
--
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
19 years, 3 months