[JBoss JIRA] (AS7-5722) Backward compatibility issue with JMS clients
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/AS7-5722?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil commented on AS7-5722:
----------------------------------
I was able to connect to AS7 master (with HornetQ 2.3.0.BETA3) from a clien using the client lib for AS7 7.1.2.Final.
> Backward compatibility issue with JMS clients
> ---------------------------------------------
>
> Key: AS7-5722
> URL: https://issues.jboss.org/browse/AS7-5722
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 7.2.0.Alpha1
>
>
> When standalone jms client is trying to connect with "old" jboss-client.jar from AS 7.1.2.Final (HornetQ 2.2.16.Final) to AS 7.2.0.Alpha1 (HornetQ 2.3.0.Beta1) then ClassNotFoundException it thrown:
> Console log of jms client:
> {code}
> [jbossqa@station4 as7-with-hq-replicated]$ java -cp /home/jbossqa/hornetq_eap6_testsuite/as7-with-hq-replicated/client-1.0-SNAPSHOT.jar:/home/jbossqa/hornetq_eap6_testsuite/server1/jboss-eap-6.0/bin/client/jboss-client.jar org.jboss.jms.client.TestProducer 192.168.40.1 jms/queue/testQueue0 10
> remote://192.168.40.1:4447
> Oct 10, 2012 11:44:41 AM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.6.GA-redhat-1
> Oct 10, 2012 11:44:41 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.8.SP1-redhat-1
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID f6fa08e1 (outbound) of Remoting connection 2a0ab444 to /192.168.40.1:4447
> org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:49)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:78)
> at org.jboss.naming.remote.client.HaRemoteNamingStore$1.operation(HaRemoteNamingStore.java:227)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:119)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:409)
> at org.jboss.jms.client.TestProducer.startClient(TestProducer.java:47)
> at org.jboss.jms.client.TestProducer.main(TestProducer.java:28)
> Caused by: java.io.IOException: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:159)
> at org.jboss.naming.remote.protocol.v1.BaseProtocolCommand.readResult(BaseProtocolCommand.java:60)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleClientMessage(Protocol.java:149)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver$1.run(RemoteNamingStoreV1.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> Caused by: java.lang.ClassNotFoundException: org.hornetq.api.core.BroadcastEndpointFactoryConfiguration
> at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:871)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:903)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1205)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1558)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$3.read(Protocol.java:156)
> ... 6 more
> Oct 10, 2012 11:44:42 AM org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1$MessageReceiver handleEnd
> ERROR: Channel end notification received, closing channel Channel ID dac0f594 (outbound) of Remoting connection 16e1eea8 to /192.168.40.1:4447
> {code}
> How to reproduce:
> 1) Download reproducer.zip from QA Lab and unzip reproducer.zip: {code}scp -r messaging-18.jbm.lab.bos.redhat.com:/home/mnovak/reproducer-backward-compatibility .{code}
> 2) Start AS7 server:{code}cd jboss-as-7.2.0.Alpha1-SNAPSHOT/bin;sh standalone.sh -c standalone-full-ha.xml -b localhost{code}
> 3) Start jms producer:{code}java -cp $PWD/client-1.0-SNAPSHOT.jar:$PWD/jboss-old-hq226-client.jar org.jboss.jms.client.TestProducer localhost jms/queue/testQueue0 10{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6317) Uploaded File Replication in cluster
by hitesh yadav (JIRA)
[ https://issues.jboss.org/browse/AS7-6317?page=com.atlassian.jira.plugin.s... ]
hitesh yadav updated AS7-6317:
------------------------------
Description:
We are using jboss-as-web-7.0.2.Final with Linux , Postgresql , Mod_cluster as Load balancer .
Our goal is to achieve 2 or 3 Node in cluster.
Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication.
We want same thing for Uploaded file replication.
Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster .
we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic.
We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap .
We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File.
In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node.
was:
We are using jboss-as-web-7.0.2.Final with Linux , Postgresql Mod_cluster as Load balancer .
Our goal is to achieve 2 or 3 Node in cluster.
Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication.
We want same thing for Uploaded file replication.
Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster .
we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic.
We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap .
We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File.
In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node.
> Uploaded File Replication in cluster
> ------------------------------------
>
> Key: AS7-6317
> URL: https://issues.jboss.org/browse/AS7-6317
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 7.0.2.Final
> Environment: jboss-as-web-7.0.2.Final , Linux , Postgresql , Mod_cluster as Load balancer
> Reporter: hitesh yadav
> Assignee: Paul Ferraro
> Labels: jboss, synced
>
> We are using jboss-as-web-7.0.2.Final with Linux , Postgresql , Mod_cluster as Load balancer .
> Our goal is to achieve 2 or 3 Node in cluster.
> Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication.
> We want same thing for Uploaded file replication.
> Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster .
> we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic.
> We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap .
> We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File.
> In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4581) Connection manager not available during shutdown
by Fabien Tillay (JIRA)
[ https://issues.jboss.org/browse/AS7-4581?page=com.atlassian.jira.plugin.s... ]
Fabien Tillay commented on AS7-4581:
------------------------------------
We have this problem as well in a shutdown hook process of a JMS queue.
Do you plan to resolve it ?
> Connection manager not available during shutdown
> ------------------------------------------------
>
> Key: AS7-4581
> URL: https://issues.jboss.org/browse/AS7-4581
> Project: Application Server 7
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.0.2.Final, 7.1.1.Final
> Reporter: Ori Kremer
> Attachments: TestEAR.zip
>
>
> The problem occurs when trying to access the database during the shutdown phase.
> It looks like when our shutdown code tries to access the database - it is no longer available.
> Our application is deployed as an EAR that has a SAR module to handle startup and shutdown.
> We add our application specific startup and shutdown code in the corresponding MBean hooks.
> In JBoss 7.0.2 and 7.1.1 we're encountering an error when the shutdown code is attempting to access the database and is failing due to the fact that the connection manager is closed:
> 13:08:37,975 ERROR [org.jboss.as.service] JBAS017200: Failed to execute legacy service stop() method: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_01]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_01]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_01]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_01]
> at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:52) [jboss-as-sar-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.service.StartStopService.stop(StartStopService.java:66) [jboss-as-sar-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_01]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_01]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_01]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:/org.test.NonSecureDS
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:137)
> at org.test.StartupService.updateStatus(StartupService.java:37)
> at org.test.StartupService.stop(StartupService.java:56)
> ... 11 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:/org.test.NonSecureDS
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:321)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:129)
> ... 13 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6317) Uploaded File Replication in cluster
by hitesh yadav (JIRA)
[ https://issues.jboss.org/browse/AS7-6317?page=com.atlassian.jira.plugin.s... ]
hitesh yadav updated AS7-6317:
------------------------------
Summary: Uploaded File Replication in cluster (was: Uploaded File Replication)
> Uploaded File Replication in cluster
> ------------------------------------
>
> Key: AS7-6317
> URL: https://issues.jboss.org/browse/AS7-6317
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 7.0.2.Final
> Environment: jboss-as-web-7.0.2.Final , Linux , Postgresql , Mod_cluster as Load balancer
> Reporter: hitesh yadav
> Assignee: Paul Ferraro
> Labels: jboss, synced
>
> We are using jboss-as-web-7.0.2.Final with Linux , Postgresql Mod_cluster as Load balancer .
> Our goal is to achieve 2 or 3 Node in cluster.
> Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication.
> We want same thing for Uploaded file replication.
> Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster .
> we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic.
> We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap .
> We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File.
> In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6317) Uploaded File Replication
by hitesh yadav (JIRA)
hitesh yadav created AS7-6317:
---------------------------------
Summary: Uploaded File Replication
Key: AS7-6317
URL: https://issues.jboss.org/browse/AS7-6317
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering
Affects Versions: 7.0.2.Final
Environment: jboss-as-web-7.0.2.Final , Linux , Postgresql , Mod_cluster as Load balancer
Reporter: hitesh yadav
Assignee: Paul Ferraro
We are using jboss-as-web-7.0.2.Final with Linux , Postgresql Mod_cluster as Load balancer .
Our goal is to achieve 2 or 3 Node in cluster.
Using jboss-as-web-7.0.2.Final we get HttpSession replication + Cache Replication.
We want same thing for Uploaded file replication.
Meas when we upload image file or some other file in cluster it must have to replicate to all node in cluster .
we d'nt want to store file in database b'coz of large size and we r using database replication so it take lots of Network traffic.
We have look GridFilesystem but it store file in memory which is not acceptable due to size of Heap .
We want some solution from JBOSS side that one or more directory in cluster sync with each other .....so that any file uploaded in this Direcory all Node in Cluster get same File.
In case, Node which handle client request crash then other Node must have knowledge to handle request related with Uploaded File on previous Node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6272) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/AS7-6272?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated AS7-6272:
-------------------------------
Assignee: (was: Tom Jenkinson)
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: AS7-6272
> URL: https://issues.jboss.org/browse/AS7-6272
> Project: Application Server 7
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.1.3.Final (EAP)
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5940) Support configuring the transaction subsystem JDBC ObjectStore
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-5940?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri updated AS7-5940:
---------------------------------
Git Pull Request: https://github.com/jbossas/jboss-as/pull/3850 (was: https://github.com/jbossas/jboss-as/pull/3590)
> Support configuring the transaction subsystem JDBC ObjectStore
> --------------------------------------------------------------
>
> Key: AS7-5940
> URL: https://issues.jboss.org/browse/AS7-5940
> Project: Application Server 7
> Issue Type: Task
> Components: Transactions
> Reporter: Tom Jenkinson
> Assignee: Stefano Maestri
>
> The JDBC ObjectStore has been added back into AS7 as part of JBTM-1230. The transaction subsystem needs to support configuring the store.
> NOTE THIS OBJECT STORE TYPE IS OPTIONAL AND SHOULD NOT REPLACE THE DEFAULT OBJECT STORE TYPE, i.e. if the user does not add these config options the AS7 should only provide the config to JBTM as it does today
> The properties that need to be set to enable JDBC object store are:
> ObjectStoreEnvironmentBean.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore
> ObjectStoreEnvironmentBean.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess;datasourceName=<JNDI-name-of-AS7-configured-none-xa-datasource>
> OPTIONAL ObjectStoreEnvironmentBean.tablePrefix=<whatever>
> OPTIONAL ObjectStoreEnvironmentBean.dropTable=false
> ObjectStoreEnvironmentBean.stateStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore
> ObjectStoreEnvironmentBean.stateStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess;datasourceName=<JNDI-name-of-AS7-configured-none-xa-datasource>
> OPTIONAL ObjectStoreEnvironmentBean.stateStore.tablePrefix
> OPTIONAL ObjectStoreEnvironmentBean.stateStore.dropTable
> ObjectStoreEnvironmentBean.communicationStore.objectStoreType=com.arjuna.ats.internal.arjuna.objectstore.jdbc.JDBCStore
> ObjectStoreEnvironmentBean.communicationStore.jdbcAccess=com.arjuna.ats.internal.arjuna.objectstore.jdbc.accessors.DataSourceJDBCAccess;datasourceName=<JNDI-name-of-AS7-configured-none-xa-datasource>
> OPTIONAL ObjectStoreEnvironmentBean.communicationStore.tablePrefix
> OPTIONAL ObjectStoreEnvironmentBean.communicationStore.dropTable
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months