[jboss-user] [Clustering/JBoss] - Re: Custom InvokerInterceptor
I'm bumping this as I would be very interested in the response from JBoss themselves. The original questions raised by Ben are highly relevant to the last two JBoss based projects I've worked on, and I'm now hitting it on a 3rd. Would it be possible for JBoss to give a statement on what is the recommended approach to load balancing calls when client and session bean are both inside the container, and that container is clustered? I found a response to this thread on techienuggets http://www.techienuggets.com/Comments?tx=52347 as follows: anonymous wrote : | think you'll want to modify the EJB stack defined in server/all/deploy/ejb3-interceptors-aop.xml. | You can add your custom interceptor or simply remove/comment-out the IsLocal interceptor. | | For example, if you want to make the change for clustered stateless session beans the applicable section could look like this: | | !-- interceptor-ref name=org.jboss.ejb3.remoting.ClusteredIsLocalInterceptor/ -- | interceptor-ref name=org.jboss.aspects.security.SecurityClientInterceptor/ | interceptor-ref name=org.jboss.aspects.tx.ClientTxPropagationInterceptor/ | interceptor-ref name=org.jboss.aspects.remoting.ClusterChooserInterceptor/ | interceptor-ref name=org.jboss.aspects.remoting.InvokeRemoteInterceptor/ | | | Notice the commented out ClusteredIsLocalInterceptor. | | I've been trying to do the exact same thing as you (i.e. cluster ejbs called from within the same JBoss 4.2.3 server). And I just figured this out today. I think it does what I want, but haven't fully exercised it in any way. Let me know if this helps. | | -Randy Could JBoss verify the above as a valid or even recommended approach? Regards, Chris View the original post : http://www.jboss.org/index.html?module=bbop=viewtopicp=4250839#4250839 Reply to the post : http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4250839 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Installation, Configuration DEPLOYMENT] - Re: Specifying the schema for EJBTimerService's TIMERS datab
FWIW, we've also had many problems with this same table, and we're using oracle. Specifying the schema name appears to be redundant - it is ignored. We found that we had to make sure the table name was unique across ALL schemas in the database. That is, we had a schema per developer in the dev environment, and we had to make sure each of us used a different table name. Something very screwy with EJB Timer persistence View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4164046#4164046 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4164046 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Beginners Corner] - Re: How to get a WorkManager from a Bean
+1 But until then, the MBean approach is a good approach. If, however, your system is mostly asynchronous/event driven, then J2EE isn't really the way to proceed; you may want to use the JBoss JSLEE container instead, http://labs.jboss.com/mobicents View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4125067#4125067 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4125067 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Re: Failover failed
Just noticed SP2 released - I'll give it a whirl. In particular, the fix for http://jira.jboss.com/jira/browse/JBMESSAGING-1184 look promising View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=476#476 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=476 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Re: Failover failed
Hi Tim,
First of all, I have a large portion of humble pie to eat - I hadn't clustered
the SLSB that publishes. However, I'm still seeing unreliable results, so I'll
elaborate on what I am doing...
I have a pojo that connects via JNDI to queue/testQueue on the
ClusteredConnectionFactory.
| private void startQueue() throws JMSException, NamingException {
| conn = ((ConnectionFactory)
ctx.lookup(ClusteredConnectionFactory))
| .createConnection(guest, guest);
| queue = (Queue) ctx.lookup(queue/testQueue);
| session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
|
| conn.start();
| }
|
It sends 1000 messages (say) of size 1Kb, that has an integer property
'TopicID' that is a random number from 1 to 50, representing the index of the
topic that the message will be forwarded to inside JBoss.
In my two node JBoss cluster, I have an EJB3 MDB that is listening to the queue
configured thus:
| @Clustered
| @MessageDriven(
| messageListenerInterface=MessageListener.class,
| activationConfig = {
| @ActivationConfigProperty(propertyName=destination,
propertyValue=queue/testQueue),
| @ActivationConfigProperty(propertyName=destinationType,
propertyValue=javax.jms.Queue)
| })
| public class OamServerPushImpl implements OamServerPush, MessageListener
|
This MDB simply forwards onto a SLSB configured as follows, which publishes the
message to the topic indicated by the TopicID property :
| @Clustered
| @Stateless
| public class PublisherImpl implements Publisher {
| @Resource(mappedName=ClusteredConnectionFactory)
| ConnectionFactory topicConnectionFactory;
|
| @Resource
| private SessionContext sc;
|
| Topic topic;
|
| public void redispatch( Message m, String sReceiverAddress, int
iMessageID) {
| Session session = null;
| TextMessage message = null;
|
| try {
| int iTopicID = m.getIntProperty(TopicID);
| String sPayload = m.getStringProperty(Payload);
| connection = topicConnectionFactory.createConnection();
| session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
| // connection.stop();
| connection.start();
|
| message = session.createTextMessage();
|
| message.setText(Redispatching : + sPayload);
| message.setStringProperty(ReceivedBy, sReceiverAddress);
| message.setStringProperty(PublishedBy,
InetAddress.getLocalHost().getHostAddress());
| message.setIntProperty(MessageID, iMessageID);
| sendToClients(session, message, iTopicID);
| connection.close();
| } catch (Throwable t) {
| // JMSException could be thrown
| logger.warn(
| PublisherBean.redispatch: + Exception:
| + t.toString());
| sc.setRollbackOnly();
| } finally {
| if (session != null) {
| try {
| session.close();
| } catch (JMSException e) {
| }
| }
| }
| }
|
| public void sendToClients(Session session, Message message, int
iTopicID)
| throws JMSException {
| topic = (Topic) sc.lookup(topic/testDurableTopic + iTopicID);
| MessageProducer publisher = session.createProducer(topic);
| publisher.send(message);
| publisher.close();
| logger.info(Publisher BEAN: Message published: ( +
| ((TextMessage)message).getText().length() +) bytes);
| }
|
I then have another 50 pojos outside the container each listening to one topic
via a durable subscription
| public class MessageSubscriberClient implements Runnable {
| private static final Logger log =
Logger.getLogger(MessageSubscriberClient.class);
|
| int iCount = 0;
| Connection conn;
| Session session;
| TopicSubscriber subscriber;
| Topic topic;
| Context ctx;
| int i;
| boolean bFinished = false;
|
| static int NUMBER_OF_MESSAGES = 1000;
|
| static final int NUMBER_OF_TOPICS = 50;
|
|
| public MessageSubscriberClient(Context ctx, int i) {
| this.i = i;
| this.ctx = ctx;
|
| try {
| startTopic();
| }
| catch (JMSException e1) {
| log.error(e1.getMessage(), e1);
| }
| catch (NamingException e) {
| log.error(e.getMessage(), e);
| }
|
| }
|
|
| public void run() {
| try {
|
[jboss-user] [JBoss Messaging] - Re: Failover failed
SP2 + the patched jboss remoting gives much better, complete results. I receive duplicates, but I'm sure the clients can handle that if they're aware that it can happen. (For anyone lese reading this, see the Clustering Notes at http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP1/html/c_configuration.html) Thanks very much for your time. Incidentally, anonymous wrote : | You're creating a connection, session, and producer for every message that you forward! | | This will be extremely slow... | Yes that was deliberate, I had copious logging going on that I stripped out of the code I posted. anonymous wrote : | If you're in a managed environment you can use the JCA JMS resource adapter to cache connections: | | See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJMSRA | I'll give that a good look. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4111238#4111238 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4111238 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Re: Failover failed
I'm wondering why durable subscription failover is, in my experience, so flaky. An obvious reason would be that I've got something wrong, although I don't believe I have or otherwise I'd go and fix it (!). If I posted some zipped up code, would anyone in the JBM team be able to give it a sanity check to see if I've got my code/config wrong? If, on the other hand, I've found a JBM bug, does anyone know if there is any way I can mitigate against failover failures? I've tried various exception handling and disconnect/reconnect strategies with some success, but nothing reliable Chris View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4110913#4110913 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4110913 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Messaging] - Failover failed
JBoss 4.2.2 GA with JBM 1.4.0.SP1 configured as per documentation, deployed identically over a two node cluster (ServerPeers 0 and 1 respectively). I send 1000 messages to a queue. An MDB is listening to the queue, and it redispatches each message to one of 50 topics (randomly). Each topic has a durable subscription client that is already listening before the message sending begins. At some point after messages have started being sent, redispatched and received, I kill the receiving node in the cluster with a kill -9. Sometimes failover works, but in my experience this is not the norm. More often I get a 'Failover failed'. See stacktrace below. It's complaining about duplicate clientIDs, but it isn't my code that is setting them, so I don't see what I can do. Any ideas? | 638453 [Thread-259] ERROR org.jboss.jms.client.FailoverCommandCenter - Failover failed | javax.jms.IllegalStateException: Cannot set clientID, already set as DurableSubscriberExample31 | at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.setClientID(ServerConnectionEndpoint.java:309) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$setClientID$aop(ConnectionAdvised.java:85) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$setClientID_N1479100880614063379.invokeNext(ConnectionAdvised$setClientID_N1479100880614063379.java) | at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$setClientID_N1479100880614063379.invokeNext(ConnectionAdvised$setClientID_N1479100880614063379.java) | at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.setClientID(ConnectionAdvised.java) | at org.jboss.jms.wireformat.ConnectionSetClientIDRequest.serverInvoke(ConnectionSetClientIDRequest.java:73) | at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) | at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163) | at org.jboss.remoting.Client.invoke(Client.java:1634) | at org.jboss.remoting.Client.invoke(Client.java:548) | at org.jboss.remoting.Client.invoke(Client.java:536) | at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:187) | at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:158) | at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$setClientID$aop(ClientConnectionDelegate.java:228) | at org.jboss.jms.client.delegate.ClientConnectionDelegate$setClientID_N1479100880614063379.invokeNext(ClientConnectionDelegate$setClientID_N1479100880614063379.java) | at org.jboss.jms.client.container.ConnectionAspect.handleSetClientID(ConnectionAspect.java:105) | 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.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) | at org.jboss.jms.client.delegate.ClientConnectionDelegate$setClientID_N1479100880614063379.invokeNext(ClientConnectionDelegate$setClientID_N1479100880614063379.java) | at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:114) | at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) | at org.jboss.jms.client.delegate.ClientConnectionDelegate$setClientID_N1479100880614063379.invokeNext(ClientConnectionDelegate$setClientID_N1479100880614063379.java) | at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) | at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) | at org.jboss.jms.client.delegate.ClientConnectionDelegate$setClientID_N1479100880614063379.invokeNext(ClientConnectionDelegate$setClientID_N1479100880614063379.java) | at org.jboss.jms.client.delegate.ClientConnectionDelegate.setClientID(ClientConnectionDelegate.java) | at org.jboss.jms.client.delegate.ClientConnectionDelegate.synchronizeWith(ClientConnectionDelegate.java:120) | at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:145) | at
[jboss-user] [JBoss Messaging] - Re: Jboss problem with messages over 2.5 M.B.
The docs advise you to not use HSQLDB for serious work - it isn't a production database. Use something else e.g. MySQL View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4110257#4110257 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4110257 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: SFSB failover not working as expected
Whoops - forgot to mention that this is EJB3. Can't edit forum posts :( View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4104959#4104959 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4104959 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - Re: SFSB failover not working as expected
It's a proper shutdown - I do a run.sh -c all -b 0.0.0.0 to start the server in the foreground, then do a Ctrl-C View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4105099#4105099 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4105099 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Clustering/JBoss] - SFSB failover not working as expected
Hi there, I'm testing two JBoss 4.2.2 GA nodes in a cluster using the 'all' config. The nodes cluster together fine. I then run a multithreaded client to start up 200 or so SFSBs that cycle through a number of states. The client requests are are load balanced in the cluster as expected. However, when I test failover by killing one of the nodes mid test, I get various exceptions such as javax.ejb.NoSuchEJBException, Could not find stateful bean: 4ss55r-gaev0q-f901ig99-1-f901ok6j-5w (bean was marked as removed) and javax.naming.NamingException, Could not dereference object If I catch the exceptions and retry the client requests, then the SFSB state is sorted out and the results are as they should be I might have missed something here, but I was expecting the client side interceptors to reroute client requests automatically on cluster member failure, i.e. I shouldn't have to programmatically catch the exceptions and retry. I'm using HA-JNDI as follows | jndiProps.put(java.naming.provider.url, jnp://foo.zub.com:1100,jnp://bar.zub.com:1100); | jndiProps.put(java.naming.factory.initial, org.jnp.interfaces.NamingContextFactory); | jndiProps.put(java.naming.factory.url.pkgs, org.jboss.naming:org.jnp.interfaces); | and I've added retry interceptors as per section 16.3.1.1 of the JBoss 4 manual. Did I miss something? Or have I misunderstood how JBoss failover is dealt with from the client? Any insight/clarification gratefully received, Regards, Chris View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4104701#4104701 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4104701 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: One node in two clusters?
I've almost achieved what I need by using TcpDelegatingCacheLoaders. The configuration I have is: Cluster 1 has two nodes A and B replicating using UDP. Cluster 2 has two nodes C and D replicating using UDP. A, B, C, D all use unshared cacheloaders Clusters 1 and 2 cannot find each other Node A has a chained TcpDelegatingCacheLoader, delegating to a TcpCacheServer that wraps node D Node C has a chained TcpDelegatingCacheLoader, delegating to a TcpCacheServer that wraps node B Now what happens is that a single cache change is continually propagated in a loop, typically A-C-B-D-A, because A does not know that the update incoming from D originated from A (A and D are in separate clusters). I think I'm close to what I am trying to achieve; can anyone fill in the miss bits? Can the data packets be given UUIDs so that A can ignore packets that it created? Also, it looks like the true tag is ignored for the TcpDelegatingCacheLoader View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4020124#4020124 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4020124 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - One node in two clusters?
Is it possible for one cache node to be in two clusters? I've read in a couple of places around the JBoss website that it is possible, but haven't seen how to configure the cache in that way. What config sections do I duplicate? The reason I want to do this as follows; I have a cluster in Europe and a cluster in USA. The nodes in each cluster replicate synchronously over LAN via UDP. Then I want one node of each cluster to also replicate asynchronously over WAN via TCP to the other cluster. What config setup do I need for the nodes that are replicating both within the LAN and the WAN? Do I duplicate the JGroup config, but then how do I relate the UDP config to sync LAN replication and TCP config to async WAN replication? Or do I have to use a shared cache loader? I've thought about it, but that seems a tricky implementation and so doesn't feel like the right solution. Can anyone provide any insight? Or better still, an example config file? Thanks for any help, Chris View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4018870#4018870 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4018870 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Persistent configuration in clustered environment.
Thanks Manik. My caches are geographically separated (UK, Japan, east and west coast US), so I don't think shared cache loaders I going to work for me unless I do async cache loader updates, and I'm pretty sure I don't want to do that. The configuration I'm trying out has N gegraphically separate persistent JBC clusters, each cluster having it's own local shared cache loader. Local changes in the cluster are propagated transactionally to cluster members and persistent store. One member of each cluster is then also in another cluster that handles the async data propagation between localised clusters. I might make the cluster-cluster synchronous and use buddy replication in a cyclic graph instead. Does this sound like a sensible configuration, or am I going wrong? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4014903#4014903 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4014903 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Persistent configuration in clustered environment.
victor75 wrote : Thank you for the answer.
|
| I have one problematic scenario.
| There're two instances in my clustered environment: serverA and
serverB, at the beginning both of them are alive.
| step 1. shutdown the serverA
| step 2. make a change in serverB.
| step 3. shutdown the serverB
| step 4. start the serverA
| step 5. start the serverB.
|
| The problem is that a change in step 2 was lost.
|
| Is there any solution here?
|
| Victor.
I've tried to do this as well with JBC 1.4.1, and I am using a cache loader as
per Manik's suggestion, but I still get the same problem as Victor - changes to
serverB are lost.
So I thought I'd go back and look at the JUnit tests and run them. The one I am
interested in is
| build one.test.aop50
-Dtest=org.jboss.cache.loader.CacheLoaderWithReplicationTest
|
I've added a test csae like this
| public void testPessSyncReplFailureRecovery1() throws Exception
| {
| cache1.setCacheMode(TreeCache.REPL_SYNC);
| cache2.setCacheMode(TreeCache.REPL_SYNC);
|
| cache1.startService();
| cache2.startService();
|
| Assert.assertNull(cache1.get(fqn, key));
| Assert.assertNull(cache2.get(fqn, key));
|
|
| CacheLoader loader1 = cache1.getCacheLoader();
| CacheLoader loader2 = cache2.getCacheLoader();
|
| TransactionManager mgr = cache1.getTransactionManager();
| mgr.begin();
| cache1.put(fqn, key, value);
|
| Assert.assertEquals(value, cache1.get(fqn, key));
| Assert.assertNull(cache2.get(fqn, key));
| Assert.assertNull(loader1.get(fqn));
| Assert.assertNull(loader2.get(fqn));
| mgr.commit();
|
| Assert.assertEquals(value, cache1.get(fqn, key));
| Assert.assertEquals(value, cache2.get(fqn, key));
| Assert.assertEquals(value, loader1.get(fqn).get(key));
| Assert.assertEquals(value, loader2.get(fqn).get(key));
|
| cache2.stopService();
|
| mgr.begin();
| cache1.put(fqn, key, value2);
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value, loader1.get(fqn).get(key));
|
| mgr.commit();
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value2, loader1.get(fqn).get(key));
|
| cache1.stopService();
|
| cache1.startService();
| cache2.startService();
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value2, loader1.get(fqn).get(key));
| Assert.assertEquals(value2, cache2.get(fqn, key));
| Assert.assertEquals(value2, loader2.get(fqn).get(key));
|
| // force clean up
| tearDown();
| }
|
and it fails on the line in bold, indicating that the caches are in synch but
that the cache loaders are not. Could somebody explain why please? Shouldn't
the cache loaders also be in synch?
I then swapped the order in which cache1 and cache2 are restarted as follows
| public void testPessSyncReplFailureRecovery2() throws Exception
| {
| cache1.setCacheMode(TreeCache.REPL_SYNC);
| cache2.setCacheMode(TreeCache.REPL_SYNC);
|
| cache1.startService();
| cache2.startService();
|
| Assert.assertNull(cache1.get(fqn, key));
| Assert.assertNull(cache2.get(fqn, key));
|
|
| CacheLoader loader1 = cache1.getCacheLoader();
| CacheLoader loader2 = cache2.getCacheLoader();
|
| TransactionManager mgr = cache1.getTransactionManager();
| mgr.begin();
| cache1.put(fqn, key, value);
|
| Assert.assertEquals(value, cache1.get(fqn, key));
| Assert.assertNull(cache2.get(fqn, key));
| Assert.assertNull(loader1.get(fqn));
| Assert.assertNull(loader2.get(fqn));
| mgr.commit();
|
| Assert.assertEquals(value, cache1.get(fqn, key));
| Assert.assertEquals(value, cache2.get(fqn, key));
| Assert.assertEquals(value, loader1.get(fqn).get(key));
| Assert.assertEquals(value, loader2.get(fqn).get(key));
|
| cache2.stopService();
|
| mgr.begin();
| cache1.put(fqn, key, value2);
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value, loader1.get(fqn).get(key));
|
| mgr.commit();
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value2, loader1.get(fqn).get(key));
|
| cache1.stopService();
|
| cache2.startService();
| cache1.startService();
|
| Assert.assertEquals(value2, cache1.get(fqn, key));
| Assert.assertEquals(value2, loader1.get(fqn).get(key));
[jboss-user] [JBossCache] - runShellDemo.sh broken in 1.4.1 GA ?
Believe I've found some broken parts of runShellDemo.sh in JBossCache 1.4.1 GA. I was getting a Exception in thread main java.lang.NoClassDefFoundError: bsh/Console fix to line 4 CACHE_HOME=. (not ./../) fix to line 39 java -cp $CLASSPATH $ARGS $JAVA_OPTS -Djboss.aop.aoppath=$AOP_PATH bsh.Console (not $CP) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4006272#4006272 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4006272 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: EntityManagers and DAOs
ALRubinger wrote : | ...if you set stuff in a ThreadLocal, ensure that its removed if the Thread has been obtained from a Thread pool. Otherwise, nightmares. | Thanks ALR, I'll watch out for that ALRubinger wrote : | Or in your case...if you don't want to put any JPA stuff in your DAO APIs...why not just pass the EM into the DAOImpl Constructor? | DAOImpls are currently singleton per DAO iface, but must be thread safe, so I'm using ThreadLocal rather than passing in via method parameters. I could stop using a singleton and create a DAOImpl per DAO request (as you suggest), but then I have a proliferation of DAOs just to ensure thread safety which smells of an antipattern. Thank you for your comments everyone. C View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3984828#3984828 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3984828 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - EntityManagers and DAOs
My scenario is that I don't want to do my entity manager interaction in a
session bean - I want to use a layering approach that has Session beans -
Business Delegates - DAOs - JPA entities.
I'm getting frustrated that I cannot inject an entity manager into a DAO class
inside the ejb container becasue it is not an EJB. I could use a jndi lookup,
but then I jhave to worry about closing the entity manager.
What I really want is to be able to access the EntityManager that was injected
into the session bean that was my entry point to the container, but
I do not want to pollute my BD and DAO API's with entity manager parameters.
So, can I use ThreadLocal's? Do the folk at JBoss have a paradigm for doing
this, or am I doing something completely stupid?
The example code that follows is significantly trimmed. I've also left out the
BD, and ignore the fact that a JPA entity is being returned to the client.
I have a session bean with a simple getter method to load an entity. It
delegates to a DAO
| @Stateful
| @Remote
| public class StatefulColumnGroupServiceBean {
|
| @PersistenceContext(unitName=MyApp,
type=PersistenceContextType.EXTENDED)
| protected EntityManager em;
|
| public ColumnGroupEntity getColumnGroup(int iThreadNumber, long id)
throws ServerException {
| EntityManagerResource.getInstance().set(em);
| ColumnGroupEntity cgvo = null;
| try {
| cgvo = ColumnGroupDAO.getInstance().getColumnGroup(id);
| }
| catch (DAOException e) {
| log.error(e);
| throw new ServerException(
MessageFactory.getMessage(Bean.CannotFind, ColumnGroup) + id, e );
| }
| return cgvo;
| }
| }
|
The DAO is
| public class ColumnGroupDAO {
|
| public ColumnGroupEntity getColumnGroup( long id ) throws DAOException {
| EntityManager em = EntityManagerResource.getInstance().get();
|
| ColumnGroupEntity res = null;
| try {
| res = em.find(ColumnGroupEntity.class, id);
| }
| catch (RuntimeException e) {
| throw new DAOException(MessageFactory.getMessage(DAO.FindError,
getClass().getName()) + id, e);
| }
| return res;
| }
|
|
| protected ColumnGroupDAO() {
| }
|
| public static ColumnGroupDAO getInstance() {
| if( instance == null ) {
| synchronized( ColumnGroupDAO.class ) {
| if( instance == null ) {
| instance = new ColumnGroupDAO();
| }
| }
| }
| return instance;
| }
|
| private static ColumnGroupDAO instance = null;
|
| }
|
and the EntityManager is passed between bean and DAO by using a singleton
ThreadLocal wrapping an EntityManager instance
| public class EntityManagerResource extends
ThreadLocalResourceEntityManager {
|
| private static EntityManagerResource instance = null;
|
| public static EntityManagerResource getInstance( ) {
| if( instance == null ) {
| synchronized( EntityManagerResource.class ) {
| if( instance == null ) {
| instance = new EntityManagerResource( );
| }
| }
| }
| return instance;
| }
|
| protected EntityManagerResource() {
| }
| }
|
| public abstract class ThreadLocalResourceT {
|
| private final ThreadLocalT resource = new ThreadLocal( );
|
| public void set( T em ) {
| resource.set(em);
| }
|
| public T get( ) {
| return resource.get();
| }
| }
|
|
Does this make sense? Any suggestions?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3984556#3984556
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3984556
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: EntityManagers and DAOs
Done some more testing using the above ThreadLocal paradigm, because I was worried about multiple serfver side threads and in particular if the JBoss container ever uses 1 thread to service a session bean call. But apparently it does not - I can happily kick off multiple (e.g. 100) concurrent client threads that start multiple SFSBs, and all is fine. So it's promising. I don't want to take it too much further in case a JBoss representative confirms that there is a very good reason to not do this, and if so, indicate a better way of doing it. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3984604#3984604 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3984604 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Aspect scope and construction pointcuts
Hi there,
I've pulled and built the 1_5_0 branch, but still get the same problem. I've
been having a look at the source and believe the casue of the problem is in
org.jboss.aop.advice.AbstractAdvice#resolveAdvice(Invocation)
The code I see states
| ...
| if (invocation instanceof ConstructorInvocation)
| {
| if (constructorAdvice == null)
| {
| throw new IllegalStateException(Unable to resolve
ConstructorInvocation advice + getName());
| }
| return constructorAdvice;
| }
| if (invocation instanceof ConstructionInvocation)
| {
| if (constructorAdvice == null)
| {
| throw new IllegalStateException(Unable to resolve
ConstructionInvocation advice + getName());
| }
| return constructorAdvice;
| }
|
| ...
|
This looks like copy-and-pastification. Should it be...
| ...
| if (invocation instanceof ConstructorInvocation)
| {
| if (constructorAdvice == null)
| {
| throw new IllegalStateException(Unable to resolve
ConstructorInvocation advice + getName());
| }
| return constructorAdvice;
| }
| if (invocation instanceof ConstructionInvocation)
| {
| if (constructionAdvice == null) // construction, not constructor
| {
| throw new IllegalStateException(Unable to resolve
ConstructionInvocation advice + getName());
| }
| return constructionAdvice; // construction, not constructor
| }
|
| ...
|
is this the fix from yesterday? If so, I'm not seeing it in the pull of the
1_5_0 branch :(
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3982906#3982906
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3982906
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Aspect scope and construction pointcuts
Thanks for replying stalep.
stalep wrote :
| @Aspect(scope=Scope.PER_INSTANCE)
| | public class MyAspect {
| | @Bind (pointcut=execution(public MyAspected-new()))
| | public Object construction(Invocation invocation) throws Throwable {
... }
| | }
|
Yup, I had tried with an execution (rather than construction) pointcut as well,
and it hadn't worked. I thought it was better to report an exception rather
than an apparent no-op.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3982628#3982628
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3982628
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Re: Aspect scope and construction pointcuts
Thanks Kabir/Stalep! Much appreciated. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3982635#3982635 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3982635 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss AOP] - Aspect scope and construction pointcuts
AOP 1.5.2 libs being used
I'm having problems with construction pointcuts and PER_INSTANCE scope. All
other scopes work as expected, but it is PER_INSTANCE that I need.
@Aspect(scope=Scope.PER_INSTANCE)
public class MyAspect {
private static final Logger log = Logger.getLogger(MyAspect.class);
@Bind (pointcut=construction(public MyAspected-new()))
public Object constructorAdvice(ConstructionInvocation invocation) throws
Throwable {
Object master = invocation.invokeNext();
log.info(Constructed Aspect);
return master;
}
}
--
public class MyAspected {
private static Logger log = Logger.getLogger( MyAspected.class );
public MyAspected() {
log.info(Constructed);
}
}
--
public class TestMyAspected extends TestCase {
static {
BasicConfigurator.configure();
}
public void testMyAspected() {
MyAspected ta = new MyAspected();
}
}
All scopes work correctly except PER_INSTANCE. With that scope, I get a nasty
exception which looks like the AOP framework couldn't find the Advice for the
aspected constructor.
java.lang.RuntimeException: Should Be Unreachable, but unable to discover Advice
at
org.jboss.aop.advice.AbstractAdvice.resolveAdvice(AbstractAdvice.java:292)
at
org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:125)
at
org.jboss.aop.joinpoint.ConstructionInvocation.invokeNext(ConstructionInvocation.java:78)
at MyAspected.(MyAspected.java:10)
at TestMyAspected.testMyAspected(TestMyAspected.java:16)
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 junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
Any ideas?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3982420#3982420
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3982420
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
