[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, 4 months
[JBoss JIRA] Created: (JBCACHE-876) Region marker in region-based marshalling message should be region fqn
by Brian Stansberry (JIRA)
Region marker in region-based marshalling message should be region fqn
----------------------------------------------------------------------
Key: JBCACHE-876
URL: http://jira.jboss.com/jira/browse/JBCACHE-876
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 1.4.1.GA
When region based marshalling is used, the replication message first has a serialized Fqn to identify the region, followed by a separately serialized method call. Receiver deserializes the identifier fqn and uses it to find the classloader to use to deserialize the main message.
Problem is the region identifier Fqn is the full Fqn of a node. This prevents the use in Fqns of classes that require the custom classloader to deserialize.
This can be mitigated by changing the marker Fqn to simply identify the Region, not some subnode. Now the restriction on use of custom classes is limited to the region Fqn; portions of Fqns below the region level can be of any serializable class.
This is needed to solve JBCLUSTER-150.
Downside is the node marshalling the message now needs to do a Region lookup to get the region Fqn.
Upsides are a reduced message size, since the shorter region fqn is marshalled, as well as a possibly faster region lookup time on the recipient nodes, since extraneous data can be ignored.
--
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, 4 months
[JBoss JIRA] Created: (JBCACHE-893) Create a pluggable PojoCache Collection class implementation
by Ben Wang (JIRA)
Create a pluggable PojoCache Collection class implementation
------------------------------------------------------------
Key: JBCACHE-893
URL: http://jira.jboss.com/jira/browse/JBCACHE-893
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: PojoCache
Currently PojoCache only supports a single flavor of Collection classes, e.g., HashMap, HashSet, and ArrayList. To fully support different flavor of Collection implementation, we can either:
1. Enable array interception from Jboss Aop such that we can instrument all Collection implementation classes (including java.util.*). But JBoss Aop currently doesn't support it yet, and issues of instrumenting the Sun system classes also is problematic.
2. Create a pluggable architecture for different flavor of Collection implementation.
I think Option #2 is more realistic now. What I propose is this:
1. Will need to implement a specific flavor of collection interceptor and cache impl. E.g., in the case of List, it will be CachedListInterceptor and CachedListImpl.
2. Register the specific impl and the corresponding Collection class name to a registry
During runtime, when we encounter Collection classes, we will check the registry first to see which interceptor (and the corresponding cache impl) that we will use for this case.
Performance impact should be minimal since this is needed only for attach phase.
--
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, 4 months
[JBoss JIRA] Created: (JBCACHE-750) PojoCache to deal with POJO without no-arg constructor
by Ben Wang (JIRA)
PojoCache to deal with POJO without no-arg constructor
------------------------------------------------------
Key: JBCACHE-750
URL: http://jira.jboss.com/jira/browse/JBCACHE-750
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: PojoCache
This came up from a forum post that uses SynchronizedCollection. Here is the problem that Professor Chiba pointed out:
------
Ben,
SynchronizedRandomAccessList class has only the following constructors:
static class SynchronizedRandomAccessList<E>
extends SynchronizedList<E>
implements RandomAccess {
SynchronizedRandomAccessList(List<E> list) {
super(list);
}
SynchronizedRandomAccessList(List<E> list, Object mutex) {
super(list, mutex);
}
:
}
I can modify Javassist so that the above constructors (visible only within the pacakge) will be copied to the generated class. But I am not sure that PojoCache can work with that generated class since it does not have a no-arg constructor.
Chiba
--------
No easy solution to this problem now. Maybe use the exisiting serialization for once during replication?
--
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, 4 months
[JBoss JIRA] Created: (JBCACHE-736) PojoCache passivation failure
by Ben Wang (JIRA)
PojoCache passivation failure
-----------------------------
Key: JBCACHE-736
URL: http://jira.jboss.com/jira/browse/JBCACHE-736
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PojoCache
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Ben Wang
In release 1.4 of PojoCache, passivation won't work becuase the new AopEvictionInterceptor and that we override the evict method such that we issue recursiveEvict that in turn is doing _remove(). Becuase of this, it bypasses the passivation interceptor.
However, the fix is not so obvious. As it also involves the eviction paradigm for POJo as well. In 2.0 instead, I have opted for not to over-ride evict such that we would only support passivation on a node basis (instead of POJO). This way, passivation is transparent to the POJO level. I have a passivation package to test out these cases.
--
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, 4 months