Re: [xmlblaster] Callback message queue fills up
: The callback queue contains only a reference on the message. If it expires the message-'meat' is destroyed but the reference remains in the queue until it is looked at during delivery (and then thrown to garbage), Michele, could this be? thanks Marcel David R Robison wrote: We are experiencing something strange in xmlBlaster 1.6.1. We have two nodes, node A subscribes to messages from node B. These are heartbeat messages and are generated every 15 seconds with a lifetime of 30 seconds. A client connects to node A and subscribes to the messages, node A then passes the subscription onto node B. Watching the callback message queue, everything seems to run well, at most 1 message in the queue waiting to be sent. It can run like this for days. Then, unexpectedly, the callback queue will show as being full (in this case 1001 messages). The queue contains many duplicated messages with different timestamps. From there, the server struggles to deliver the messages and keep the queue empty. The reader never seems to read enough messages to get the queue back down to zero. If I stop the client and reconnect, it will recreate its queue and be back to normal. I know this is a bit sketchy, but it is becoming a real problem for us. Any thoughts on what might be the problem? Any idea of where to start looking? One more note, when the client is subscribing to heartbeats that are generated on Node A, the client never fails in this manor, only when it is subscribing to node A for a message generated on node B. Thanks, in advance, David Robison -- David R Robison Open Roads Consulting, Inc. 708 S. Battlefield Blvd., Chesapeake, VA 23322 phone: (757) 546-3401 e-mail: [EMAIL PROTECTED] web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/book_detail.php?id=2579
Re: [xmlblaster] dead lock
Can you tell me a little more about the conditions that caused the dead lock? We are experiencing a problem that may be related (although it may be just my wacky code). Any additional information would be helpful. David Robison _ From: Marcel Ruff [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Sent: Wed, 26 Sep 2007 07:03:15 -0400 Subject: Re: [xmlblaster] dead lock Hi Xavier, the dead lock is now fixed, the code is available with svn. thanks for reporting, Marcel Xavier Roques wrote: Hi, I'm using Xmlblaster 1.6. I restarted, some connected clients and unfortunately one of my client never connects back :( Even if I restart several times this client, it never successes to connect. That's why I dumped the threads' stack on the server side and I found the following dead lock (see below) Is there a way to avoid it ? Thanks, Xavier. XmlBlaster.ssl_socket.SSL.tcpListener-alouettebench17-agent: INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.getConnectionStatusListener s(DispatchManager.java:206) INFO | jvm 1| 2007/09/25 11:31:29 | - waiting to lock 0xdb74d9c0 (a org.xmlBlaster.util.dispatch.DispatchManager) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.toAlive(DispatchManager.jav a:293) INFO | jvm 1| 2007/09/25 11:31:29 | - locked 0xdb7a0930 (a java.lang.Object) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.updateState(Disp atchConnectionsHandler.java:332) INFO | jvm 1| 2007/09/25 11:31:29 | - locked 0xdb7a0f28 (a java.util.ArrayList) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.toAlive(Dispatch ConnectionsHandler.java:302) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnection.handleTransition(Dispatc hConnection.java:575) INFO | jvm 1| 2007/09/25 11:31:29 | - locked 0xdb7b2838 (a org.xmlBlaster.engine.dispatch.CbDispatchConnection) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnection.initialize(DispatchConne ction.java:132) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.initialize(Dispa tchConnectionsHandler.java:179) INFO | jvm 1| 2007/09/25 11:31:29 | - locked 0xdb7a0f28 (a java.util.ArrayList) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.updateProperty(DispatchMana ger.java:160) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.authentication.SessionInfo.updateConnectQos(SessionInfo.j ava:513) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.authentication.Authenticate.connect(Authenticate.java:276 ) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.authentication.AuthenticateProtector.connect(Authenticate Protector.java:74) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.authentication.AuthenticateProtector.connect(Authenticate Protector.java:62) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.j ava:266) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:379) INFO | jvm 1| 2007/09/25 11:31:29 | at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) INFO | jvm 1| 2007/09/25 11:31:29 | at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) INFO | jvm 1| 2007/09/25 11:31:29 | at java.lang.Thread.run(Thread.java:619) INFO | jvm 1| 2007/09/25 11:31:29 | XmlBlaster.PingTimer: INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.shutdown(Dispatc hConnectionsHandler.java:486) INFO | jvm 1| 2007/09/25 11:31:29 | - waiting to lock 0xdb7a0f28 (a java.util.ArrayList) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.shutdown(DispatchManager.ja va:954) INFO | jvm 1| 2007/09/25 11:31:29 | - locked 0xdb74d9c0 (a org.xmlBlaster.util.dispatch.DispatchManager) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.givingUpDelivery(DispatchMa nager.java:364) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchManager.toDead(DispatchManager.java :356) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.updateState(Disp
Re: [xmlblaster] Strange error when unsubscribing
I do know that the method names are lowercase. I am having my people look at all the values for the database field flag to see if there are more cases of lowercase values. I'll let you know what I find. David - Original Message - From: Marcel Ruff [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] Strange error when unsubscribing Hi again, our persistent entries should be marked with capital letters public static final String ENTRY_TYPE_SUBSCRIBE = SUBSCRIBE; which does not match to the type of your logging output: 'subscribe' I have no idea how this small notation can appear, i believe it must be somewhere in your database? I have commited to the current svn a version which ignores case during persistence lookup, but this is just a temporary workaround, regards Marcel David Robison wrote: We are experiencing a problem running xmlBlaster 1.5.1. After running for several weeks, two nodes in our cluster start reporting the same types of errors: May 23, 2007 12:08:52 PM WARNING 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.jdbc.PreparedQuery close: close with autocommit 'false': rollback May 23, 2007 12:08:52 PM SEVERE 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin loadFromPersistence: connection:/node/StauntonSTC/client/StauntonSTC/1: Could not read back data from persistence: XmlBlasterException serverSideException=true node=[StauntonSTC] location=[ServerEntryFactory] stackTrace=errorCode=internal.notImplemented message=#exported Persistent object 'subscribe' is not implemented at org.xmlBlaster.engine.queuemsg.ServerEntryFactory.createEntry(ServerEntryFactory.java:289) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2017) at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.peek(JdbcQueueCommonTablePlugin.java:576) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.loadFromPersistence(CacheQueueInterceptorPlugin.java:1042) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:545) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:447) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:792) at org.xmlBlaster.client.XmlBlasterAccess.unSubscribe(XmlBlasterAccess.java:931) at org.xmlBlaster.engine.cluster.ClusterManager.forwardUnSubscribe(ClusterManager.java:537) at org.xmlBlaster.engine.RequestBroker.unSubscribe(RequestBroker.java:1167) at org.xmlBlaster.engine.XmlBlasterImpl.unSubscribe(XmlBlasterImpl.java:131) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:490) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:227) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:376) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Unknown Source) versionInfo=version=1.5.1,revision=exported,os.name=Windows 2003,os.version=5.2,java.vm.vendor=Sun Microsystems Inc.,java.vm.version=1.5.0_10-b03,os.arch=x86,build.timestamp=02/26/2007 08:00 AM,build.java.vendor=Sun Microsystems Inc.,build.java.version=1.4.2_06 errorCode description=http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#internal.notImplemented errorCode=internal.notImplemented message=#exported Persistent object 'subscribe' is not implemented at org.xmlBlaster.engine.queuemsg.ServerEntryFactory.createEntry(ServerEntryFactory.java:289) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2017) at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.peek(JdbcQueueCommonTablePlugin.java:576) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.loadFromPersistence(CacheQueueInterceptorPlugin.java:1042) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:545) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:447) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:792) at org.xmlBlaster.client.XmlBlasterAccess.unSubscribe(XmlBlasterAccess.java:931
Re: [xmlblaster] Strange error when unsubscribing
In the logfile portion I sent, it throws a warning that a prepared statement is being closed with autocomplete false. Should we configure access to the postgresql database for autocomplete true? Thanks, David - Original Message - From: Marcel Ruff [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] Strange error when unsubscribing Hi again, our persistent entries should be marked with capital letters public static final String ENTRY_TYPE_SUBSCRIBE = SUBSCRIBE; which does not match to the type of your logging output: 'subscribe' I have no idea how this small notation can appear, i believe it must be somewhere in your database? I have commited to the current svn a version which ignores case during persistence lookup, but this is just a temporary workaround, regards Marcel David Robison wrote: We are experiencing a problem running xmlBlaster 1.5.1. After running for several weeks, two nodes in our cluster start reporting the same types of errors: May 23, 2007 12:08:52 PM WARNING 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.jdbc.PreparedQuery close: close with autocommit 'false': rollback May 23, 2007 12:08:52 PM SEVERE 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin loadFromPersistence: connection:/node/StauntonSTC/client/StauntonSTC/1: Could not read back data from persistence: XmlBlasterException serverSideException=true node=[StauntonSTC] location=[ServerEntryFactory] stackTrace=errorCode=internal.notImplemented message=#exported Persistent object 'subscribe' is not implemented at org.xmlBlaster.engine.queuemsg.ServerEntryFactory.createEntry(ServerEntryFactory.java:289) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2017) at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.peek(JdbcQueueCommonTablePlugin.java:576) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.loadFromPersistence(CacheQueueInterceptorPlugin.java:1042) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:545) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:447) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:792) at org.xmlBlaster.client.XmlBlasterAccess.unSubscribe(XmlBlasterAccess.java:931) at org.xmlBlaster.engine.cluster.ClusterManager.forwardUnSubscribe(ClusterManager.java:537) at org.xmlBlaster.engine.RequestBroker.unSubscribe(RequestBroker.java:1167) at org.xmlBlaster.engine.XmlBlasterImpl.unSubscribe(XmlBlasterImpl.java:131) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:490) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:227) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:376) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Unknown Source) versionInfo=version=1.5.1,revision=exported,os.name=Windows 2003,os.version=5.2,java.vm.vendor=Sun Microsystems Inc.,java.vm.version=1.5.0_10-b03,os.arch=x86,build.timestamp=02/26/2007 08:00 AM,build.java.vendor=Sun Microsystems Inc.,build.java.version=1.4.2_06 errorCode description=http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#internal.notImplemented errorCode=internal.notImplemented message=#exported Persistent object 'subscribe' is not implemented at org.xmlBlaster.engine.queuemsg.ServerEntryFactory.createEntry(ServerEntryFactory.java:289) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2017) at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.peek(JdbcQueueCommonTablePlugin.java:576) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.loadFromPersistence(CacheQueueInterceptorPlugin.java:1042) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:545) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:447) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:792) at org.xmlBlaster.client.XmlBlasterAccess.unSubscribe(XmlBlasterAccess.java:931
Re: [xmlblaster] Strange error when unsubscribing
I know we have in the past had troubles with some plugins. We are integrating data from 911 systems XML messages that are published into a cluster of xmlBlaster nodes. To do this, we deploy xmlBlaster plugins that, in one case, periodically scrapes the 911 dispatch database. New dispatches are detected and then published directly into the xmlBlaster node that the plugin is part of. We have had trouble if we used the wrong Global object (server vs client) when publishing the message. It is possible that we still have a problem with a single plugin. Can you think of any other way this could happen? Thanks, David - Original Message - From: Michele Laghi [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] Strange error when unsubscribing Hi David and Marcel, one possible reason of this problem could be a mixup between client and server queues: The client queue stores subscribe messages which could not be sent as subscribe (lower) (comes out of MethodName.SUBSCRIBE). At the moment I still can not understand how the client entry is read as a server entry. Try to separate the client from the server queues by giving them different names: in JdbcStorage[...].entriesTableName Regards Michele David Robison wrote: In the logfile portion I sent, it throws a warning that a prepared statement is being closed with autocomplete false. Should we configure access to the postgresql database for autocomplete true? Thanks, David - Original Message - From: Marcel Ruff [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] Strange error when unsubscribing Hi again, our persistent entries should be marked with capital letters public static final String ENTRY_TYPE_SUBSCRIBE = SUBSCRIBE; which does not match to the type of your logging output: 'subscribe' I have no idea how this small notation can appear, i believe it must be somewhere in your database? I have commited to the current svn a version which ignores case during persistence lookup, but this is just a temporary workaround, regards Marcel David Robison wrote: We are experiencing a problem running xmlBlaster 1.5.1. After running for several weeks, two nodes in our cluster start reporting the same types of errors: May 23, 2007 12:08:52 PM WARNING 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.jdbc.PreparedQuery close: close with autocommit 'false': rollback May 23, 2007 12:08:52 PM SEVERE 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin loadFromPersistence: connection:/node/StauntonSTC/client/StauntonSTC/1: Could not read back data from persistence: XmlBlasterException serverSideException=true node=[StauntonSTC] location=[ServerEntryFactory] stackTrace=errorCode=internal.notImplemented message=#exported Persistent object 'subscribe' is not implemented at org.xmlBlaster.engine.queuemsg.ServerEntryFactory.createEntry(ServerEntryFactory.java:289) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2017) at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.peek(JdbcQueueCommonTablePlugin.java:576) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.loadFromPersistence(CacheQueueInterceptorPlugin.java:1042) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:545) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:447) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:792) at org.xmlBlaster.client.XmlBlasterAccess.unSubscribe(XmlBlasterAccess.java:931) at org.xmlBlaster.engine.cluster.ClusterManager.forwardUnSubscribe(ClusterManager.java:537) at org.xmlBlaster.engine.RequestBroker.unSubscribe(RequestBroker.java:1167) at org.xmlBlaster.engine.XmlBlasterImpl.unSubscribe(XmlBlasterImpl.java:131) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:490) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:227) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:376) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Unknown Source) versionInfo=version=1.5.1,revision=exported,os.name=Windows 2003,os.version=5.2,java.vm.vendor=Sun Microsystems Inc.,java.vm.version=1.5.0_10-b03,os.arch=x86,build.timestamp=02/26/2007
[xmlblaster] Multiple logging levels
Is there a way to define multiple logs with differing logging levels? For example, using the ConsoleHandler to log at level INFO and the FileHandler to log at level FINEST. I've tried modifying the logging.properties file but I cannot get the logs to log at differing levels. They both seem to use the level set for the .level property. Any thoughts? Thanks, David
Re: [xmlblaster] Not getting callback on erase
Can RequestBroker.update be used to publish messages from a native plugin? David Robison _ From: Marcel Ruff [mailto:[EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Sent: Sun, 04 Mar 2007 12:43:27 -0500 Subject: Re: [xmlblaster] Not getting callback on erase Hi Jonathan, the proper way (also for native plugins) to erase messages is for example: System.err.println(HelloWorldNative: Connecting with protocol 'LOCAL' to xmlBlaster\n); I_XmlBlasterAccess con = new XmlBlasterAccess(glob); ConnectQos qos = new ConnectQos(this.glob); /* Client side object */ qos.setPtpAllowed(false); qos.setUserId(A-NATIVE-CLIENT-PLUGIN); qos.getSessionQos().setSessionTimeout(0L); con.connect(qos, null);// Login to xmlBlaster as A-NATIVE-CLIENT-PLUGIN EraseQos eq = new EraseQos(glob); eq.setForceDestroy(true); EraseKey theEK = new EraseKey(glob, Hello); con.erase(theEK, eq); As an example see demo/javaclients/HelloWorldNative.java or HelloWorldNative2.java http://www.xmlblaster.org/xmlBlaster/doc/requirements/protocol.local.html The method requestBroker.update() is for internal usage only (cluster messages with special syntax) . regards Marcel Jonathan Clark wrote: As a followup to my previous email, it appears that the erased topics are still in the database in the case where they are erased from the plugin, but they do appear to be cleaned up from the database in the external service case. Are there know side affects of using a client side connection from within a plugin? This seems to be the only option to erase topics successfully from within the plugin. Thanks __ I have some code that runs as a separate service that generates topics and when the message is cleared, it then erases the topic after a predefined delay using the code below. EraseQos eq = new EraseQos(glob); eq.setForceDestroy(true); EraseKey theEK = new EraseKey(glob, oid); EraseReturnQos[] eraseArr = con.erase(theEK, eq); When the erase happens, clients listening on the topic receive a callback with the qos.isErased() set to true and can react to the erase. However, I want to convert the code to run as a plugin so that it will only be active when xmlBlaster is running. The code runs, but I have run into a problem. When I process the erase from within a plugin using the following code, then clients listening on the topic do not receive a callback indicating the erase. updateKey = new UpdateKey(engineGlob, msgUnit.getKey()); msgQosData = new MsgQosData(engineGlob, MethodName.ERASE); msgQosData.setForceDestroy(true); requestBroker.update(sessionInfo, updateKey, null, msgQosData); Any thoughts on why the external erases seem to get propogated and the internal erases do not? In all cases the topic appears to get erased, however, the clients do not know about the erase in the second case. Test have been run under 1.5.1. Jonathan Clark Open Roads Consulting, Inc. 757-546-3401
[xmlblaster] Plugin access to ORB
Is there a way for a plugin to get the current ORB used by xmlBlaster?Thanks,David Robison
