Re: Fwd: [xmlblaster] server side exception: Can't process XPath expression
};
}
myxpath = method_newXPath.invoke(instance_XPathFactory,
new Object[0]);
Object[] params = new Object[] { expression, document,
field_NODESET };
java.lang.reflect.Method method_evaluate =
clazz_XPath.getMethod(evaluate, paramCls_StringDocument);
final org.w3c.dom.NodeList nodes =
(org.w3c.dom.NodeList)method_evaluate.invoke(myxpath, params);
final int length = nodes.getLength();
return new java.util.Enumeration() {
int i=0;
public boolean hasMoreElements() {
return ilength;
}
public Object nextElement() {
i++;
return nodes.item(i-1);
}
};
}
thanks for looking into this,
andrew
-- Forwarded message --
From: Andrew Yinger andrew.yin...@gmail.com
Date: Sat, Aug 25, 2012 at 10:07 PM
Subject: Re: [xmlblaster] server side exception: Can't process XPath expression
To: Marcel Ruff m...@marcelruff.info
Cc: xmlblaster xmlblaster@server.xmlblaster.org
with version 2.1.0 of the server, i still (although rarely) see the
server-side error. it seems to be encountered only during unit
testing, when many simultaneous publish/subscribe events are
triggered. is it possible that there is an XPathFactory instance
somewhere else that is not properly synchronized? (i am not positive
that the error is caused by an XPathFactory synchronization issue --
i'm just basing that diagnosis on earlier post regarding sporadic,
invalid, server-side xpath expression errors).
regards,
andrew
On Sat, Aug 25, 2012 at 2:07 AM, Marcel Ruff m...@marcelruff.info wrote:
Am 24.08.2012 05:01, schrieb Andrew Yinger:
i believe this issue was identified before, but i occasionally see a
server-side exception that starts off like:
errorCode=user.query.invalid message=#exported Sorry, can't access,
query syntax of
XmlBlasterException errorCode=[resource.configuration]
serverSideException=true location=[XmlNotPortable]
message=[#exported Can't process XPath expression .
it was first suggested that this was a parsing issue -- a possible xml
parser library conflict. (i have verified that i do *not* have any
extraneous xml parsing libs in my 'java\lib\endorsed' directory.)
later, a user noticed that a similar error was happening during unit
testing, and that it was a bug on the server:
The issues are:
1. The null check (method_newXPath == null) is outside the
synchronization block. Thread A and thread B could both pass through
the null check at the same time. Thread A will create the xpath
objects while B waits. Then thread B will go through and recreate
xpath objects while A is using them.
2. XPathFactory is, in general, not thread-safe (see
http://java.sun.com/javase/6/docs/api/javax/xml/xpath/XPathFactory.html),
and a method on that object is invoked outside the synchro block.
In the current code it looks like this:
Object xpath = null;
synchronized(XmlNotPortable.class) {
if (method_newXPath == null) {
clazz_XPathFactory =
java.lang.Class.forName(javax.xml.xpath.XPathFactory);
Class[] paramCls = new Class[0];
Object[] params = new Object[0];
java.lang.reflect.Method method =
clazz_XPathFactory.getMethod(newInstance, paramCls);
instance_XPathFactory = method.invoke(clazz_XPathFactory,
params);
method_newXPath = clazz_XPathFactory.getMethod(newXPath,
paramCls);
clazz_XPath =
java.lang.Class.forName(javax.xml.xpath.XPath);
Class clazz_XPathConstants =
java.lang.Class.forName(javax.xml.xpath.XPathConstants);
clazz_QName =
java.lang.Class.forName(javax.xml.namespace.QName);
java.lang.reflect.Field field =
clazz_XPathConstants.getDeclaredField(NODESET);
field_NODESET = field.get(null);
paramCls_StringDocument = new Class[] {
java.lang.String.class,
java.lang.Object.class, //
org.w3c.dom.Document.class,
clazz_QName };
}
xpath = method_newXPath.invoke(instance_XPathFactory, new
Object[0]);
}
so it seems to be correctly synchronized, or do I overlook your issue?
Thank you
Marcel
has this bug been fixed? if so, what version should i be using now?
(i am currently using xmlBlaster version 1.6.2 2007-12-03
'Openroads'.)
a response to this ongoing issue would be greatly appreciated, as it
is impacting our automated unit tests.
thanks,
andrew yinger
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] server side exception: Can't process XPath expression
Am 24.08.2012 05:01, schrieb Andrew Yinger:
i believe this issue was identified before, but i occasionally see a
server-side exception that starts off like:
errorCode=user.query.invalid message=#exported Sorry, can't access,
query syntax of
XmlBlasterException errorCode=[resource.configuration]
serverSideException=true location=[XmlNotPortable]
message=[#exported Can't process XPath expression .
it was first suggested that this was a parsing issue -- a possible xml
parser library conflict. (i have verified that i do *not* have any
extraneous xml parsing libs in my 'java\lib\endorsed' directory.)
later, a user noticed that a similar error was happening during unit
testing, and that it was a bug on the server:
The issues are:
1. The null check (method_newXPath == null) is outside the
synchronization block. Thread A and thread B could both pass through
the null check at the same time. Thread A will create the xpath
objects while B waits. Then thread B will go through and recreate
xpath objects while A is using them.
2. XPathFactory is, in general, not thread-safe (see
http://java.sun.com/javase/6/docs/api/javax/xml/xpath/XPathFactory.html),
and a method on that object is invoked outside the synchro block.
In the current code it looks like this:
Object xpath = null;
synchronized(XmlNotPortable.class) {
if (method_newXPath == null) {
clazz_XPathFactory =
java.lang.Class.forName(javax.xml.xpath.XPathFactory);
Class[] paramCls = new Class[0];
Object[] params = new Object[0];
java.lang.reflect.Method method = clazz_XPathFactory.getMethod(newInstance,
paramCls);
instance_XPathFactory = method.invoke(clazz_XPathFactory,
params);
method_newXPath = clazz_XPathFactory.getMethod(newXPath,
paramCls);
clazz_XPath =
java.lang.Class.forName(javax.xml.xpath.XPath);
Class clazz_XPathConstants =
java.lang.Class.forName(javax.xml.xpath.XPathConstants);
clazz_QName =
java.lang.Class.forName(javax.xml.namespace.QName);
java.lang.reflect.Field field =
clazz_XPathConstants.getDeclaredField(NODESET);
field_NODESET = field.get(null);
paramCls_StringDocument = new Class[] {
java.lang.String.class,
java.lang.Object.class, //
org.w3c.dom.Document.class,
clazz_QName };
}
xpath = method_newXPath.invoke(instance_XPathFactory, new
Object[0]);
}
so it seems to be correctly synchronized, or do I overlook your issue?
Thank you
Marcel
has this bug been fixed? if so, what version should i be using now?
(i am currently using xmlBlaster version 1.6.2 2007-12-03
'Openroads'.)
a response to this ongoing issue would be greatly appreciated, as it
is impacting our automated unit tests.
thanks,
andrew yinger
Re: [xmlblaster] Problem with broken XMLBlaster connections
Dear David, it seems the client was away some time and the server decided to destroy the session. And this failed to be done properly. When later the session reconnects it enters a stale session. The xmlBlaster you are using is about 5 years old (v1.6.2), is it possible to upgrade to v2.1? In this case you would also need to upgrade java to 1.5 or above (I would recommend the newest v1.7x) I'm on holiday for a week, I hope the issue is not too urgent if you consider to remain with v1.6.2 ... thank you Marcel Am 06.07.2012 21:24, schrieb David R Robison: We have a site that makes a connection to an XMLBlaster. This connection is regularly disconnected due to network issues. After some reconnects, the client successfully reconnects but fails to get any new updates. In the log we see the following error: INFO | jvm 1| 2012/07/06 13:28:36 | 2012-07-06 13:28:36.613 WARNING 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.authentication.SessionInfo timeout: -221-client/tvd-int-02.NovaSTCDataGatewayMcLean/1: Session timeout for tvd-int-02.NovaSTCDataGatewayMcLean occurred, session 'sessionId:10.20.13.132-null-1341589111267-72039212-222' is expired, autologout INFO | jvm 1| 2012/07/06 13:28:36 | 2012-07-06 13:28:36.613 INFO 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.authentication.Authenticate resetSessionInfo: Disconnecting client /node/NovaSTC3/client/tvd-int-02.NovaSTCDataGatewayMcLean/1, instanceId=-221, secretSessionId=sessionId:10.20.13.132-null-1341589111267-72039212-222 INFO | jvm 1| 2012/07/06 13:28:36 | 2012-07-06 13:28:36.613 SEVERE 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.engine.AvailabilityChecker checkException: disconnect() failed: XmlBlasterException serverSideException=true node=[NovaSTC3] location=[210-/node/NovaSTC3/client/tvd-int-02.NovaSTCDataGatewayMcLean] INFO | jvm 1| 2012/07/06 13:28:36 | INFO | jvm 1| 2012/07/06 13:28:36 | stackTrace=errorCode=internal.unknown message=#exported SubjectInfo is shutdown, no logout INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.authentication.SubjectInfo.notifyAboutLogout(SubjectInfo.java:836) INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.authentication.Authenticate.resetSessionInfo(Authenticate.java:738) INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.authentication.Authenticate.disconnect(Authenticate.java:518) INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.authentication.AuthenticateProtector.disconnect(AuthenticateProtector.java:118) INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.authentication.SessionInfo.timeout(SessionInfo.java:442) INFO | jvm 1| 2012/07/06 13:28:36 | at org.xmlBlaster.util.Timeout.run(Timeout.java:189) INFO | jvm 1| 2012/07/06 13:28:36 | versionInfo=version=1.6.2,revision=exported,os.name=Windows 2003,os.version=5.2,java.vm.vendor=Sun Microsystems Inc.,java.vm.version=17.0-b17,os.arch=x86,build.timestamp=12/03/2007 03:42 PM,build.java.vendor=Sun Microsystems Inc.,build.java.version=1.4.2_06 INFO | jvm 1| 2012/07/06 13:28:36 | errorCode description=http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#internal.unknown INFO | jvm 1| 2012/07/06 13:28:36 | INFO | jvm 1| 2012/07/06 13:33:03 | 2012-07-06 13:33:02.946 WARNING 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.authentication.SessionInfo timeout: -218-client/tvd-int-02.NovaSTCDataGatewayMcLean/1: Session timeout for tvd-int-02.NovaSTCDataGatewayMcLean occurred, session 'sessionId:10.20.13.132-null-1341588782823-2119490318-219' is expired, autologout INFO | jvm 1| 2012/07/06 13:33:03 | 2012-07-06 13:33:02.946 WARNING 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.authentication.Authenticate check: SessionId 'sessionId:10.20.13.132-null-1341588782823-2119490318-219' is invalid, no access to xmlBlaster. INFO | jvm 1| 2012/07/06 13:33:03 | 2012-07-06 13:33:02.946 SEVERE 38-XmlBlaster.SessionTimer RL10 org.xmlBlaster.authentication.SessionInfo timeout: -218-client/tvd-int-02.NovaSTCDataGatewayMcLean/1: Internal problem with disconnect: errorCode=user.security.authentication.accessDenied message=#exported Your secretSessionId is invalid, no access to NovaSTC3. Any idea why the client is connected but the server never sends any new updates? Is there anyway to force the connection close? Any thoughts? David -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
[xmlblaster] [xmlblaster-devel] ANNOUNCE xmlBlaster release 2.1.0
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 2.1.0 'Premium'. We have added many subtle improvements, this release is considered mature and stable! This release needs JDK 1.5 or higher. For more details please visit http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES http://www.xmlblaster.org/xmlBlaster/CHANGES enjoy, the xmlBlaster maintainers
[xmlblaster] Re: Http Applet Client
Hi Gregory, the J2ME client inside xmlBlaster is not used anymore, probably you can reactivate it, but you need at least to separately download WTK from java.sun.com and probably proguard for obfuscation. We provide a prefessional commercial J2ME library for xmlBlaster which supports all important features like client side queueing, high compression, reconnect polling etc. If you have interest for this please contace us directly. The Applet: It seems that xmlBlaster client library is not added to the war, we need to investigate this - seems to get lost during build_war ... regards Marcel Gregory Hamel schrieb: Sorry posted earlier before finishing my thoughts. Second problem is that if I try to build the javaMe client using xmlblaster/build j2me I get various compiler exceptions which look like missing jars for the wireless toolkit. Seems reasonable since I haven't setup any paths for this; I'm wondering if there is any additional doc that I'm missing to get these samples up and running? Environment is Windows, current Ant, JDK 1.6.0_20, Firefox 3.6.4. Thx, On Sun, Aug 1, 2010 at 2:45 PM, Gregory Hamel g...@itactual.com.my mailto:g...@itactual.com.my wrote: Hi I'm new to xmlBlaster and have been working through the 2.0.0 release instructions for the http applet client and the j2me client, however I'm having trouble with both.. After doing xmlblaster/build all and xmlblaster/build -DTOMCAT_HOME=path.. deploy_war i see the webapp deployed to my webserver. After starting a blaster and a system info publisher per the instructions I find that the applet itself throws a class not found exception on org/utils/xmlBlaster/Base64. If I try to build the ja -- Gregory Hamel Chief Technology Officer IT Actual Sdn. Bhd Unit 3, Level 5, Block C Mines Waterfront Business Park 3 Jalan Tasik, The Mines Resort City, 43300 Seri Kembangan Selangor, Malaysia -- Gregory Hamel Chief Technology Officer IT Actual Sdn. Bhd Unit 3, Level 5, Block C Mines Waterfront Business Park 3 Jalan Tasik, The Mines Resort City, 43300 Seri Kembangan Selangor, Malaysia -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Re: Http Applet Client
Hi Gregory, the online demo runs fine: http://www.xmlblaster.org:8080/xmlBlaster/HelloWorld3.html I have just tried the current xmlBlaster svn: ~/xmlBlaster build deploy_war http://localhost:8080/xmlBlaster/HelloWorld3.html but the connect to xmlBlaster hangs, I couldn't find the Java console for my Firefox 3.6.2, (https://addons.mozilla.org/de/firefox/addon/141/) so I didn't investigate further. Is there any Applet expert out there to shed some light on this? I have the impression that applets are not in use this much anymore since Javascript-Ajax, Flash or Webstart can do everything as well. Thanks Marcel Gregory Hamel schrieb: Thx for the reply Marcel. We're proofing a distributed app platform and I'm looking to integrate xmlBlaster as a lightweight MOM.. If our POC works alright we'd like to be able to do funding demos using 3-4 simultaneous mobile clients; can you ballpark pricing of the J2ME client for commercial OEM use and for limited demo use? Regarding the Applet client I'll try stuffing the jar inside the war, but what I really need are xmlBlaster clients for javaFx desktop, web, and mobile profiles. If the Applet client uses Java networking it can probably just be integrated as a background thread any synchronized with the 'fx UI thread but it would be nice to have a cross-profile xmlBlaster 'fx client.. Do you happen to know if there is any work going on that area? Regards, On Mon, Aug 2, 2010 at 4:05 PM, Marcel Ruff m...@marcelruff.info mailto:m...@marcelruff.info wrote: Hi Gregory, the J2ME client inside xmlBlaster is not used anymore, probably you can reactivate it, but you need at least to separately download WTK from java.sun.com http://java.sun.com and probably proguard for obfuscation. We provide a prefessional commercial J2ME library for xmlBlaster which supports all important features like client side queueing, high compression, reconnect polling etc. If you have interest for this please contace us directly. The Applet: It seems that xmlBlaster client library is not added to the war, we need to investigate this - seems to get lost during build_war ... regards Marcel Gregory Hamel schrieb: Sorry posted earlier before finishing my thoughts. Second problem is that if I try to build the javaMe client using xmlblaster/build j2me I get various compiler exceptions which look like missing jars for the wireless toolkit. Seems reasonable since I haven't setup any paths for this; I'm wondering if there is any additional doc that I'm missing to get these samples up and running? Environment is Windows, current Ant, JDK 1.6.0_20, Firefox 3.6.4. Thx, On Sun, Aug 1, 2010 at 2:45 PM, Gregory Hamel g...@itactual.com.my mailto:g...@itactual.com.my mailto:g...@itactual.com.my mailto:g...@itactual.com.my wrote: Hi I'm new to xmlBlaster and have been working through the 2.0.0 release instructions for the http applet client and the j2me client, however I'm having trouble with both.. After doing xmlblaster/build all and xmlblaster/build -DTOMCAT_HOME=path.. deploy_war i see the webapp deployed to my webserver. After starting a blaster and a system info publisher per the instructions I find that the applet itself throws a class not found exception on org/utils/xmlBlaster/Base64. If I try to build the ja -- Gregory Hamel Chief Technology Officer IT Actual Sdn. Bhd Unit 3, Level 5, Block C Mines Waterfront Business Park 3 Jalan Tasik, The Mines Resort City, 43300 Seri Kembangan Selangor, Malaysia -- Gregory Hamel Chief Technology Officer IT Actual Sdn. Bhd Unit 3, Level 5, Block C Mines Waterfront Business Park 3 Jalan Tasik, The Mines Resort City, 43300 Seri Kembangan Selangor, Malaysia -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371 -- Gregory Hamel Chief Technology Officer IT Actual Sdn. Bhd Unit 3, Level 5, Block C Mines Waterfront Business Park 3 Jalan Tasik, The Mines Resort City, 43300 Seri Kembangan Selangor, Malaysia -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] is there an example showing how to send an XML document via pub/sub system?
Gautam Thaker schrieb:
Marcel Ruff wrote:
Hi Gautam,
an XML is a byte[]. If you do a
byte[] bytes = ...
try {
String xml = new String(bytes, UTF-8);
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
you have assumed it is UTF-8 encoded (which is the xml default and is
advisable).
But usually you shouldn't do that.
If you use a xml parser for the XML InputStream (from byte[])
it correctly detects the encoding of the xml by looking at the XML
header
?xml version=1.0 encoding=UTF-8?
To summarize: A byte[] is a perfect transport medium for xml,
Hi Marcel:
Many thanks for this clarification. Makes sense. However, this brings
me to another (possibly very naive) question. *IF* one is passing
around byte [] as message contents, what would be criteria that might
make one decide if the protocol to be used should be socket, or
xmlrpc, or CORBA, or RMI? Are firewall/security considerations the
primary drivers or is it something else?
The protocol choosen is independend of the message content.
Just use SOCKET (with or without SSL) all the time.
In some cases, you may want to choose XML-RPC because of firewall issues.
If you want to integrate a client written in another language (like Ada,
Ruby) you can choose the protocol
which is most easy to implement for your client,
Marcel
Thanks.
Gautam
Marcel
Gautam Thaker schrieb:
Hi:
I am learning more about xmlBlaster by trying various demo programs
and running small variations there off. I have run most of the
HelloWorldx.java pgms and a few others. What I have found so far
is that in all cases the content of the user information being sent
is a byte array. The key and qos info are in XML, but the user
payload is byte array. What I wish to do is to have my payload be a
large XML document. (The receiver would have a schema against which
it may check for validity before accepting/processing the message.)
Is there an example that shows how this is done? Or is it that in
all cases the message content is byte array and all XML documents
are simply byte arrays any way? (I am not an XML guru myself, sorry
if this is a naive question over all.)
Gautam
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] setPersistent() on DOMAIN and XPATH
Hi Sanjeev, thank you for reporting, it looks like a bug. I'll come back on it as soon as we have analyzed the problem, Marcel Sanjeev Dhiman schrieb: Hi, While working on XMLBlaster as a client, when I get subscribed on a server on a specific DOMAIN (and not on XPATH) and call setPersistent(true) I get following error and my subscription gets failed. Subscribing on XPATH works 100% fine. Any help is highly appreciated. subscribe key : key domain='AK-511' queryType='DOMAIN'/ subscribe QoS : qos persistent/ isSubscribe/ /qos 17:48:01,463 ERROR MyListener:86 - DIT_XMLBLASTER_EXCEPTION[problem in subscribing...] errorCode=internal.unknown message=#exported errorCode=internal.subscribe: An internal error occurred when processing a subscribe() request. : java.lang.ClassCastException: org.xmlBlaster.util.key.MsgKeyData cannot be cast to org.xmlBlaster.util.key.QueryKeyData at org.xmlBlaster.util.XmlBlasterException.parseByteArr(XmlBlasterException .java:706) at org.xmlBlaster.util.xbformat.MsgInfo.getException(MsgInfo.java:608) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestRe plyExecutor.java:613) at org.xmlBlaster.client.protocol.socket.SocketCallbackImpl.run(SocketCallb ackImpl.java:351) at java.lang.Thread.run(Thread.java:619) Jan 6, 2010 5:48:01 PM org.xmlBlaster.client.XmlBlasterAccess connect INFO: 1.6.4 #exported: Successful SOCKET login as /node/xmlBlaster_127_0_0_1_3412/client/engine7/1 ConnectReturn Qos : qos securityService type=htpasswd version=1.0![CDATA[ userengine7/user passwdsecret/passwd ]]/securityService instanceId/xmlBlaster/node/xmlBlaster_127_0_0_1_3412/instanceId/126270 7403774/instanceId session name='/node/xmlBlaster_127_0_0_1_3412/client/engine7/1' timeout='8640' maxSessions='10' clearSessions='false' reconnectSameClientOnly='false' sessionId='sessionId:127.0.0.1-null-1262780265646-262620263-69'/ queue relating='connection' type='RAM' version='1.0' maxEntries='1000' maxEntriesCache='1000' address type='SOCKET' dispatchPlugin='undef' socket://169.130.94.125:7610 /address /queue queue relating='subject' type='RAM' version='1.0'/ queue relating='callback' type='RAM' version='1.0' maxEntries='1000' maxEntriesCache='1000' maxBytes='4147483647' maxBytesCache='200555666' callback type='SOCKET' retries='-1' delay='6' dispatchPlugin='undef' socket://172.16.8.35:3446 attribute name='__ContextNode' type='String'/xmlBlaster/node/xmlBlaster_127_0_0_1_3412/client/engine7/ session/1/attribute /callback /queue clientProperty name='__UTC'2010-01-06 12:17:45.431Z/clientProperty clientProperty name='__rcvTimestampStr'2010-01-06 12:17:45.648Z/clientProperty /qos -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] RE: [xmlblaster] Mirrored Masters?
Craig McIlwee schrieb: Thanks Marcel. What we are looking for is nowhere near as elegant of a solution as you've outlined below. Quoting the same page as David, we are most interested in Messages which are published are sent to all masters. Because we really just want a second master node that stays in sync with the primary master. In our scenario we don't need any type of smart failover or load balancing, we want to make sure that 2 nodes are receiving and persisting the same information. In normal usage, the primary node will always receive messages. In a catastrophic situation where the primary node fails (hardware error, etc) we need to be able to switch to the secondary node that should be in sync with the primary, and manual reconfiguration is acceptable. So from your mail below, I take it that persisting at 2 nodes is not implemented yet? No this is not implemented. If not, it sounds like you recommend mirroring at the database level? Yes. And I would recommend to go from the beginning the Linux HA (bonding,DRDB,Heartbeat etc, HP-ServiceGuard ...) way, as all the failover problems will arise over time anyhow, so I suggest doing it right from beginning. regards Marcel Thanks, Craig -Original Message- From: owner-xmlblas...@server.xmlblaster.org [mailto:owner-xmlblas...@server.xmlblaster.org] On Behalf Of Marcel Ruff Sent: Tuesday, December 08, 2009 4:41 AM To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] Mirrored Masters? Hi David, multi master is not implemented. The I_LoadBalancer#getClusterNode() returns one node (NodeMasterInfo) which is used to forward messages to the next node, but only to one. If you need mirroring you could, depending if you need failover or load balancing, consider following: 1) Change the xmlBlaster cluster code to handle multiple masters You need to decide in this case if the multiple masters are informed in a transaction (sync) or not (async). Clients need to be coded to choose a master depending on current load or failure. - failover and load balancing 2) You could create an extended I_Queue and I_Map plugin which duplicates the data to two DBs - failover 3) You could do low-level DB mirroring (DRDB, Linux HA et al) xmlBlaster gets on startup all information to re-establish its state. In this case the mirrored xmlBlaster is started on failure of the first, clients automatically find the mirrored as the IP is change (standard HA behaviour) - failover 4) Master/Slave operation (exists already, one master with many salves) - load balancing 5) Combination of 3) and 4) should work out of the box - failover and load balancing It depends on what you want to achieve, best regards Michele Marcel David R Robison schrieb: In the discussion on clustering in the reference manual it talks about mirrored masters: /An xmlBlaster cluster allows to have more than one master server for a specific message domain. The master nodes are //mirrored instances for those messages. Published messages reach all master nodes. Subscribed messages are retrieved using a load balance algorithm. / However, the discussion says that it has not been implemented. Has any work been done on this? Any suggestions on how to achieve this? Thanks, David -- Marcel Ruff http://www.xmlBlaster.org http://gpsvision.biz
Re: [xmlblaster] License of demo code
Adam Tauno Williams schrieb: I see that xmlBlaster's root directory has a file stating the code is under LGPL2.1. The code under demo/, particularly demo/csharp/xmlrpc/src/XmlBlasterLib/, doesn't contain any explicit license statements. Is this code also under LGPL2.1? Yes, also LGPL, best regards Marcel I'd like to build a .Net (Mono) application using xmlBlaster and the XmlBlasterLib seems like an interesting code base to start with for the xmlBlaster connectivity piece. If it is under LGPL then I'm fine to consume that code as the application would eventually be itself released under LGPL2.1 -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
[xmlblaster] Re: There is Memory leak on xmlblaster serverside?
Hi,
is your topic 'lpszKey,' changing for each publish?
If yes, a new topic is created for each message
and not destoyed as xmlBlaster keeps the message
in the history queue (max 10 as default).
To avoid this switch off the history queue
or use messages with expire or erase the topic
actively.
Or better: Use the same topic for all messages
if your use case allows it.
best regards
Marcel
DuXiPeng(杜希鹏) wrote:
Error happens when I send a lot of volatile message to xmlblaster(1.6.2
vision). The publisher send volatile messages (1k per second)and the
Subscriber received it. The memory’s consuming on serverside is
increasing constantly. Why is not the memory release?
thanks
my publish code
bool Publish(LPCTSTR lpszKey, LPBYTE pContent, int nSize, int optional,
LPCTSTR lpszTarget)
{
PublishKey key(global_, string(lpszKey), text/xml, 1.0);
string clientTags;
clientTags = test Flag=”123”/ test
key.setClientTags(clientTags);
if (domain != )
key.setDomain(domain);
PublishQos pq(global_);
pq.setPriority(MAX_PRIORITY);
if (optional MSG_VOLATILE)// volatile
{
pq.setVolatile(true);
//pq.setLifeTime(lifeTime);
pq.setForceDestroy(true);
}
Else //non- volatile
{
pq.setLifeTime(-1);
}
if (optional MSG_PERSISTENT)
pq.setPersistent(true);
pq.setForceUpdate(forceUpdate);
pq.setSubscribable(subscribable);
TopicProperty topicProperty(global_);
topicProperty.setDestroyDelay(0);
topicProperty.setCreateDomEntry(false);
if (historyMaxMsg = 0L)
{
HistoryQueueProperty prop(global_, );
prop.setMaxEntries(historyMaxMsg);
prop.setMaxEntriesCache(historyMaxEntriesCache);
prop.setMaxBytesCache(historyMaxBytesCache);
prop.setMaxBytes(historyMaxBytes);
prop.setExpires(historyExpiresTimes);
topicProperty.setHistoryQueueProperty(prop);
}
pq.setTopicProperty(topicProperty);
if (lpszTarget != NULL)
{
pq.setSubscribable(false);
SessionName sessionName(global_, lpszTarget);
Destination dest(global_, sessionName);
dest.forceQueuing(forceQueuing);
pq.addDestination(dest);
}
stringstream sout;
std::vector unsigned char contentVec;
for (int i = 0 ;i nSize; i++)
contentVec.push_back(*(pContent + i));
MessageUnit msgUnit(key, contentVec, pq);
bool bSucceeded = false;
if (oneway)
{
//log_.trace(ME, string(publishOneway() message unit: ) +
msgUnit.toXml());
vectorMessageUnit msgUnitArr;
msgUnitArr.push_back(msgUnit);
try
{
connection_.publishOneway(msgUnitArr);
log_.trace(ME, publishOneway() done);
bSucceeded = true;
}
catch (XmlBlasterException e)
{
lastError = publishOneway failed. Error info: + e.toXml();
log_.error(ME, lastError);
}
}
else
{
//log_.trace(ME, string(publish() message unit: ) +
msgUnit.toXml());
for (int i = 0; i publishRetryCount + 1; i++)
{
try
{
PublishReturnQos tmp = connection_.publish(msgUnit);
log_.trace(ME, string(publish return qos: ) + tmp.toXml());
bSucceeded = true;
break;
}
catch (XmlBlasterException e)
{
lastError = publish failed. Error info: + e.toXml();
log_.error(ME, lastError);
}
}
}
contentVec.clear();
return bSucceeded;
}
[xmlblaster] Dropping Java 1.5 support?
Hi all, dropping JDK 1.4 for coming xmlBlaster v2.0 is decided. What about jumping directly to JDK 1.6? Does anybody need JDK1.5 in his project? thank you Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Dropping Java 1.5 support?
Ok, xmlBlaster 2.0 will be JDK 1.5 compatibel, best regards Marcel Clark, Jonathan schrieb: Marcel, Open Roads is still using JDK1.5 on a number of projects that use xmlBlaster. Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 This e-mail communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. If you are not the intended recipient, you should immediately stop reading this message and delete it from all computers that it resides on. Any unauthorized reading, distribution, copying or other use of this communication (or its attachments) is strictly prohibited. If you have received this communication in error, please notify us immediately. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcel Ruff Sent: Friday, November 21, 2008 8:12 AM To: xmlblaster@server.xmlBlaster.org Subject: [xmlblaster] Dropping Java 1.5 support? Hi all, dropping JDK 1.4 for coming xmlBlaster v2.0 is decided. What about jumping directly to JDK 1.6? Does anybody need JDK1.5 in his project? thank you Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
[xmlblaster] ANNOUNCE xmlBlaster release 1.6.4
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 1.6.4. It is a bug fix release and contains many extensions, so we recommend you to upgrade. It is released after massive testing (Java/C/C++) and a lot of feed back of our partners and users. The most remarkable extensions are: o Mature and outstanding database replication, beating smilingly other *very* expensive offerings under most unbelievable operating environments o Cluster callback tunneling with SSL for high secure inter-company communication o MacOSX and iPhone client ports to crown the extensive mobile support o Extensive administrative control during operation and legal recording of message flow This is the last release supporting JDK 1.4 For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES enjoy, the xmlBlaster maintainers
Re: [xmlblaster] locking bug
Issue resolved?
Marcel Ruff schrieb:
Póka Balázs schrieb:
Hi there,
Just a thought: what if you modified SessionInfo.timeout(Object) like
this:
public final void timeout(Object userData) {
synchronized (this.EXPIRY_TIMER_MONITOR) {
this.timerKey = null;
log.warning(ME+: Session timeout for + getLoginName() +
occurred, session ' + getSecretSessionId() + ' is expired,
autologout);
}
DisconnectQosServer qos = new DisconnectQosServer(glob);
qos.deleteSubjectQueue(true);
try {
glob.getAuthenticate().disconnect(getAddressServer(),
getSecretSessionId(), qos.toXml());
} catch (XmlBlasterException e) {
log.severe(ME+: Internal problem with disconnect: +
e.toString());
}
}
It seems as if timerKey is protected by EXPIRY_TIMER_MONITOR
elsewhere, but not here (this might be an error). I simply removed
the locking of lock from the method. Does this make it
thread-unsafe? :)
No, i think the original sync did not make sense,
as the disconnect (coming here from a timeout thread)
can also come from a remote client which disconnects at any time,
so the core must be capable to handle this situation anyhow.
I have removed the sync here and also in shutdown() to prevent the
deadlock.
The current code is now committed to svn.
thanks again
Marcel
regards,
Balázs
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] Support for publishOneway in PtP, xmlrpc3
Póka Balázs schrieb: Hi all! I've had an interesting day debugging and looking into XmlBlaster, partly because I'm finally overhauling my XmlRpc3 driver (using apache commons). (That's the one which I promised to make available for inclusion in the library...) Use case is as follows: client1 sends PtP messages to client2 using updateOneway(). I noticed the following: I_CallbackDriver.sendUpdateOneway(MsgUnitRaw[] msgArr) got never called in the server. Instead, all updates were done using I_CallbackDriver.sendUpdate(MsgUnitRaw[] msgArr). Which was kind of a performance problem, and I'm using updateOneway because I don't need full update functionality. I've also successfully located the problem. The server gets called at org.xmlblaster.engine.XmlBlasterImpl.publishOneway(...), which is good, but it lost the onewayness property (actually MethodName) of the message and subsequently sent it to the client as if it was a normal update. I also made a small patch which eliminated the problem for me, so now it works as I expected. Please review it. Great,please commit it to xmlBaster. Note to Marcel: I've found a 10 month old mail of you offering SVN access to add my XmlRpc3 protocol impl. I could actually add it and rename the packages and/or classes to some standard name, replace java.util.concurrent packages with the backport, but I don't really have time for much more. It's working for me and some of my company's clients, but there are hackish parts and occassonally it may do unexpected things. So it would need a review. I don't feel comfortable just adding it. :) There's also some code duplication from the old impl, and possibly classpath incompatibilities with the old xmlrpc2 library (so that may have to go). I would suggest you commit it to xmlBlaster. The open details we will figure out thereafter. I believe xmlBlaster/src/java/org/xmlBlaster/protocol/xmlrpc3 (server side) and xmlBlaster/src/java/org/xmlBlaster/client/protocol/xmlrpc3 (client side) is a good place to go. For my part we can drop java 1.4 support in xmlBlaster so you could keep the original concurrent packages, i'll ask in the mailing list separately about this. Thank you Marcel Thanks for your support! regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
[xmlblaster] Dropping Java 1.4 support?
Hi all, i think it is time to drop Java 1.4 support for xmlBlaster and start coding with JDK 1.5 - 1.7. I'm interested about your opinion about this, thank you Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] locking bug
Hi again, i think our mails crossed, I came to the same result. I hope i find a solution for this as one session can be in touch with many topics and vice versa ... Marcel Póka Balázs schrieb: Hi, The previous mail was missing the thread which was locking the instance of org.xmlBlaster.engine.SessionInfo.lock, so here it is: 2008-10-28 12:32:27,613 ERROR [XmlBlaster.SessionTimer] (DebugReentrantLock.java:51) - failed to lock() at java.lang.Exception at org.xmlBlaster.debug.DebugReentrantLock.tryLock(DebugReentrantLock.java:51) at org.xmlBlaster.engine.TopicAccessor$TopicContainer.lock(TopicAccessor.java:416) at org.xmlBlaster.engine.TopicAccessor.access(TopicAccessor.java:93) at org.xmlBlaster.engine.MsgUnitWrapper.toDestroyed(MsgUnitWrapper.java:595) at org.xmlBlaster.engine.MsgUnitWrapper.incrementReferenceCounter(MsgUnitWrapper.java:279) at org.xmlBlaster.engine.queuemsg.ReferenceEntry.incrementReferenceCounter(ReferenceEntry.java:191) at org.xmlBlaster.engine.queuemsg.ReferenceEntry.removed(ReferenceEntry.java:230) at org.xmlBlaster.util.queue.ram.RamQueuePlugin.clear(RamQueuePlugin.java:241) at org.xmlBlaster.authentication.Authenticate.resetSessionInfo(Authenticate.java:806) at org.xmlBlaster.authentication.Authenticate.disconnect(Authenticate.java:557) at org.xmlBlaster.authentication.AuthenticateProtector.disconnect(AuthenticateProtector.java:119) at org.xmlBlaster.authentication.SessionInfo.timeout(SessionInfo.java:462) at org.xmlBlaster.util.Timeout.run(Timeout.java:190) That in turn means that the cause is probably: 1) org.xmlBlaster.engine.SessionInfo.lock locked at org.xmlBlaster.authentication.SessionInfo.timeout(SessionInfo.java:462) trying to lock org.xmlBlaster.authentication.TopicAccessor.TopicContainer.lock; 2) org.xmlBlaster.authentication.TopicAccessor.TopicContainer.lock locked at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1679) trying to lock org.xmlBlaster.engine.SessionInfo.lock at org.xmlBlaster.engine.TopicHandler.forwardToDestinations(TopicHandler.java:844). regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] locking bug
) at org.xmlBlaster.engine.XmlBlasterImpl.publish(XmlBlasterImpl.java:180) at org.xmlBlaster.engine.XmlBlasterImpl.publishArr(XmlBlasterImpl.java:219) at org.xmlBlaster.engine.XmlBlasterImpl.publishOneway(XmlBlasterImpl.java:233) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:441) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:194) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:369) 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(Thread.java:619) 2008-10-28 12:32:27,414 ERROR [XmlBlaster.DispatchWorkerPool.nova-226] (DebugReentrantLock.java:51) - failed to lock() at org.xmlBlaster.debug.DebugReentrantLock.tryLock(DebugReentrantLock.java:51) at org.xmlBlaster.engine.TopicAccessor$TopicContainer.lock(TopicAccessor.java:416) at org.xmlBlaster.engine.TopicAccessor.access(TopicAccessor.java:93) at org.xmlBlaster.engine.MsgUnitWrapper.toDestroyed(MsgUnitWrapper.java:595) at org.xmlBlaster.engine.MsgUnitWrapper.incrementReferenceCounter(MsgUnitWrapper.java:279) at org.xmlBlaster.engine.queuemsg.ReferenceEntry.incrementReferenceCounter(ReferenceEntry.java:191) at org.xmlBlaster.engine.queuemsg.ReferenceEntry.removed(ReferenceEntry.java:230) at org.xmlBlaster.util.queue.ram.RamQueuePlugin.removeRandom(RamQueuePlugin.java:543) at org.xmlBlaster.util.dispatch.DispatchManager.removeFromQueue(DispatchManager.java:519) at org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:123) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:732) at java.lang.Thread.run(Thread.java:619) Explanation: The first stacktrace is the current state of the thread which was the last to successfully acquire the lock. The second stacktrace is from the same thread as the first, but it reflects the state when the last locking was successfully acquired. The third stacktrace is the stack of the thread which timed out while trying to acquire the lock. To conclude, the deadlock is between two instances of the following locks: 1) org.xmlBlaster.engine.SessionInfo.lock 2) org.xmlBlaster.authentication.TopicAccessor.TopicContainer.lock I'm trying to decipher the exact cause and if it can be circumvented, but I think it's better if you looked into it since this may require more in-depth knowledge of the inner workings of the server. Hoping to hear from you soon! regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] locking bug
Póka Balázs schrieb:
Hi there,
Just a thought: what if you modified SessionInfo.timeout(Object) like
this:
public final void timeout(Object userData) {
synchronized (this.EXPIRY_TIMER_MONITOR) {
this.timerKey = null;
log.warning(ME+: Session timeout for + getLoginName() +
occurred, session ' + getSecretSessionId() + ' is expired, autologout);
}
DisconnectQosServer qos = new DisconnectQosServer(glob);
qos.deleteSubjectQueue(true);
try {
glob.getAuthenticate().disconnect(getAddressServer(),
getSecretSessionId(), qos.toXml());
} catch (XmlBlasterException e) {
log.severe(ME+: Internal problem with disconnect: +
e.toString());
}
}
It seems as if timerKey is protected by EXPIRY_TIMER_MONITOR
elsewhere, but not here (this might be an error). I simply removed the
locking of lock from the method. Does this make it
thread-unsafe? :)
No, i think the original sync did not make sense,
as the disconnect (coming here from a timeout thread)
can also come from a remote client which disconnects at any time,
so the core must be capable to handle this situation anyhow.
I have removed the sync here and also in shutdown() to prevent the deadlock.
The current code is now committed to svn.
thanks again
Marcel
regards,
Balázs
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] locking bug
Hi Póka ,
nice approach!
Please report what you find out,
thanks
Marcel
Póka Balázs schrieb:
Hi Marcel,
I have modified the TopicContainer class as follows (in order to help
me track down the problem):
private final class TopicContainer {
private volatile TopicHandler topicHandler;
private final boolean fairness = false;
private final ReentrantLock lock = new DebugReentrantLock(fairness);
public TopicContainer(TopicHandler topicHandler) {
this.topicHandler = topicHandler;
}
public TopicHandler getTopicHandler() {
return this.topicHandler;
}
public void erase() {
if (!this.lock.isHeldByCurrentThread())
throw new IllegalStateException(must be locked before
erased);
if (this.topicHandler == null)
return;
synchronized (this.lock) {
this.topicHandler = null;
int c = this.lock.getHoldCount();
for (int i = 0; i c; i++)
this.lock.unlock();
if (this.lock.isLocked()) log.severe(Must be unlocked!);
}
}
public TopicHandler lock() {
// topicHandler already erased
if (this.topicHandler == null)
return null;
try {
this.lock.tryLock(60, TimeUnit.SECONDS);
} catch (InterruptedException e) {
throw new RuntimeException(Interrupted while locking, e);
}
// topicHandler might have been erased while locking
TopicHandler th = this.topicHandler;
if (th == null) {
this.lock.unlock();
return null;
}
return th;
}
public void unlock() {
synchronized (this.lock) {
if (this.lock.getHoldCount() 0) // returns 0 if we are
not the
// holder
this.lock.unlock(); // IllegalMonitorStateException if our
// thread is not the holder of the lock,
// never happens because of above if()
}
}
} // class TopicContainer
There are some additional checks as you can see. Additionally, I'm
using tryLock with a timeout of one minute. I also extended
ReentrantLock as DebugReentrantLock which saves the last stacktraces
of the thread which aquired the lock:
public class DebugReentrantLock extends ReentrantLock {
private static final Logger
logger=Logger.getLogger(DebugReentrantLock);
private ArrayList holderTrace=new ArrayList();
public DebugReentrantLock() {
}
public DebugReentrantLock(boolean fair) {
super(fair);
}
public boolean tryLock() {
boolean ret=super.tryLock();
synchronized(this) {
if (ret) {
if (getHoldCount()==1) holderTrace.clear();
holderTrace.add(new Exception());
}
return ret;
}
}
public boolean tryLock(long timeout, TimeUnit unit) throws
InterruptedException {
boolean ret=super.tryLock(timeout, unit);
synchronized(this) {
if (ret) {
if (getHoldCount()==1) holderTrace.clear();
holderTrace.add(new Exception());
}
else {
Thread owner=getOwner();
Exception ownerE=new Exception();
ownerE.setStackTrace(owner.getStackTrace());
logger.log(Level.SEVERE, trylock failed, locked by, ownerE);
Iterator i=holderTrace.iterator();
while (i.hasNext()) {
logger.log(Level.SEVERE, lock() called at,
(Exception)i.next());
}
logger.log(Level.SEVERE, failed to lock() at, new
Exception());
}
return ret;
}
}
public void lock() {
super.lock();
synchronized(this) {
if (getHoldCount()==1) holderTrace.clear();
holderTrace.add(new Exception());
}
}
public void lockInterruptibly() throws InterruptedException {
super.lockInterruptibly();
synchronized(this) {
if (getHoldCount()==1) holderTrace.clear();
holderTrace.add(new Exception());
}
}
}
I hope this will yield some results, I'm trying to stress test the
server now. Unfortunately this bug only occurred on the production
server so far.
Feel free to tell me any idea you might have. :)
regards,
Balázs Póka
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] locking bug
Hi, i have looked at your thread dump, but i couldn't come to a conclusion, it is not possible to see the lock-taking thread ... Could you please send me the logfiles as well, during the time the threads are consumed (probably with -logging/org.xmlBlaster.engine FINE but this will blow up your files). Could you please add in TopicAccessor.java:376 the keyword 'volatile': private volatile TopicHandler topicHandler; It is just i very blind guess. Can you make a grep in your log files on the line log.warning(Trying again to get a TopicHandler ... if it is logged somewhere. Is it always the same topicId which fails? Do you have many other topics witch work fine? Thanks Marcel Marcel Ruff schrieb: Póka Balázs schrieb: Hello to all XmlBlaster developers! I may have discovered a locking problem in org.xmlblaster.engine.TopicAccessor. The symptom is xmlBlaster running out of memory. I made a stack dump the last time when this happened (and it happens a lot), and there were innumerable threads stuck here: XmlBlaster.HandleClient prio=10 tid=0x2aaac12ce800 nid=0xf62 in Object.wait() [0x2aaae417e000..0x2aaae417eca0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:199) - locked 0x2aaab42ec888 (a edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync) at edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:481) at org.xmlBlaster.engine.TopicAccessor$TopicContainer.lock(TopicAccessor.java:403) at org.xmlBlaster.engine.TopicAccessor.findOrCreate(TopicAccessor.java:179) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1677) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1405) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1393) at org.xmlBlaster.engine.XmlBlasterImpl.publish(XmlBlasterImpl.java:180) at org.xmlBlaster.engine.XmlBlasterImpl.publishArr(XmlBlasterImpl.java:219) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:447) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:194) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:369) 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(Thread.java:619) There was no deadlock. It seems that some thread locked the ReentrantLock instance contained in org.xmlblaster.engine.TopicAccessor$TopicContainer, and forgot to unlock it. The clients subsequently disconnected and reconnected to another session id since from their point of view, the server did not respond, thus the huge number of stale threads and clients resulted. I noted that the implementation of org.xmlblaster.engine.TopicAccessor.release(...) seems problematic since it may return _without unlocking_ under erroneous conditions, while not even logging any INFO or higher level message! Maybe the tc.unlock() call would need to be placed in a finally block. There may as well be other places which may hold instances of this lock without unlocking it ever again. If the map throws a Runtime exception, yes. But this should be logged somewhere up the stack. Could you please send us the complete stack trace? Since when did you notice this behaviour? Which version of xmlBlaster do you use? Thanks Marcel Thanks for your help. regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] locking bug
Póka Balázs schrieb: Hello to all XmlBlaster developers! I may have discovered a locking problem in org.xmlblaster.engine.TopicAccessor. The symptom is xmlBlaster running out of memory. I made a stack dump the last time when this happened (and it happens a lot), and there were innumerable threads stuck here: XmlBlaster.HandleClient prio=10 tid=0x2aaac12ce800 nid=0xf62 in Object.wait() [0x2aaae417e000..0x2aaae417eca0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:199) - locked 0x2aaab42ec888 (a edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync) at edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:481) at org.xmlBlaster.engine.TopicAccessor$TopicContainer.lock(TopicAccessor.java:403) at org.xmlBlaster.engine.TopicAccessor.findOrCreate(TopicAccessor.java:179) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1677) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1405) at org.xmlBlaster.engine.RequestBroker.publish(RequestBroker.java:1393) at org.xmlBlaster.engine.XmlBlasterImpl.publish(XmlBlasterImpl.java:180) at org.xmlBlaster.engine.XmlBlasterImpl.publishArr(XmlBlasterImpl.java:219) at org.xmlBlaster.util.protocol.RequestReplyExecutor.receiveReply(RequestReplyExecutor.java:447) at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(HandleClient.java:194) at org.xmlBlaster.protocol.socket.HandleClient$1.run(HandleClient.java:369) 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(Thread.java:619) There was no deadlock. It seems that some thread locked the ReentrantLock instance contained in org.xmlblaster.engine.TopicAccessor$TopicContainer, and forgot to unlock it. The clients subsequently disconnected and reconnected to another session id since from their point of view, the server did not respond, thus the huge number of stale threads and clients resulted. I noted that the implementation of org.xmlblaster.engine.TopicAccessor.release(...) seems problematic since it may return _without unlocking_ under erroneous conditions, while not even logging any INFO or higher level message! Maybe the tc.unlock() call would need to be placed in a finally block. There may as well be other places which may hold instances of this lock without unlocking it ever again. If the map throws a Runtime exception, yes. But this should be logged somewhere up the stack. Could you please send us the complete stack trace? Since when did you notice this behaviour? Which version of xmlBlaster do you use? Thanks Marcel Thanks for your help. regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] JDBC
AI wrote: Hi， I try to load jdbc driver (sqlserver oracle) under JDK1.6. Failed. Checked the requirements I found the plugin only tested under 1.5. So any possiblity the probelm is by JDK1.6? Thanks a lot AI Both, SQLServer and Oracle run fine with JDK 1.6 It must be a configuration problem, please check your xmlBlaster.properties Thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] How to persist?
Paul Babyak wrote: Hi Michele. Could you explain a difference between ConnectQos.setPersistent() and PublishQos.setPersistent()? ConnectQos.setPersistent(true): Now your login session is persisted. On xmlBlaster server restart the session is loaded early in Runlevel 2. Like this, for example persistent subscriptions are available and incoming messages where the subscription matches are collected even that the real client has not yet connected. PublishQos.setPersistent(true): The message published will survive any crash/power loss/shutdown of any involved client or server. What happen if i set persistent for PublishQos and do not set for ConnectQos (and vice versa)? They are not directly related, see above, enjoy Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] which JDK is better?
JDK 1.5 and JDK 1.6 are both fine, Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] anything new on the way?
AI wrote: I am studying xmlbalster now. But just found here a little quiet after 2007.Why? something new on the way? Really hope its still healthy,robust and will go on as usual. Just curious. The project is very healthy, is developed actively and used in many commercial applications, regards Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Persistent msg caching without previous connection
Hi, this works out of the box. Type (without a server): java -Dcom.sun.management.jmxremote javaclients.HelloWorldPublish -session.name pubisher/2 -persistent true -numPublish 200 and publish some messages. Now start the server (probably set CheckPoint plugin to 'true' in xmlBlasterPlugins.xml to see message flow) and the messages are published, regards Marcel christian chevalley wrote: Hi Guys, Is it possible to force the caching of persistent messages on the client side without having previously established a connection to a server? I am trying to implement an asynchronous client gathering events which are published to a central server. However, this client might be started before the server (hence the caching), whenever the server is started, the client then connect automatically to the server (no problem here) and the cached messages should be then sent to the server. The problem is that if the client has not already connected to a server, it is not possible to publish messages (exception is: errorCode=user.notConnected). Have I missed something here, since the persistent connection + persistent PublishQos work fine after an initial connection ? Thanks in advance -- Christian -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] import to eclipse
AI wrote: hello, I'm trying to import xmlBlaster to eclipse following the requirement document. Then it returns The project was not built due to This file system is read only: /xmlBlaster/classes.antLink/org.. Fix the problem, then try refreshing this project and building it since it may be inconsistent. The winxp folder read only problem? No, it is our configuration which is buggy. Go to: Project - Right Mouse - Properties There choose Java Build Path and Source At the bottom Default output folder you can now change the above link to a physical directory of your choice, Marcel Thanks AI -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] RMI Problem
Edit: xmlBlaster/src/java/org/xmlBlaster/util/MsgUnitRaw.java
and change to
public final class MsgUnitRaw implements java.io.Serializable
and compile:
cd xmlBlaster
build all
Now it should work fine again
Marcel
Mohannad wrote:
Dear sir,
Thank you all for supporting and helping ,
I faced something a little strange !
I'm trying to run XMLBlaster with RMI, I followed this :
java -Djava.rmi.server.codebase=file:///mr/Desktop/xmlBlaster/classes/ -Djava.security.policy=mr/Desktop/xmlBlaster/config/xmlBlaster.policy
-Djava.rmi.server.hostname=172.16.132.55 http://172.16.132.55
org.xmlBlaster.Main -plugin/rmi/registryPort 2078
and I added the required plugin, but I am not sure what should I
modify in
Djava.rmi.server.codebase=file:///${XMLBLASTER_HOME}/classes/ \
I changed XMLBLASTER_HOME with my XMLBlaster home, but what should I
do for /classes ??
when I run this command
java HelloWorld3 -protocol RMI -plugin/rmi/registryPort 2078
@ client side:
/ this error appeared although I added
ProtocolPlugin[RMI][1.0]=org.xmlBlaster.protocol.rmi.RmiDriver /and
/CbProtocolPlugin[RMI][1.0]=org.xmlBlaster.protocol.rmi.CallbackRmiDriver/
to xmlBlaster.properties
init: XmlBlasterException errorCode=[resource.configuration]
serverSideException=false location=[PluginInfo-ClientProtocolPlugin]
message=[#1.6.2 Plugin 'ClientProtocolPlugin[RMI][1.0]' not found,
please check your configuration : ] [See URL
http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#resource.configuration]
could you help me, or rmi not supported any more ?
regards,
Mohannad
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] Java and C#
Arghad Arnaout wrote: Hi Mohannad .. Here you can find a sample on how to write a client in csharp ... http://www.xmlblaster.com/xmlBlaster/doc/requirements/client.csharp.html You can start from the code here: http://www.xmlblaster.org/xmlBlaster/src/csharp/Hello.cs.html This Hello.cs uses the SOCKET protocol, so no XMLRPC is needed in this case. But the C# client uses a C DLL beneath (for the SOCKET communication) which is compiled like this: build c-lib -- xmlBlaster/lib/libxmlBlasterClientCD.so If you are on Linux a .so, on Windows a .dll is generated. On Windows you need the Visual Studio compiler and if on Linux you need the gcc or icc and mono thanks Marcel First you have to start the server with XMLRPC support and then you can start your .NET client ... Hope this help you .. Cheers, Arghad On Fri, May 30, 2008 at 9:54 AM, Mohannad [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dear sir, I need to make a small communication using XMLblaster between two objects : Java and C#. Mr.Zied made a file /(Attached)/ for testing latency in Java and I need to make the same but in C# to make that small communication. Could any body help please? Thanks Mohannad -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] admin command to retrieve p2p messages/topics
Michael Justin wrote: Dear all Currently I am implementing a (free) admin client GUI for message brokers, including xmlBlaster. I have successfully used the admin commands to retrieve all kinds of information about the server, the sessions and the topic list. However I could not find out how I can retrieve additional topic information. The same approach which works with all other nested objects (like sessions, clients) gives an error message for topics. I have used the XML based metadata description on the xmlBlaster home page. The topic XML which I can retrieve starts with a TopicHandler element, is this the new element name for the topic metadata parts? Actually I would like to list all topics for P2P messages, if I can access the topic metadata I would try filter out these topics using the admin command. Many thanks in advance Hi Michael, sorry the late response. Basically, what you can see in jconsole should be available using messages as well. You can also try to query xmlBlaster via JMX (same as jconsole does). Note that for PtP we use normal topics (from Pub/Sub mode) as a 'vehicle'. What are the exact query informations you need? regards Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] determine the server
Mohannad wrote: Dear Sir, I run the RamTest.java and BigMessage.java in my machine (locally) and they work fine with me. However, I need to determine the server IP (XMLBlaster server) to make this test in a network. How can I do that ? The server to use IP 192.168.1.3 java -Dcom.sun.management.jmxremote org.xmlBlaster.Main -plugin/socket/hostname 192.168.1.3 The client to find above server: java HelloWorld3 -plugin/socket/hostname 192.168.1.3 regards Marcel which code should I modify ? Thanks, Mohannad -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Http and Socket
Zied ABID wrote: hi all, For deployment reason I have to work with http or https traffic, I thank that xmlrpc protocol will be a solution, but the callback server is not tolerated either ... I think now about 2 ways : 1) to work with socket protocol and adding a http connection between clients and server ... If there is no proxy (squid et al) and / or restrictive firewall in the way using SOCKET is the way to go. Callbacks are tunneled back. 2) work with client.browser and code something for a java Client ... If there is a company proxy and firewall inhibiting the direct socket access from inside to outside but http is working fine using a company proxy you can try the applet, it will use the browsers proxy settings and nicely connect to the outside xmlBlaster server. regards Marcel So , what do think , is a better way ? Do you have others ideas, advices ... ? thanks Zied PS : my work is open source, so if some one has already done something it will be very helpful to send it, if not, I hope doing something and I'll do it :) -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Testing Protocols
Mohannad wrote: thanks Zied, These files will be helpful. However, I need tools for measurement. I used jconsole but I didn't find for example a way to measure the time delay or packet transmission time. Is there any function in Jconsole will help to support this ? MBeans - org.xmlBlaster - node/xyz/client/aClient/session/1 Here you have very limited possibilities: Operations: pingClientCallbackServer() - will ping the client and report the millis needed Attributes: pingRoundTripDelay - Double click and you see a chart about the millis needed Marcel
Re: [xmlblaster] Publish return Qos without 'state' element
Michael Justin wrote: Dear all The specification for some return Qos does not match the actual values which I receive from xmlBlaster 1.6.2. qos state id='OK' info='QUEUED[bilbo]'/ key oid='MyMessageOid'/ rcvTimestamp nanos='104281583667501'/ /qos The state tag is omited if id='OK' (the default) and no info attribute is filled. On publish other states are not returned, however the info attribute may contain a local queued hint. On 'unrecoverable' publish failure you get an XmlBlasterException (the responsibility to take care on the message is bounced back to you). regards Marcel (http://xmlblaster.org/xmlBlaster/doc/requirements/interface.publish.html) In my tests, the 'state' element is not in the return Qos, instead there is a 'isPublish' element. qos key oid='MyMessageOid'/ rcvTimestamp nanos='120763960668700'/ isPublish/ /qos' The new isPublish element is very helpful to see that it is the answer to the publish command. I assume that the state is just no longer neccessary because problems will be reported as XmlBlasterException? Best Regards -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Client connection not being restored properly?
Hi David, I think your solution is to keep the server session alive by setting the session to unlimited. Further Notes: You could call xmlBlasterAccess.refreshSession() to refresh the server side session (but this can fail if the network is broken and the refresh is not reaching the server in time). If you don't want to use an unlimited server session you need to destroy the XmlBlasterAccess instance (without deleting the client queue entries) when going to DEAD (xmlBlasterAccess.disconnect(disConnectQos)). Use a disConnectQos.clearClientQueue(false) to keep the entries. Re-establish the connection with a new XmlBlasterAccess instance which then sends the existing queue entries. However - this will, i think, not work if you use a RAM,1.0 queue (no DB). As said in the last mail, XmlBlasterAccess behavior is fishy after going to DEAD, which needs to be fixed by us. We more clearly need to invalidate the XmlBlasterAccess instance in this case. And finally: If your scenario is a use case which we should support we can think of changing the client library behavior so that a server session timeout triggers a POLLING (and not a DEAD) which would solve your case. Is there any logical reason to keep the to-DEAD pattern (Michele?) regards Marcel David Kerry wrote: On Wed, Apr 02, 2008 at 07:42:54PM +0200, Marcel Ruff wrote: Hi David, if the server side session times out the expected behavior is that the client goes to dead (what you client seem to do). That your client recovers from DEAD is not intended and is considered a bug, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.failsafe.html#failsave The transition (9) and (8) should not happen. Thanks for reporting best regards Marcel Hi Marcel, Whoops! Then I guess the original issue is still outstanding then. If my client goes from ALIVE-DEAD, simply because of a session timeout on the server side, what are my options on the client side to reconnect gracefully and to prevent the loss of the messages still queued on the client side? The client still happily accepts messages for queueing even though the connection state is DEAD and returns no errors. -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Client connection not being restored properly?
Hi David, if the server side session times out the expected behavior is that the client goes to dead (what you client seem to do). That your client recovers from DEAD is not intended and is considered a bug, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.failsafe.html#failsave The transition (9) and (8) should not happen. Thanks for reporting best regards Marcel David Kerry wrote: On Mon, Mar 10, 2008 at 11:10:54AM +0100, Marcel Ruff wrote: Hi David, fail safe mode should also set a positive session id, like this the client queue is found again on restart and you don't need another queue to store the entries. Something like java -Dcom.sun.management.jmxremote javaclients.HelloWorldSubscribe -session.name subscriber/1 -dispatch/callback/retries -1 -connect/qos/persistent true -persistentSubscribe true The persistent settings are only needed to recover from server restart and to not loose a message if a publisher reconnects and publishes earlier, before our subscriber reconnects and re-subscribes. best regards, Marcel Hi Marcel, Something's still fishy here. Although I'm not setting a persistent queue (I'm not concerned about queued incoming messages while disconnected right now), I am setting all the other parameters for a failsafe connection (callback retries -1, positive session id). I've setup my client to be notified of connection state via the I_ConnectionStateListener interface. When I attempt to publish a message after the session times out, I get a callback when the session times out (reachedDead), which is correct. However, what's not happening reliably is the reachedPolling state. Most of the time my test client goes reachedDead - reachedPolling - reachedAlive. In some cases it just goes reachedDead and no further. I did note this exception that popped out on the client side in a case where the client didn't get to a polling state. I don't know if it's relevant or not though. I didn't see any other log output or exceptions around the time this occurred. The server side simply indicates the session timed out. 2008-04-01 13:45:36,602 INFO [STDOUT] java.lang.Exception: Stack trace 2008-04-01 13:45:36,603 INFO [STDOUT] at java.lang.Thread.dumpStack(Thread.java:1158) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.client.ClientErrorHandler.handleError(ClientErrorHandler.java:79) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchManager.givingUpDelivery(DispatchManager.java:379) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchManager.shutdownFomAnyState(DispatchManager.java:371) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.updateState(DispatchConnectionsHandler.java:368) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.toDead(DispatchConnectionsHandler.java:336) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchConnection.handleTransition(DispatchConnection.java:498) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchConnection.send(DispatchConnection.java:241) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.send(DispatchConnectionsHandler.java:455) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:70) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchManager.putPre(DispatchManager.java:668) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.dispatch.DispatchManager.putPre(DispatchManager.java:642) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.util.queue.ram.RamQueuePlugin.put(RamQueuePlugin.java:723) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:901) 2008-04-01 13:45:36,603 INFO [STDOUT] at org.xmlBlaster.client.XmlBlasterAccess.publish(XmlBlasterAccess.java:1061) 2008-04-01 13:45:36,603 INFO [STDOUT] at com.navahonetworks.app.jboss.xmlblaster.NNXmlBlasterClientImpl.publish(NNXmlBlasterClientImpl.java:165) 2008-04-01 13:45:36,603 INFO [STDOUT] at com.navahonetworks.app.jboss.xmlblaster.NNXmlBlasterClientImpl.publish(NNXmlBlasterClientImpl.java:138) 2008-04-01 13:45:36,604 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 2008-04-01 13:45:36,604 INFO [STDOUT] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 2008-04-01 13:45:36,604 INFO [STDOUT] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 2008-04-01 13:45:36,604 INFO [STDOUT] at java.lang.reflect.Method.invoke(Method.java:585) 2008-04-01 13:45:36,604 INFO [STDOUT] at com.navahonetworks.ejb.session.XmlblasterLogicBean.publish(XmlblasterLogicBean.java:287) 2008-04-01 13:45:36,604 INFO
Re: [xmlblaster] Client connection not being restored properly?
Hi David, fail safe mode should also set a positive session id, like this the client queue is found again on restart and you don't need another queue to store the entries. Something like java -Dcom.sun.management.jmxremote javaclients.HelloWorldSubscribe -session.name subscriber/1 -dispatch/callback/retries -1 -connect/qos/persistent true -persistentSubscribe true The persistent settings are only needed to recover from server restart and to not loose a message if a publisher reconnects and publishes earlier, before our subscriber reconnects and re-subscribes. best regards, Marcel David Kerry wrote: On Wed, Feb 27, 2008 at 06:28:59PM +0100, Marcel Ruff wrote: snip My way of working around this for now is to create yet another queue, in my application that keeps a copy of the saved messages until a connection is re-established after which it puts them back in the xmlblaster queue for publishing. This works, but it's, well, ugly. Is this the intended client behaviour in this situation? Keep in mind that I'm not concerned about subscriptions and incoming messages to this client, if that makes a difference. Hi David, what about starting the client in fail safe mode? Like this the client retries to establish a connection and sends the queued messages on reconnect, regards, Marcel Hi Marcel, I think I was mistaken. I think I am connecting in fail-safe mode, if 'fail-safe' mode means setting up the connection reconnect/ping/retry values. I am not specifying an explicit session id, however (I get a negative id back upon connect). For reference, here are the connect properties I'm using: protocol=SOCKET dispatch/connection/pingInterval=3 dispatch/connection/retries=-1 dispatch/connection/delay=5000 dispatch/connection/plugin/socket/port=7607 dispatch/connection/plugin/socket/hostname= queue/connection/defaultPlugin=RAM,1.0 The rest are whatever defaults that xmlblaster client provides. From reading the reference docs, I think this actually does enable failsafe mode, correct? -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] xmlBlaster with HTTP
Zied ABID wrote:
Hi,
I begin to work with xmlBlaster for my degree's Project, it will be
deployed in a server under a firewall so 80 port with HTTP is open (or
even HTTPS ) .
well, I have some quetions :
1) can I work with XmlRpc protocol already in xmlBlaster ? will I
work with xmlBlaster servelet ?
If i understand you correctly: On 80 a web server (like apache,tomcat)
is running.
You can't use our XmlRpc for this as in this case the XMLRPC server must
be xmlBlaster itself (running on port 80 or 8080 ...).
If you want to use a servlet approach there are currently only two
options a.f.a.i.k:
1) Using an applet
xmlBlaster/src/java/org/xmlBlaster/protocol/http/appletproxy/README
(servlet setup)
xmlBlaster/src/java/org/xmlBlaster/client/protocol/http/applet/README
(applet setup)
xmlBlaster/demo/http/applet (applet example)
2) Using a javascript client in a browser
(xmlBlaster/src/java/org/xmlBlaster/protocol/http/ajax/AjaxServlet.java)
Here you have the complete Ajax based xmlBlaster access.
In case you need a stand-alone java client with bi-directional
communication you
need to code some lines yourself, probably the applet code is a good
point to start.
About you questions below:
This works fine here:
java -Dcom.sun.management.jmxremote org.xmlBlaster.Main
java HelloWorld3 -protocol XMLRPC
your configuration looks ok but i think the server names are somehow
invalid,
best regards
Marcel
2) using Socket protocol, I could change properties for clients like
HelloWorld6 and the server in command line , but I don' work for xmlrpc :
for client :
// Change hard-coded the protocol and server lookup:
String[] args = { -protocol, XMLRPC,
-dispatch/connection/plugin/xmlrpc/hostname, server.xxx.zz,
-dispatch/connection/plugin/xmlrpc/port,
8080, // I try with 8080 to not use root access
-dispatch/connection/plugin/socket/localHostname, client.xxx.zz,
-dispatch/connection/plugin/xmlrpc/localPort, 8080
};
for server : the command line :
java -jar lib/xmlBlaster.jar -plugin/xmlrpc/port 8080
I had for client :
2008-03-06 15:31:08.909 [32;40m INFO [0m 10-main
org.xmlBlaster.client.protocol.xmlrpc.XmlRpcConnection init: Created
'XMLRPC' protocol plugin to connect to xmlBlaster server
2008-03-06 15:31:09.32 [32;40m INFO [0m 10-main
org.xmlBlaster.client.protocol.xmlrpc.XmlRpcConnection
connectLowlevel: Created XmlRpc client to http://server.xxx.zz:8080/
2008-03-06 15:31:09.70 [32;40m INFO [0m 10-main
org.xmlBlaster.util.dispatch.DispatchConnection handleTransition:
Connection 'XMLRPC' transition UNDEF - ALIVE: Success,
DispatchConnection-connection:client/abid_zie1204813867398 connected.
2008-03-06 15:31:09.192 [32;40m INFO [0m 10-main
org.xmlBlaster.util.dispatch.DispatchManager switchToSyncMode:
connection:client/abid_zie1204813867398: Switched to synchronous
message delivery
2008-03-06 15:31:09.317 [31;40mSEVERE [0m 10-main
javaclients.HelloWorld6 init: Houston, we have a problem:
errorCode=user.configuration message=#exported Local host IP
'server.xxx.zz' for XMLRPC callback server is invalid:
java.io.IOException: Cannot assign requested address
Success, hit a key to exit
( I can ping server.xxx.zz and client.xxx.zz )
So wan't wrong here ?
3) if, I want to add this properties in xmlBlaster.properties , how
can I do it? I'll try to put lines like :
# after the line 87 :
CbProtocolPlugin[XMLRPC][1.0]=org.xmlBlaster.protocol.xmlrpc.CallbackXmlRpcDriver
#test if proprities work for XmlRpc:
plugin/xmlrpc/port=8080
plugin/xmlrpc/hostname=server.xxx.zz
plugin/xmlrpc/localport=8080
I hope that isn't too much questions ...
thanks for your time and your answers
--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371
Re: [xmlblaster] Client connection not being restored properly?
David Kerry wrote: On Mon, Feb 25, 2008 at 02:48:33PM +0100, Marcel Ruff wrote: David Kerry wrote: Hello All, I'm seeing some odd behaviour on one of my clients here and I'm not sure if it's a bug, feature, or configuration problem. Client and server are running the 1.6.2 version of code. Hi David, 1. Why is secretSessionId invalid? We would need to see the server log for this, possibly the session timed out. 2. Is the client connecting in fail safe mode? o With public session ID 0: -session.name spiderman_test/1 o -dispatch/callback/retries -1 To detect going DEAD you can register xmlBlasterAccess.registerConnectionListener() and react Kerry-like (see xmlBlaster/demo/HelloWorld4.java). Still it would be good to know why the secret sessionId got invalid. best regards Marcel, Michele Hi Marcel, Well, I figured this out - it was a bit of a misunderstanding on the session timeout parameter. I didn't look close enough and thought it was in seconds instead of milliseconds. Thus, my client's sessions kept timing out on the server side much too fast! The client wasn't connecting in fail safe mode, and I was using a connection listener to monitor the connection, which helped my figure out what was going on. However, the client behaviour when the server times out the session is still a little off, I believe. What I see happening is the server kills the client session (fine), but the client doesn't notice that fact until it tries to use the connection (ie: publish), even though it has a connection-ping setup for every 10 seconds. Once the publish happens, the client goes 'oh, my connection is dead' and then starts queuing messages. At this point, however, the client never goes into a polling mode and the only way to re-establish communications is to do a disconnect(), re-instatiate a new XmlBlasterAccess and do another connect(). This whole process also has the side-effect of erasing all the queued messages. If I try to simply call connect() again, I get an exception stating connect() rejected, you are connected already, please check your code. My way of working around this for now is to create yet another queue, in my application that keeps a copy of the saved messages until a connection is re-established after which it puts them back in the xmlblaster queue for publishing. This works, but it's, well, ugly. Is this the intended client behaviour in this situation? Keep in mind that I'm not concerned about subscriptions and incoming messages to this client, if that makes a difference. Hi David, what about starting the client in fail safe mode? Like this the client retries to establish a connection and sends the queued messages on reconnect, regards, Marcel -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Client connection not being restored properly?
org.xmlBlaster.client.protocol.socket.SocketConnection shutdown FINER: Entering shutdown of callback server Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.protocol.socket.SocketCallbackImpl shutdownSocket FINE: Entering shutdownSocket() Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.protocol.socket.SocketConnection shutdown FINE: InputStream.close(): java.net.SocketException: Socket is closed Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.protocol.socket.SocketConnection shutdown FINE: OutputStream.close(): java.net.SocketException: Socket is closed Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchConnectionsHandler removeDispatchConnection FINE: connection:client/ejb_test1203703214006: Destroyed one callback connection, 0 remain. Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchConnectionsHandler updateState FINE: connection:client/ejb_test1203703214006: updateState() oldState=ALIVE conList.size=0 Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager shutdownFomAnyState FINER: connection:client/ejb_test1203703214006: Switch from ALIVE to DEAD Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.XmlBlasterAccess toDead FINER: client/ejb_test/-42: Changed from connection state ALIVE to DEAD connectInProgress=false Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager givingUpDelivery FINE: connection:client/ejb_test1203703214006: Entering givingUpDelivery(), state is DEAD Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.ClientErrorHandler handleError FINER: Entering handleError for 0 messages Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.protocol.socket.SocketCallbackImpl run FINE: Terminating socket callback thread Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager shutdown FINER: connection:client/ejb_test1203703214006: Entering shutdown ... Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchConnectionsHandler shutdown FINER: connection:client/ejb_test1203703214006: Entering shutdown ... Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager handleSyncWorkerException FINER: connection:client/ejb_test1203703214006: Sync delivery failed connection state is DEAD: errorCode=communication.noConnection.dead message=#exported Your secretSessionId is invalid, no access to spiderman_test. : O riginal erroCode=user.security.authentication.accessDenied Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager checkSending FINE: connection:client/ejb_test1203703214006: The dispatcher is shutdown, can't activate callback worker thread DispatchManager id='connection:client/ejb_test1203703214006' numEntries='0' isShutdown='true' DispatchConnectionsHandler state='DEAD' noDispatchConnection/ /DispatchConnectionsHandler dispatchWorkerIsActivefalse/dispatchWorkerIsActive /DispatchManager Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager switchToASyncMode INFO: connection:client/ejb_test1203703214006: Switched to asynchronous message delivery Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.dispatch.ClientDispatchConnectionsHandler createFakedReturnObjects FINER: Entering createFakedReturnObjects() for 1 entries Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.dispatch.ClientDispatchConnectionsHandler createFakedReturnObjects FINE: Creating faked return for 'publish' invocation Feb 22, 2008 2:36:02 PM org.xmlBlaster.util.dispatch.DispatchManager handleSyncWorkerException FINE: connection:client/ejb_test1203703214006: Delivery failed, pushed 1 entries into tail back queue Feb 22, 2008 2:36:02 PM org.xmlBlaster.client.XmlBlasterAccess queueMessage FINE: client/ejb_test/-42: Forwarded one 'publish' message, current state is DEAD Feb 22, 2008 2:36:59 PM org.xmlBlaster.util.dispatch.DispatchConnection finalize FINE: DispatchConnection-connection:client/ejb_test1203703214006 finalize - garbage collected Feb 22, 2008 2:36:59 PM org.xmlBlaster.util.queuemsg.MsgQueueEntry finalize FINE: finalize - garbage collect At this point, the client is still running, but it never reconnects back to the server, regardless of how many publish() calls are made - the messages are effectively lost in the client-side queue now. Is this a bug, or a configuration issue or is there some method I should be calling to 'kick' the connection back up and allow the queued messages to get published to the server? -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Problem to publish several message under the same oid topic
[EMAIL PROTECTED] wrote: The SimpleReaderGui is really useful Thank you. It's working for me. So a question then , when X messages are published under the same publish key oid, the subscriber will receive each messages from this topic if he has subscribe to trough a XPATH query for example. When I execute a XPATH query with XML Blaster control panel (all my message have been published for my topic with oid Test) I will only see the last published message for this topic ? Yes, as a default only the current message of a topic is delivered. Each topic has a history queue of default size 10 messages which can be queried as well. See subscribe QoS: http://www.xmlblaster.org/xmlBlaster/doc/requirements/interface.subscribe.html Usually the history feature is of no much use, regards Marcel Regards, Louis Le lundi 11 février 2008 à 22:40 +0100, Marcel Ruff a écrit : Hi, i have just tried (export CLASSPATH=$XMLBLASTER_HOME/lib/xmlBlaster.jar): java -Dcom.sun.management.jmxremote org.xmlBlaster.Main -cluster.node.id heron opened the sniffer java javaclients.simplereader.SimpleReaderGui and hit 'Subscribe' And edited HelloWorld3.java with your code compiled it ~/xmlBlaster build all and started java HelloWorld3 and all three messages Test arrive as expected. Could you please re-check? regards Marcel Champion Louis wrote: Hi, I am a newbie to XMLBlaster and I am actually trying to figure how it's works. I have take a look to the different HelloWorld examples. The Java code : PublishQos publishQos = new PublishQos(global); publishQos.addClientProperty(Name, Henri); publishQos.addClientProperty(Age, 25); PublishKey publishKey = new PublishKey(global,Test); MsgUnit[] msgUnits = new MsgUnit[3]; MsgUnit msgUnit1 = new MsgUnit(publishKey, Transaction id=\1\ /, publishQos); msgUnits[0] = msgUnit1; MsgUnit msgUnit2 = new MsgUnit(publishKey, Transaction id=\2\ /, publishQos); msgUnits[1] = msgUnit2; MsgUnit msgUnit3 = new MsgUnit(publishKey, Transaction id=\3\ /, publishQos); msgUnits[2] = msgUnit3; xmlBlasterAccess.publishArr(msgUnits); When I use the graphical tools to execute the XPATH query //key, I only get the message with the content of the Transaction with the id 3. And when I look into my postgresql database I have only one entry into the table. Why one entry when I have try to publish 3 messages ? Thanks in advance for any explanation, Louis -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Retrieve an external custom property in the '__sys__Event' message
Salut Richard, 1) Add this to xmlBlasterPlugins.xml plugin create='true' id='subscriptionSpecificEvents' className='org.xmlBlaster.engine.EventPlugin' action do='LOAD' onStartupRunlevel='8' sequence='4'/ action do='STOP' onShutdownRunlevel='7' sequence='4'/ attribute id='eventTypes'topic/*/event/subscribe,topic/*/event/unSubscribe/attribute attribute id='destination.publish' publish.key=key oid='__sys__Subscribe'__sys__internal//key, publish.qos=qosexpiration lifeTime='0'/topic destroyDelay='3'persistence relating='msgUnitStore' type='RAM'/queue relating='history' type='RAM'//topic/qos /attribute /plugin 2) Start the server java -Dcom.sun.management.jmxremote org.xmlBlaster.Main -cluster.node.id heron 3) Start a listener to '__sys__Subscribe' events (just to see that it works) java javaclients.simplereader.SimpleReaderGui and hit Subscribe 4) Do a subscribe (and unSubscribe by hitting 'u') with an added SubscribeQos property myProperty java -Dcom.sun.management.jmxremote javaclients.HelloWorldSubscribe -clientProperty[myProperty] 1234 5) Enjoy Now the SimpleReaderGui event notification contains a clientProperty name='myProperty'1234/clientProperty markup in the UpdateQos. IMPORTANT NOTE: Please update again from current svn as i have added an important recursion detection for your case! regards Marcel [EMAIL PROTECTED] wrote: Hi Marcel, Thanks for your response (I just read your response, I don't know why I did'nt receive directly an E-mail as I subscribed to the mailing list xmlblaster@server.xmlBlaster.org ??) What do you mean by this information is not delivered ? There is no documentation ? If you have coded and commit the functionality I need, could you please give some hooks (classes, package, method concerned in the API, ..) where I can search in the xmlBlaster sources to test it. Richard. Re: [xmlblaster] Retrieve an external custom property in the '__sys__Event' messag e Marcel Ruff Tue, 29 Jan 2008 11:12:48 -0800 Hi Richard, this information is not delivered. However, I have coded it quickly and commited it (completely untested, no testsuite yet, but it is no dangerous spot as not in the core and should work). Please check xmlBlaster out from svn and try it and give feedback, Marcel [EMAIL PROTECTED] wrote: Hi, I want to capture the two following evenTypes : topic/*/event/subscribe and topic/*/event/unSubscribe Following the advice of the REQ admin.event, my client (subscribing to __sys__Event) receives effectively an event like the following when another client invokes the subscribe() method : key oid='__sys__Event' contentMimeExtended='1.0' org.xmlBlasterevent//org.xmlBlaster /key content size='23'topic/*/event/subscribe/content qos clientProperty name='_subscriptionId'__subId:heron-113681279891300/clientProperty clientProperty name='_nodeId'heron/clientProperty clientProperty name='_description' encoding='base64'.../clientProperty clientProperty name='_eventType'topic/*/event/subscribe/clientProperty clientProperty name='_summary'New subscription of client /node/heron/client/joe/1 on topic airport/clientProperty clientProperty name='_publicSessionId' type='long'1/clientProperty clientProperty name='_subjectId'joe/clientProperty clientProperty name='_absoluteName'/node/heron/client/joe/1/clientProperty clientProperty name='_topicId'airport/clientProperty /qos My problem: I would like to retrieve a custom property set by the subscriber (who invokes the subscribe() method) in the qos part of the previous message. For example, a subscriber set a property like myProperty=1234 then call con.subscribe() and I would like to receive a message like the following : key oid='__sys__Event' contentMimeExtended='1.0' org.xmlBlasterevent//org.xmlBlaster /key content size='23'topic/*/event/subscribe/content qos clientProperty name='_subscriptionId'__subId:heron-113681279891300/clientProperty clientProperty name='_nodeId'heron/clientProperty clientProperty name='_description' encoding='base64'.../clientProperty clientProperty name='_eventType'topic/*/event/subscribe/clientProperty clientProperty name='_summary'New subscription of client /node/heron/client/joe/1 on topic airport/clientProperty clientProperty name='_publicSessionId' type='long'1/clientProperty clientProperty name='_subjectId'joe/clientProperty clientProperty name='_absoluteName'/node/heron/client/joe/1/clientProperty clientProperty name='_topicId'airport/clientProperty clientProperty name
Re: [xmlblaster] Retrieve an external custom property in the '__sys__Event' messag e
Hi Richard, this information is not delivered. However, I have coded it quickly and commited it (completely untested, no testsuite yet, but it is no dangerous spot as not in the core and should work). Please check xmlBlaster out from svn and try it and give feedback, Marcel [EMAIL PROTECTED] wrote: Hi, I want to capture the two following evenTypes : topic/*/event/subscribe and topic/*/event/unSubscribe Following the advice of the REQ admin.event, my client (subscribing to __sys__Event) receives effectively an event like the following when another client invokes the subscribe() method : key oid='__sys__Event' contentMimeExtended='1.0' org.xmlBlasterevent//org.xmlBlaster /key content size='23'topic/*/event/subscribe/content qos clientProperty name='_subscriptionId'__subId:heron-113681279891300/clientProperty clientProperty name='_nodeId'heron/clientProperty clientProperty name='_description' encoding='base64'.../clientProperty clientProperty name='_eventType'topic/*/event/subscribe/clientProperty clientProperty name='_summary'New subscription of client /node/heron/client/joe/1 on topic airport/clientProperty clientProperty name='_publicSessionId' type='long'1/clientProperty clientProperty name='_subjectId'joe/clientProperty clientProperty name='_absoluteName'/node/heron/client/joe/1/clientProperty clientProperty name='_topicId'airport/clientProperty /qos My problem: I would like to retrieve a custom property set by the subscriber (who invokes the subscribe() method) in the qos part of the previous message. For example, a subscriber set a property like myProperty=1234 then call con.subscribe() and I would like to receive a message like the following : key oid='__sys__Event' contentMimeExtended='1.0' org.xmlBlasterevent//org.xmlBlaster /key content size='23'topic/*/event/subscribe/content qos clientProperty name='_subscriptionId'__subId:heron-113681279891300/clientProperty clientProperty name='_nodeId'heron/clientProperty clientProperty name='_description' encoding='base64'.../clientProperty clientProperty name='_eventType'topic/*/event/subscribe/clientProperty clientProperty name='_summary'New subscription of client /node/heron/client/joe/1 on topic airport/clientProperty clientProperty name='_publicSessionId' type='long'1/clientProperty clientProperty name='_subjectId'joe/clientProperty clientProperty name='_absoluteName'/node/heron/client/joe/1/clientProperty clientProperty name='_topicId'airport/clientProperty clientProperty name='myProperty'1234/clientProperty /qos Is there any solution for my problem or any way to implement this sort of functionality ? Thanks. -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] xmlrpc v3 plugin; callback timing?
Póka Balázs wrote: Hi! is this issue resovled? I haven't done anything since then to resolve it, so I believe not. However, the XMLRPC v3 plugin (proposed and written by me) has been working in a production environment for a few months at our company, so I may as well offer my source code to the xmlblaster project (default xmlblaster license). Maybe then you can better understand what's going on here, because I didn't. :) Hi Balázs, currently i'm quite busy but i'll give you svn access so you can commit it, as soon as possible. Thanks for your donation offer, best regards, Marcel regards, Balázs -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] xmlrpc v3 plugin; callback timing?
Hi Póka is this issue resovled? Thanks Marcel Michele Laghi wrote: Hi Póka could you reproduce the 400 ms loop ? I tried with a simple case and I could only see it setting when going from ALIVE to POLLING. If you where experiencing a loop, then it must have switched back and forth between these two states and would be definitely worth giving a closer look. Could you reproduce the error and send us the logs (possibly with fine or finest) ? Regards Michele Póka Balázs wrote: Hi! you are right that the timer is overwritten , but this is a behaviour which is desidered when the state first changes from alive to polling, on the next sweep the delay will not be overwritten since the reconnect=false. The logs however are wrong, I will fix them. You're saying the polling is really only done (after the first try) at the interval I specified, but the log is reporting it every 400 ms? I'm absolutely sure I saw these messages at exactly 400 ms intervals. I went through the code myself, it's quite complicated, I may have missed something or I may have implemented the new XMLRPC plugin incorrectly. For the XMLRPC Code of course we would be more than happy, as you mentionned earlier the old XMLRPC Library is kind of outdated. All right, I'll get to it and send you the source when 1 or 2 remaining issues are fixed. Balázs -- Marcel Ruff http://www.xmlBlaster.org http://watchee.net Phone: +49 7551 309371
Re: [xmlblaster] Subscription Invocation Exception
| at com.sun.org.apache.xpath.internal.axes.NodeSequence.setRoot(Unknown Source) INFO | jvm 2| 2007/12/12 17:12:38 | at com.sun.org.apache.xpath.internal.axes.LocPathIterator.execute(Unknown Source) INFO | jvm 2| 2007/12/12 17:12:38 | ... 18 more INFO | jvm 2| 2007/12/12 17:12:38 | Dec 12, 2007 5:12:38 PM WARNING 238-XmlBlaster.socket_ssl.SSL.tcpListener-my.account RL10 org.xmlBlaster.engine.xml2java.XmlKeyDom parseKeyOid: Sorry, can't access, query syntax is wrong for '//key[starts-with(@oid, 'vsp-') and (Division='DIV5')]' : XmlBlasterException errorCode=[resource.configuration] serverSideException=true location=[XmlNotPortable] message=[#exported Can't process XPath expression '//key[starts-with(@oid, 'vsp-') and (Division='DIV5')]' : java.lang.reflect.InvocationTargetException] [See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#resource.configuration ] INFO | jvm 2| 2007/12/12 17:12:38 | Dec 12, 2007 5:12:38 PM WARNING 238-XmlBlaster.socket_ssl.SSL.tcpListener-my.account RL10 org.xmlBlaster.engine.RequestBroker subscribe: XmlBlasterException errorCode=[user.query.invalid] serverSideException=true location=[XmlKeyDom] message=[#exported Sorry, can't access, query syntax of '//key[starts-with(@oid, 'vsp-') and (Division='DIV5')]' is wrong : XmlBlasterException errorCode=[resource.configuration] serverSideException=true location=[XmlNotPortable] message=[#exported Can't process XPath expression '//key[starts-with(@oid, 'vsp-') and (Division='DIV5')]' : java.lang.reflect.InvocationTargetException] [See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#resource.configuration ]] [See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#user.query.invalid ] Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org
[xmlblaster] ANNOUNCE xmlBlaster release 1.6.2 'Openroads'
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 1.6.2 'Openroads'. It is a bug fix release and contains some extensions, please consider to upgrade. It is released after massive testing (Java/C/C++) and a lot of feed back of our partners and users. The C/C++ clients are now also available on o Vista with VC++ 2005 or 2008 and the newest xerces 2.8 o Unixes with the newest g++ 4.2.1 and Intel C++ icc 10.1.008 o Windows CE 4 and 5 (C only) For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES This release is generously sponsored by Openroads Consulting! (http://www.openroadsconsulting.com/) enjoy, the xmlBlaster maintainers
Re: [xmlblaster] Calling peek admin message?
David R Robison wrote: Any idea of how to call this with two parameters? I am trying to call unSubscribeByIndex. Thanks, David Hi David, with our command syntax this is not possible, it was originally designed to support properties only and was never further developed. However it should be possible to access it with JMX (as jconsole is able to access it as well). This works fine here (tested from command line of the running xmlBlaster server console): j org.xmlBlaster:nodeClass=node,node=xmlBlaster_192_168_1_25_3412,clientClass=client,client=Subscriber,sessionClass=session,session=1/action=usage j org.xmlBlaster:nodeClass=node,node=xmlBlaster_192_168_1_25_3412,clientClass=client,client=Subscriber,sessionClass=session,session=1/action=peekCallbackMessages?p1+int=1p2+java.lang.String='Hello' Unfortunately your query i couldn't get to work: j org.xmlBlaster:nodeClass=node,node=xmlBlaster_192_168_1_25_3412,clientClass=client,client=Subscriber,sessionClass=session,session=1/action=unSubscribeByIndex?p1+int=1p2+java.lang.String='Hello' -- javax.management.AttributeNotFoundException: unSubscribeByIndex not accessible I don't know yet why ... Marcel David R Robison wrote: Thanks. In case others are interested, the correct call was: MsgUnit[] msgUnit = xmlBlaster.get(key oid='__cmd: + data.session + /?peekCallbackMessages'/, qosquerySpec type='QueueQuery'![CDATA[100]]/querySpec/qos); David Marcel Ruff wrote: Hi David, the way to query queues is described in http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html The notation you have described seems to be broken in the current xmlBlaster, we need to check this, regards Marcel David R Robison wrote: How would I call the peek admin message? I am trying it as: MsgUnit[] msgUnit = xmlBlaster.get(key oid='__cmd: + data.session + /?peekCallbackMessages50'/, qos/); but getting the error errorCode=resource.configuration message=#exported Error while SAX parsing :1:79 : org.xml.sax.SAXParseException: The entity name must immediately follow the '' in the entity reference. any thoughts? TNX David -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Callback message queue fills up
David Robison wrote: I think part of the problem might be that the subscriptions, even when you specify a domain, are not domain specific. What I mean is that a user connected to B subscribes to messages for a domain that is mastered on A. However, when the subscription is forwarded to A, it matches messages from all domains, even those generated on B and sent to A. Does this make sense? Could this be part of the problem? It boils down to the question if the oid and domain are ANDed? (B is slave, A is master of Sport) B-client: subscribe( oid=Hello domain=Sport ) - ends up in A as A is master of Sport A-client: publish( oid=Hello domain= ) - is matched in A and forwarded to B and then to B-client So, as you mentioned, the domain is not ANDed. But i still can't see this as the reason for your filled up callback queue. Note: If a published message is forwarded to another cluster node you will see something like route node id='B' stratum='1' timestamp='119615134316000' dirtyRead='false'/ node id='A' stratum='0' timestamp='119615134316400' dirtyRead='false'/ /route in the publishQos. best regards, Marcel David *From:* David R Robison [mailto:[EMAIL PROTECTED] *To:* xmlblaster@server.xmlBlaster.org *Sent:* Wed, 21 Nov 2007 10:41:10 -0500 *Subject:* Re: [xmlblaster] Callback message queue fills up Here is a dunp of one of the messages: MsgUnit index='0' key oid='DomainHeartbeat-Albemarle911' contentMime='text/xml' contentMimeExtended='1.0' domain='Albemarle911'/ content size='46'Domain Albemarle911 ALIVE at 11/21/07 09:48:43/content qos subscribable/ sender/node/Albemarle911/client/A-NATIVE-CLIENT-PLUGIN/-3/sender priorityMAX/priority subscribe id='__subId:StauntonSTC-XPATH119562846332900'/ expiration lifeTime='3' remainingLife='22703' forceDestroy='true'/ rcvTimestamp nanos='119565948261302'/ queue index='0' size='1'/ persistentfalse/persistent isUpdate/ /qos /MsgUnit The message was created on node B and sent to node A because of a subscription on node A. But it is now in the callback queue on A to go back to B. Also, I have never seen the route data in the messages. Is there a way to turn this on? David Marcel Ruff wrote: David R Robison wrote: One other thought. Heartbeat messages are published on node B and subscribed to by clients on node A. Also, there are clients on node B that subscribe to messages on node A. However, it appears that the subscriptions the clients on node B are using are also matching the heartbeat messages from node B that have been sent to node A. Could I have some kind of circular queue? A message is posted on B then sent to A because a subscription by a client on A. Then sent back to B because of a subscription by a client on B for messages on A. Then the message gets sent back to A and the whole cycle repeats? Could be, usually the cluster should prevent this ... The messages contain in their QoS the nodes traversed: qos senderjoe/sender route node id='bilbo' stratum='2' timestamp='34460239640'/ node id='frodo' stratum='1' timestamp='34460239661'/ node id='heron' stratum='0' timestamp='34460239590'/ /route /qos it would be nice to see the dump of such messages, Use the jconsole or logging output from your receiving client or use the message sniffer, e.g.: java javaclients.simplereader.SimpleReaderGui -xpath //key -session.name simpleReader -passwd secret -protocol SOCKET -dispatch/connection/plugin/socket/hostname 192.168.1.25 -dumpToFile true or peek the callback queue with administrative messages as described in one of your last posts, thanks Marcel Could this be possible? David David R Robison wrote: Thanks, See in line... Marcel Ruff wrote: Hi David, do you have a jconsole to observe the two nodes? I don't have a jconsole, but can I get the same using the admin messages? If yes, please check the number of subscriptions the node A has forwarded to node B (look into node B and check the number of subscriptions of client A) during such a case. In case the subscribeQos has set I will check. multiSubscribetrue/multiSubscribe I believe that we set all to false. (which is the default) it could be that the subscriptions multiplied during small connection errors and reconnects. This is just a guess. If it is the case please set multiSubscribe to false. Is there a high CPU load during the 1001 message case? No Are the hearbeat messages persistent messages? Yes, but the only live 30
Re: [xmlblaster] Callback message queue fills up
David R Robison wrote: Thanks, See in line... Marcel Ruff wrote: Hi David, do you have a jconsole to observe the two nodes? I don't have a jconsole, but can I get the same using the admin messages? You can, but jconsole will save you (and me :-) a lot of time, - really - try to set up jconsole observation! You need a JDK 1.5 or 1.6 to be installed on your production nodes then you can just fire up the jconsole. This is how I do it: If the production node is a Windows use RDP if it is a UNIX use nomachine (or X or VNC). If you don't have grafical access to the production machines but you have ssh access you can configure to tunnel the jconsole data over ssl and start the jconsole locally on your desktop (no new security hole, just the existing ssh). For ssh i can send you an example setup (private/public key exchange etc). You need to configure the running xmlBlaster to allow jconsole access, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.jmx.html regards Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] How integrate xmlBlaster in existing applications
Hi Sam, I want to know if we can integrate xmlblaster as mideleware in existing system, i dis not find an answer on the site: 1- Is is possible to integrate xmlblastre without developping, just with configuration? In theory you can avoid coding and do a lot with configuration, e.g. if you use the file poller plugin and throw files on the disk to be transittet, or if you use xmlBlaster xml-scripting. In real use cases you need to code. 2- if developpement is a must, what are the steps , it seems for me that xmlblaster in examples runs as server and i do not know how to make it as bridge, is it sufficient to have developpement code in xmlblaster path? First you start the xmlBlaster server somewhere. Now your coding starts: You take the provided client libraries in your preferred language (Java/C++/C/ScriptLanguages/C#/...) and code the messages you want to transfer. Those xmlBlaster clients are the gateways to your existing applications, DB and logic. regards Marcel Thanks you Sam -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Callback message queue fills up
David R Robison wrote: One other thought. Heartbeat messages are published on node B and subscribed to by clients on node A. Also, there are clients on node B that subscribe to messages on node A. However, it appears that the subscriptions the clients on node B are using are also matching the heartbeat messages from node B that have been sent to node A. Could I have some kind of circular queue? A message is posted on B then sent to A because a subscription by a client on A. Then sent back to B because of a subscription by a client on B for messages on A. Then the message gets sent back to A and the whole cycle repeats? Could be, usually the cluster should prevent this ... The messages contain in their QoS the nodes traversed: qos senderjoe/sender route node id='bilbo' stratum='2' timestamp='34460239640'/ node id='frodo' stratum='1' timestamp='34460239661'/ node id='heron' stratum='0' timestamp='34460239590'/ /route /qos it would be nice to see the dump of such messages, Use the jconsole or logging output from your receiving client or use the message sniffer, e.g.: java javaclients.simplereader.SimpleReaderGui -xpath //key -session.name simpleReader -passwd secret -protocol SOCKET -dispatch/connection/plugin/socket/hostname 192.168.1.25 -dumpToFile true or peek the callback queue with administrative messages as described in one of your last posts, thanks Marcel Could this be possible? David David R Robison wrote: Thanks, See in line... Marcel Ruff wrote: Hi David, do you have a jconsole to observe the two nodes? I don't have a jconsole, but can I get the same using the admin messages? If yes, please check the number of subscriptions the node A has forwarded to node B (look into node B and check the number of subscriptions of client A) during such a case. In case the subscribeQos has set I will check. multiSubscribetrue/multiSubscribe I believe that we set all to false. (which is the default) it could be that the subscriptions multiplied during small connection errors and reconnects. This is just a guess. If it is the case please set multiSubscribe to false. Is there a high CPU load during the 1001 message case? No Are the hearbeat messages persistent messages? Yes, but the only live 30 seconds. At any given time there should only be at most 2 in the history queue Was the client connected or offline during this message overflow? No, the client was online Does your heartbeat have a unique id so that you can tell for sure if the same No, but the content of the message has a timestamp so I knew they were duplicates published message is cloned many times (try a peek on the callback queue with jconsole)? Can this be done with the admin messages A final option is to use the current svn xmlBlaster and switch on the checkpoint logging to get a better idea what is going on. We will try this in house, unfortunately, the problem nodes are in a production environment. And finally it could be a problem with your client not taking the callback messages. Could be, but what I don't see is the queue gradually growing. Instead, it all-of-a-sudden appears to be full. Another idea: 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 -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Callback message queue fills up
Hi David, do you have a jconsole to observe the two nodes? If yes, please check the number of subscriptions the node A has forwarded to node B (look into node B and check the number of subscriptions of client A) during such a case. In case the subscribeQos has set multiSubscribetrue/multiSubscribe (which is the default) it could be that the subscriptions multiplied during small connection errors and reconnects. This is just a guess. If it is the case please set multiSubscribe to false. Is there a high CPU load during the 1001 message case? Are the hearbeat messages persistent messages? Was the client connected or offline during this message overflow? Does your heartbeat have a unique id so that you can tell for sure if the same published message is cloned many times (try a peek on the callback queue with jconsole)? A final option is to use the current svn xmlBlaster and switch on the checkpoint logging to get a better idea what is going on. And finally it could be a problem with your client not taking the callback messages. Another idea: 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 -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Property: Added 7 property pairs
David R Robison wrote: I have an xmBlaster client. It started at 02:01:20 and gave the message Property: Added 7 property pairs. At 13:08:20 it repeated the message. I was surprised that this message would be repeated. Is this normal? If so, what causes it? If this is not normal, what might cause it? I think when a new Global is created this is written out, but i need to check the code ... Marcel Thanks, David Robison -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Calling peek admin message?
Hi David, the way to query queues is described in http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html The notation you have described seems to be broken in the current xmlBlaster, we need to check this, regards Marcel David R Robison wrote: How would I call the peek admin message? I am trying it as: MsgUnit[] msgUnit = xmlBlaster.get(key oid='__cmd: + data.session + /?peekCallbackMessages50'/, qos/); but getting the error errorCode=resource.configuration message=#exported Error while SAX parsing :1:79 : org.xml.sax.SAXParseException: The entity name must immediately follow the '' in the entity reference. any thoughts? TNX David -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] use of public I_ConnectionProblems
Hi Jürgen,
you are probably missing the registration for such events:
connection_.initFailsafe(this);
regards
Marcel
Jürgen Prinz wrote:
I tried to employ the public I_ConnectionProblems method as shown in
SubscribeDemo with my clients
in BlasterBase.H
class BlasterBase : public I_Callback, public I_ConnectionProblems
...
public:
bool reachedAlive(StatesEnum /*oldState*/, I_ConnectionsHandler*
connectionsHandler);
void reachedDead(StatesEnum /*oldState*/, I_ConnectionsHandler*
/*connectionsHandler*/);
void reachedPolling(StatesEnum /*oldState*/, I_ConnectionsHandler*
/*connectionsHandler*/);
In BlasterBase.C
bool BlasterBase::reachedAlive(StatesEnum /*oldState*/,
I_ConnectionsHandler* connectionsHandler)
{
cout reachedAlive endl;
return true;
}
void BlasterBase::reachedPolling(StatesEnum /*oldState*/,
I_ConnectionsHandler* connectionsHandler)
{
cout reachedPolling endl;
}
void BlasterBase::reachedDead(StatesEnum /*oldState*/,
I_ConnectionsHandler* connectionsHandler)
{
cout reachedDead endl;
}
but never got called.
The SubscribeDemo, using the same properties and the same xmlBlaster
report the approtriate LOG_INFO's.
Any suggestions ?
--
Marcel Ruff
http://www.xmlBlaster.org
Re: [xmlblaster] socket reconnect flood
Póka Balázs wrote: Hi Marcel! what is the current state with this issue? That's an old one... This was fixed ages ago. I believe it was a combination of my bad API usage (had forgotten to cleanup Global object) with an inability of reproducing the bug locally which lead to the assumption that this was a bug in XmlBlaster code. I think there had never been a problem like this since then. regards, Balázs So you are using SOCKET SSL without problems? thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Expected Release Date
Jonathan Clark wrote: Marcel, I could use the new release immediately, so I guess my time frame is as soon as possible. I just had a chat with Michele, he is currently coding some features for xmlBlaster, so our natural date to create a release will be end of month / beginning first days in December. As creating a release binds quite some time for both of us we haven't got the resources for a quicker release. You have the option to stick with the current svn or buy professional support for other solutions, thanks for understanding, best regards Marcel Thanks, Jonathan Jonathan Clark wrote: Can you give me an estimate of the next expected release date? I'd like to include this change, but would rather do it with one of the official releases. Thanks, Currently we haven't scheduled a release, what are your time frames? Michele: Any suggestion from your side? Thanks Marcel Jonathan Hi all, the leak is now removed and the code is available in the current svn trunk. The leak was due to a change in the EventPlugin. Regards Michele Marcel Ruff wrote: Jonathan Clark wrote: Marcel, I'm trying to track down this specific memory leak change, but could not identify it in svn through the date or the svn comments. Any help would be greatly appreciated. Thanks, The leak was somewhere introduced at #16357 EventPlugin notification when queue threshold is reached We added a possibility to trigger arbitrary events when queues run full. It was partly fixed some weeks ago and currently Michele does some final coding on this issue, regards, Marcel Mon, 17 Sep 2007 Michele wrote: Hi Marcel, you are right, a cleanup is needed when shutting down the queue. Ok, i have now commited the patch, Balázs could you please verify? thanks Marcel Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org http://www.xmlblaster.org/ Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] default response timout
to reconnect and resubscribe to the blaster. This situation does not happen all the time, but only occasionally and unfortunately we have not been able to isolate the exact string of events that cause this problem. We are hoping that a timeout will fix the problem. David Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org http://www.xmlblaster.org/ Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] socket reconnect flood
Póka Balázs wrote: Hi there, 2006-11-06 20:20:07,847 INFO [XmlBlaster.PingTimer] (SocketConnection.java :180) - SSL client socket enabled for socket://**:7608, keyStore=/home/disp/disp/conf/nova_disp/truststore I forgot to mention that you might notice by correlating the logs and the code, that there is no logging statement in this line. That is because I'm using log4j as logging framework, and wrote an adaptor class which translates java.util.logging log messages to log4j. Until recently I didn't get the code right and here it still displayed a lower stack frame with respect to where logging methods were really invoked from. I have corrected this tonight. If you need more exact, fine-grained logs, maybe with level set to FINER, I could update the deployed app and wait for the bug to happen again. It should be a few days max. regards, Balázs Hi again, what is the current state with this issue? Thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] default response timout
Jonathan Clark wrote: I've tried to set the timeout value for the client side to correct the problem detailed below, but have not found the correct entry.I am using dispatch/connection/plugin/socket/responseTimeout=6, but this does not seem to affect the client side. Any suggestions on what property I should be setting? Thanks, Do you have blocking clients when the server disappears? If yes, can you reproduce this issue? Thanks, Marcel David Robison wrote: I am not sure why the xmlBlaster does not respond. Here is the stack trace when the client gets hung waiting for a response. DomainCheckTimer prio=6 tid=0x033a29b0 nid=0x182c in Object.wait() [0x03ebf000..0x03ebfbec] at java.lang.Object.wait(Native Method) at EDU.oswego.cs.dl.util.concurrent.Latch.attempt(Latch.java) - locked 0x198226e0 (a EDU.oswego.cs.dl.util.concurrent.Latch) at org.xmlBlaster.util.protocol.RequestReplyExecutor.requestAndBlockForReply(RequestReplyExecutor.java:629) at org.xmlBlaster.client.protocol.socket.SocketConnection.subscribe(SocketConnection.java:469) at org.xmlBlaster.client.dispatch.ClientDispatchConnection.subscribe(ClientDispatchConnection.java:282) at org.xmlBlaster.client.dispatch.ClientDispatchConnection.doSend(ClientDispatchConnection.java:150) at org.xmlBlaster.util.dispatch.DispatchConnection.send(DispatchConnection.java:231) at org.xmlBlaster.util.dispatch.DispatchConnectionsHandler.send(DispatchConnectionsHandler.java:435) at org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:70) at org.xmlBlaster.util.dispatch.DispatchManager.putPre(DispatchManager.java:561) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:476) at org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.put(CacheQueueInterceptorPlugin.java:456) at org.xmlBlaster.client.XmlBlasterAccess.queueMessage(XmlBlasterAccess.java:820) at org.xmlBlaster.client.XmlBlasterAccess.subscribe(XmlBlasterAccess.java:862) at com.orci.datagateway.ClientKit.DGDomain.subscribe(DGDomain.java:327) at com.orci.datagateway.ClientKit.DGConnection.addDomain(DGConnection.java:146) - locked 0x17feb2c0 (a com.orci.datagateway.ClientKit.DGConnection) at com.orci.datagateway.ClientKit.DGDomain.connect(DGDomain.java:195) at com.orci.datagateway.ClientKit.DGDomain.updateCurrentState(DGDomain.java:264) at com.orci.datagateway.ClientKit.DGDomain.checkState(DGDomain.java:216) at com.orci.datagateway.ClientKit.DGDomain$CheckDomainsTask.run(DGDomain.java:404) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) The problem seems to occur when using SocketSSL protocol and the server dies and comes back up. The client tries to reconnect and resubscribe to the blaster. This situation does not happen all the time, but only occasionally and unfortunately we have not been able to isolate the exact string of events that cause this problem. We are hoping that a timeout will fix the problem. David Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org
Re:[xmlblaster] Re: memory leak with socket sessions
Jonathan Clark wrote: Marcel, I'm trying to track down this specific memory leak change, but could not identify it in svn through the date or the svn comments. Any help would be greatly appreciated. Thanks, The leak was somewhere introduced at #16357 EventPlugin notification when queue threshold is reached We added a possibility to trigger arbitrary events when queues run full. It was partly fixed some weeks ago and currently Michele does some final coding on this issue, regards, Marcel Mon, 17 Sep 2007 Michele wrote: Hi Marcel, you are right, a cleanup is needed when shutting down the queue. Ok, i have now commited the patch, Balázs could you please verify? thanks Marcel Jonathan Clark Open Roads Consulting, Inc. 757-546-3401 -- Marcel Ruff http://www.xmlBlaster.org
[xmlblaster] Tracing message flow ...
Hi, in the current svn there is a new plugin which allows to trace the flow of a message through the xmlBlaster core. This can be helpful if you sometimes wonder where your messages end up ... Details: http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.checkpoint.html regards Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Which xmlBlaster.properties file was loaded?
David R Robison wrote: Is it possible to have xmlBlaster log which xmlBlaster.proeprties file was loaded? I'm not sure my instance is grabbing the correct file. TNX David It is reported as the first line on startup: ~ java -Dcom.sun.management.jmxremote org.xmlBlaster.Main Property: Loading xmlBlaster.properties from directory /home/xmlblast regards Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Unknown log file message
David R Robison wrote: My logfile has a lot of the following types of messages, what to they mean and how can I better handle them? Thanks, David INFO | jvm 1| 2007/10/11 17:47:58 | Oct 11, 2007 5:47:58 PM WARNING 8255-XmlBlaster.DispatchWorkerPool.StauntonSTC-143 RL10 org.xmlBlaster.engine.RequestBroker deadMessage: Recursive message 'callback:/node/StauntonSTC/client/SYSTEM/-9/MAX/119213914894204/DomainHeartbeat-Albemarle911' is error handled already (sent as dead letter), we ignore it. Hi David, could you please provide more details? Is the client 'SYSTEM/-9' disappearing frequently? How are the connect settings? Does your callback queue overflow? Is it a PtP or a subscribed message? thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] default response timout
David Robison wrote: I noticed that the default timeout response was changed from one minute to MAX_INT in release 1.0.7. Was there a reason for this change. We have run into a situation when we issue a subscribe command but never get a response. With the MAX_INT timeout, the program hangs. I was thinking about resetting the response timeout to one minute but wanted to make sure that this would not cause additional problems. Thanks, David Robison Why is the response not returning? client -- subscribe -- xmlBlaster --- subscribeReturnQos -- is it xmlBlaster which is not responding? I think the first step is to track down the reason for the missing response. We have introduced the MAX_INT mainly for callbacks. If the callback carries a huge message over a modem (taking for example half a day) it may cause a ping to be blocked which in turn aborts the transfer and the callback dispatcher goes to polling. Then it is retried again, fails again and so on. This situation is not this critical anymore as the current xmlBlaster detects the bytes transfered and ommits the ping if bytes travel over the socket. Yes, i would say you can reduce the MAX_INT in your case, regards, Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] server hangs when changing the size maximum of the DispathcWorkerPool
(on object monitor) at java.lang.Object.wait(Native Method) at org.xmlBlaster.util.Timeout.run(Timeout.java:203) - locked 0xdacbe8a8 (a org.xmlBlaster.util.Timeout) XmlBlaster.HttpIORServer daemon prio=10 tid=0x0130c000 nid=0x66 runnable [0xd4baf000..0xd4bafaf0] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked 0xda94f2d8 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.xmlBlaster.util.http.HttpIORServer.run(HttpIORServer.java:157) XmlBlaster.SocketDriver daemon prio=10 tid=0x01309c00 nid=0x65 runnable [0xd4bdf000..0xd4bdfa70] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked 0xda94f1e8 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketI mpl.java:259) at org.xmlBlaster.protocol.socket.SocketDriver.run(SocketDriver.java:533) XmlBlaster.SocketDriver daemon prio=10 tid=0x013a7000 nid=0x64 runnable [0xd4c0f000..0xd4c0fbf0] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked 0xda94f260 (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.xmlBlaster.protocol.socket.SocketDriver.run(SocketDriver.java:533) XmlBlaster.SessionTimer daemon prio=10 tid=0x013a7800 nid=0x63 in Object.wait() [0xd4c3f000..0xd4c3fb70] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.xmlBlaster.util.Timeout.run(Timeout.java:203) - locked 0xda949870 (a org.xmlBlaster.util.Timeout) XmlBlaster.Consumer daemon prio=10 tid=0x003fe400 nid=0x62 in Object.wait() [0xd4c6f000..0xd4c6f8f0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xdac36698 (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$Seria lizableLock) at java.lang.Object.wait(Object.java:485) at edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue.take( LinkedBlockingQueue.java:316) - locked 0xdac36698 (a edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$Seria lizableLock) at org.xmlBlaster.engine.TopicAccessor$Consumer.run(TopicAccessor.java:451) at java.lang.Thread.run(Thread.java:619) -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] dead lock
Xavier Roques wrote: In my configuration, I want that the clients always try to connect back to the Server so the clients retries is set to -1. But I want to be informed as soon as a client is disconnected. That's why my configuration is dispatch/callback/retries=0 Otherwise I'm not informed when a client is abnormally disconnected. So, I have a question, is there a way to know that a client has been normally disconnected or not ? Xavier. If you set dispatch/callback/retries=-1 the server will never cleanup your session (it will only if you do an explicit disconnect() or kill it using the jconsole). If the client disappears the callback framework goes to state POLLING, and all settings like subscribes or callback queue entries are preserved (even on server restart if marked persistent/). You can detect polling clients using an EventPlugin, see http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.events.html and use the event client/[subjectId]/session/[publicSessionId]/event/callbackState Please use the newest xmlBlaster as we have made some coding changes for this in the last history, best regards Marcel -Original Message- From: [EMAIL PROTECTED] [mailto:owner- [EMAIL PROTECTED] On Behalf Of Marcel Ruff Sent: mercredi 26 septembre 2007 19:02 To: xmlblaster@server.xmlBlaster.org Subject: Re: [xmlblaster] dead lock Xavier Roques wrote: Hi David, When the dead lock occurred, I have one server with 144 connected clients. All my clients are configured in fail safe mode and all the messages are stored in RAM, the configuration of all my agents is: #server configuration dispatch/callback/retries=0 -- 0 no retry: XmlBlaster will clean up the session if the client does not respond to the callback ping if you need fail safe behaviour you should set dispatch/callback/retries=-1 regards Marcel dispatch/callback/delay=2000 dispatch/callback/pingInterval=2000 dispatch/callback/plugin/socket_ssl/multiThreaded=false #client configuration pingInterval=2000 retries=-1 delay=2000 The problem occurred after having restarted 30 of the agents running on the same box. I hope it may help, Xavier. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *David Robison *Sent:* mercredi 26 septembre 2007 14:46 *To:* xmlblaster@server.xmlBlaster.org *Subject:* 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
Re: [xmlblaster] dead lock
(DispatchConnecti on.java:423) INFO | jvm 1| 2007/09/25 11:31:29 | at org.xmlBlaster.util.Timeout.run(Timeout.java:189) -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] dead lock
David Robison wrote: 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. This happens when: 1. No fail safe client connection (pubSessionId 0) (Xavier, is this correct?) 2. Client is reconnecting 3. At the same time xmlBlaster's callback ping thread detects the lost client and wants to clean up regards Marcel 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
Re: [xmlblaster] dead lock
Xavier Roques wrote: Hi David, When the dead lock occurred, I have one server with 144 connected clients. All my clients are configured in fail safe mode and all the messages are stored in RAM, the configuration of all my agents is: #server configuration dispatch/callback/retries=0 -- 0 no retry: XmlBlaster will clean up the session if the client does not respond to the callback ping if you need fail safe behaviour you should set dispatch/callback/retries=-1 regards Marcel dispatch/callback/delay=2000 dispatch/callback/pingInterval=2000 dispatch/callback/plugin/socket_ssl/multiThreaded=false #client configuration pingInterval=2000 retries=-1 delay=2000 The problem occurred after having restarted 30 of the agents running on the same box. I hope it may help, Xavier. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *David Robison *Sent:* mercredi 26 septembre 2007 14:46 *To:* xmlblaster@server.xmlBlaster.org *Subject:* 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
Re: [xmlblaster] use of setReconnectSameClientOnly
Jürgen Prinz wrote: I use this feature to assure, that only one client with this session-id is connected. i only wondered that the exception did not occure with the connect. It happens on connect, but you are notified asynchronously as you are in fail safe mode. Note that you can max log in once for the user (loginName) and NOT for the session. To have more such 'singleton' clients you need to use different login names. Best regards and thanks Jürgen P.S. What about my problem with OSF/Motif timmers ? As said in my posting from 2007-09-10 you should check your multi threading approach, probably it is necessary to dispatch the code to the X-Window main loop thread, best regards Marcel Marcel Ruff wrote: Dear Jürgen, the details of this feature are described here: http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.configuration.html (search Assuring a client singleton there) First you should set maxSessions='1' in your use case! You get the exception errorCode=user.configuration.identicalClient and Only the creator of session /node/ZBAA_/client/[EMAIL PROTECTED]/99 may reconnect, access denied. The reason is most likely that a login session of [EMAIL PROTECTED] exists already please use the jconsole to check. best regards Marcel Jürgen Prinz wrote: To prevent identical users , i use setReconnectSameClientOnly(true) in SessionQos. It works, but the error is a bit confusing (see below) The connect is ok, but the following get has a exception. Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#1)[24414]: [EMAIL PROTECTED] connecting to xmlBlaster. Connect qos: Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#2)[24414]: qos Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#3)[24414]: securityService type=htpasswd version=1.0 Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#4)[24414]: ![CDATA[ Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#5)[24414]: user[EMAIL PROTECTED]/99/user Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#6)[24414]: passwdbeijing/passwd Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#7)[24414]:]] Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#8)[24414]: /securityService Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#9)[24414]: ptptrue/ptp Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#10)[24414]: instanceId/instanceId/119070820156172/instanceId Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#11)[24414]: session name='client/[EMAIL PROTECTED]/99' timeout='8640' maxSessions='10' clearSessions='true' reconnectSameClientOnly='true'/ Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#12)[24414]: Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#13)[24414]: !-- QueuePropertyBase -- Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#14)[24414]: queue relating='connection' type='RAM' maxEntries='1000' storeSwapLevel='1468006' storeSwapBytes='524288' reloadSwapLevel='629145' reloadSwapBytes='524288' Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#15)[24414]: address type='SOCKET' bootstrapHostname='127.0.0.1' bootstrapPort='0' dispatchPlugin='undef' Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#16)[24414]: socket://127.0.0.1 Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#17)[24414]: /address Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#18)[24414]: /queue Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#19)[24414]: !-- QueuePropertyBase -- Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#20)[24414]: queue relating='callback' storeSwapLevel='1468006' storeSwapBytes='524288' reloadSwapLevel='629145' reloadSwapBytes='524288' Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#21)[24414]: callback type='SOCKET' bootstrapHostname='127.0.0.1' dispatchPlugin='undef' Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#22)[24414]: socket://127.0.0.1:3412 Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#23)[24414]: /callback Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#24)[24414]: /queue Sep 25 10:16:41 vpngateway Objserv(2007,650,INFO,,,#25)[24414]: /qos INFO XmlBlasterAccess-client/[EMAIL PROTECTED]/99 Callback settings: type=CACHE onOverflow=deadMessage onFailure=deadMessage maxEntries=1000 type=SOCKET oneway=false burstMode.collectTime=0 WARN ConnectionsHandler-1190708201563105000 Got exception when connecting, polling now: errorCode=user.configuration.identicalClient message=XmlBlasterException errorCode=[user.configuration.identicalClient] serverSideException=true location=[Authenticate.connect()] message=[#exportiert Only the creator of session /node/ZBAA_/client/[EMAIL PROTECTED]/99 may reconnect, access denied. : ] [See URL http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#user.configuration.identicalClient] INFO RamQueuePlugin Created queue [RAM][1.0] Sep 25 10:16:41 vpngateway Objserv(2007,920,INFO,,,#1)[24414
Re: [xmlblaster] j2me related questions..
) at org.xmlBlaster.client.protocol.http.common.XmlBlasterAccessRawBase.connect(+122) at SystemInfoMidlet.init(+21) at SystemInfoMidlet.startXmlBlaster(+193) at SystemInfoMidlet.run(+4) -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Problems connecting C# Clients
Hmm, the XmlRpc approach is maintained by Cyrille, Cyrille do you have an idea about this issue? Francis, there is another, well tested C# access using http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.c.windowsCE.html (see http://www.xmlblaster.org/xmlBlaster/doc/requirements/client.csharp.html overview). It uses all the features of the C SOCKET client libraries (like tunneling callback through the same socket, zlib streaming compression etc). Depending on your use case, this socket approach is probably the way to go. regards Marcel Francis Bernard wrote: Hello, when i run the CSharpDrawingDemo, keeping the default values, http://127.0.0.1:8080/ guest guest i get this error. [ERROR] XmlBlaster operation has failed. - Unable to connect to the remote server [ERROR]at XmlBlaster.XmlBlasterException.HandleException(Exception ex) at XmlBlaster.XmlBlasterClient.Connect(String url, String username, String password) at xmlrpc.Form1.connect_Click(Object sender, EventArgs e) [ERROR] XmlBlaster operation has failed. - Unable to connect to the remote server [ERROR]at XmlBlaster.XmlBlasterException.HandleException(Exception ex) at XmlBlaster.XmlBlasterClient.Subscribe(String topic) at xmlrpc.Form1.connect_Click(Object sender, EventArgs e) I tried stopping the firewall, no luck. I tried netstat, and i saw that the xmlblaster server is running and listening on ports: 8080, 7607, 3412, no luck. my server is started with set XMLBLASTER_HOME=D:\xmlBlaster_REL_1_0_7\xmlBlaster java -cp %XMLBLASTER_HOME%/lib -jar %XMLBLASTER_HOME%/lib/xmlBlaster.jar i tried downloading an older version, no luck. xmlrpc plugin is activated on the xmlblasterplugins.xml What am i missing ? Francis -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Re: memory leak with socket sessions
Michele wrote:
Hi Marcel,
you are right, a cleanup is needed when shutting down the queue.
Ok, i have now commited the patch,
Balázs could you please verify?
thanks
Marcel
Marcel Ruff wrote:
Póka Balázs wrote:
Hi again!
Reflecting on my memory leak post yesterday, today I went though some
source code, beginning with QueuePluginManager. I noticed that the
only place where unprocessedEvents.remove is called is method
registerFinished() (that means that the map can only be emptied
there); that method is called from nowhere else than
EventPlugin.init(Global, PluginInfo). The most important piece of
information by far is that I didn't have any EventPlugin enabled!
So, I suppose this memory leak must have been occuring from the
beginning, but it only became a problem because on of our clients
reconnects every 10 minutes.
Am I right or wrong? :)
right.
The leak sneaked in on 2007-06-19.
Michele, it seems the offending code is
QueuePluginManager.java:
public I_Queue getPlugin(PluginInfo pluginInfo, StorageId storageId,
QueuePropertyBase props) throws XmlBlasterException {
...
if (!props.isEmbedded()) {
EventHelper helper =
this.storageEventHandler.generateEventHelper(storageId);
this.storageEventHandler.registerListener(plugin, helper);
}
return plugin;
}
any idea why decided to always register the listener?
I think we need an own listener on each instance of the queue since the
configuration could allow different configurations for different (for
example) callback queues (on a per-client basis).
Regards
Michele
We could add to StorageEventHandler:
public void removeListener(I_Storage storage) throws
XmlBlasterException {
if (this.processedEvents != null) {
synchronized(this.processedEvents) {
this.processedEvents.remove(storage);
}
}
}
and somehow call it from I_Storage.shutdown() ...
Balázs, for the time being you could activate the EventPlugin (for some
dummy events)
to clean up the leak.
thanks
Marcel
regards,
Balázs Póka
--
Marcel Ruff
http://www.xmlBlaster.org
Re: [xmlblaster] Re: memory leak with socket sessions
Póka Balázs wrote: Hi again! Reflecting on my memory leak post yesterday, today I went though some source code, beginning with QueuePluginManager. I noticed that the only place where unprocessedEvents.remove is called is method registerFinished() (that means that the map can only be emptied there); that method is called from nowhere else than EventPlugin.init(Global, PluginInfo). The most important piece of information by far is that I didn't have any EventPlugin enabled! So, I suppose this memory leak must have been occuring from the beginning, but it only became a problem because on of our clients reconnects every 10 minutes. Am I right or wrong? :) I'll look at it - right or wrong --- the truth will come ... Marcel regards, Balázs Póka -- Marcel Ruff http://www.xmlBlaster.org
[xmlblaster] xmlBlaster release 1.6.1
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 1.6.1 If is a bug fix release. It is released after massive testing (Java/C/C++) and a lot of feed back of our partners and users. For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES enjoy, the xmlBlaster maintainers
Re: [xmlblaster] Deliver-once semantics and synchronous message query
If I understand that page correcly, I have two alternatives: Either a plain GET command on the administrative telnet port, or with the query variables encoded on the same form inside a querySpec tag in the QoS of (for instance) an xmlrpc call to xmlBlaster.get. If the latter is correct, then I suggest mentioning the querySpec tag in the example of all available get QoS on the interface.get requirement page. Done, thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Deliver-once semantics and synchronous message query
Hi Martin, you can access any server side queue (callback-queue, history-queue, subject-queue) with a synchronous call with get(). This is described in http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html It allows polling - or more elegant - doing a blocking get() until the given timeout happens or the given messages are available and then immediately returns. Your XmlRpc client would login and subscribe to all interested topics, its callback queue is filled but because you don't establish a callback server they are never delivered. Now you can use the above consuming get() to poll for them without ever loosing a message, even if you XmlRpc client is offline for some days, regards Marcel Martin Stjernholm wrote: Hello. I'm just figuring out how to put xmlBlaster to work in a project and I've never used it before, so please excuse what might be a newbie question. The engine.callback requirement mentions a guarantee to deliver messages only once. The thing is that I'd prefer to not use callback mode, but rather only use the synchronous get() method (over xmlrpc) to poll for messages. That way I don't have to set up an xmlrpc server. So can I get deliver-once semantics using synchronous polling too? Thanks. -- Marcel Ruff http://www.xmlBlaster.org
[xmlblaster] ANNOUNCE xmlBlaster release 1.6
Dear Ladies and Gentlemen, we would like to announce xmlBlaster release 1.6 If is a bug fix release and contains many minor extensions, please consider to upgrade. It is released after massive testing (Java/C/C++) and a lot of feed back of our partners and users. For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES enjoy, the xmlBlaster maintainers
Re: [xmlblaster] Scalability and Performance question
Hi David, as a developer i can't talk for xmlBlaster 'end-users', but i like your use case :-) I would recommend to simulate the setup in-house to recognize early enough possible problems. This shouldn't be too hard but will pay off in long term. Another issue in such an environment is efficient monitoring and control, here xmlBlaster offers some very smart features. Probably it is a good idea to hire Michele or myself for some days doing initial planing, best regards Marcel David R Robison wrote: We are also interested in people's experience with the stability of a large xmlBlaster network. Thanks again, David David R Robison wrote: We are currently deploying a statewide xmlBlaster network for regional data integration and sharing. The data being shared is standards based XML messages wrapped in an EDXL-DE message. We currently have deployed 6 xmlBlaster nodes, most operating as both domain masters and slaves. We foresee the network growing to about a dozen nodes with 2 dozen domains mapped onto the cluster of nodes with up to 1500 simultaneous users attached to the various nodes. Our client has expressed some question as to the ability of xmlBaster to scale to multiple nodes and multiple data sources. I am curious as to what other experience others have had in deploying large xmlBlaster networks and what performance is being realized by xmlBlaster. Thanks in advance, David Robison -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Client never leaves the function XmlblasterAccess.connect
Xavier Roques wrote:
Hi Marcel,
Thanks for your very quick answer.
I do exactly the same thing as the example HelloWord4.java.
What I don't understand is why the method XmlblasterAccess.connect never
finishes.
Good question, i have to check this ...
Marcel
Even if they were messages into the queue they will be sent, no ?
Xavier.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marcel Ruff
Sent: lundi 9 juillet 2007 14:20
To: xmlblaster@server.xmlBlaster.org
Subject: Re: [xmlblaster] Client never leaves the function
XmlblasterAccess.connect
Hi Xavier,
In our xmlBlaster/javaclients/HelloWorld4.java we have an example
...
con.registerConnectionListener(new I_ConnectionStateListener()
...
which registers on connection states and shows an example how to access
the
client queue. Like this you can destroy the subscription entries.
You should also consider to use the standard fail safe way of
xmlBlaster,
regards
Marcel
Xavier Roques wrote:
Hi,
I encountered a strange problem last day.
I have some clients connected to my Xmlblaster server.
I stopped the Xmlblaster server and I restarted it later.
One of my client did not reconnect to the Xmlblaster server.
My clients are not configured in client fail safe mode. When a client
detects that the connection is dead,
it closes the connection and open a new one.
After some debug I can see that my thread connector was blocked to the
function XmlblasterAccess.connect.
# code #
if (this.clientQueue.getNumOfEntries() 0) {
long num = this.clientQueue.getNumOfEntries();
log.info(getLogId()+We have + num + client side
queued
tail back messages);
this.dispatchManager.switchToASyncMode();
while (this.clientQueue.getNumOfEntries() 0) {
try { Thread.sleep(20L); } catch( InterruptedException
i)
{}
}
log.info((num-this.clientQueue.getNumOfEntries()) +
client
side queued tail back messages sent);
this.dispatchManager.switchToSyncMode();
}
# end code #
The field clientQueue contains 6 entries (Essentially subscribe) and
they are never cleaned. That's why the code
# code #
while (this.clientQueue.getNumOfEntries() 0) {
try { Thread.sleep(20L); } catch( InterruptedException
i)
{}
}
# end code #
Never finished.
Further more, the field dispatchManager has the attribute isShutDown
set
to true...
So my question is How can I avoid this issue ?
Thanks,
Xavier.
--
Marcel Ruff
http://www.xmlBlaster.org
Re: [xmlblaster] persistance and graceful disconnect
Martin Johnson wrote: Hi Marcel How would I achieve this use case. A client (socket) using a persistent connection and persistent subscription disconnects from the server gracefully. Hi Martin, if you call on client side: xmlBlasterAccess.leaveServer(null) ; // instead of xmlBlasterAccess.disconnect(...) the client side resources are freed but the server maintains the session and queues the subscribed messages. The client should use a positive public session id like: client/joe/session/1 and can reconnect to this session on restart (to access the filled callback queue). Further it should tell the xmlBlaster server on lost callback ping to retry, this is a command line example: java javaclients.HelloWorldSubscribe -session.name joe/5 -oid Hello -dispatch/callback/retries -1 -persistentSubscribe true You should set -persistentSubscribe to true as well. In this case even the xmlBlaster server may go down and on restart immediately collects messages for the subscriber (even if the subscriber arrives a day later). Like this no messages are ever lost. What you describe is a very common use case used most time with xmlBlaster and works very reliable, regards Marcel During this periond when the client is not available (ie shutdown for some maintenance) the server continues maintaining session and subscription queue. The client is then started again and connects to same sessionid and recv's messages published during period of downtime. I have been trying with qos deleteSubjectQueuefalse/deleteSubjectQueue clearSessionsfalse/clearSessions /qos When calling disconnect() Without much luck. Regards Martin -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] persistance with subscription and sessions
Martin Johnson wrote: Sent again in case registration process bounced first attempt to send. Hi Marcel, Michele, Below is and extract from another message on the list /-- 4. -multiSubscribe false when the subscriber restarts it does the same subscribe again and you would receive the messages twice. Setting this to 'false' will ignore duplicate identical subscribes (An alternative solution: We could change the code of HelloWorldSubscribe to check if it has reconnected to the previous session and in this case not do a subscribe anymore). --/ I really like to know the technique to do this rather than having multiSubscribe==false. 1) multiSubscribe=false is the smart way to go, the server takes care to not subscribe twice. 2) The alternative solution loads the burden to your client code. You need to save the secret session id from the ConnectReturnQos to your hard disk. On client restart and reconnect it loads the secretSessionId from hard disk again and compares it with the new one from the new ConnectReturnQos. If they are equal you know that the server still knows everything about us, if they are different you know that the server may have been down (or has destroyed your server session because of your settings) and has lost previous (none persistent) subscribes. 3) A third variant could query the existing subscriptions via a administrative command or JMX from the server and react accordingly. regards Marcel I have a crashing client (for other systematic reasons) and can end up with many many subscriptions. Love to be able to avoid this. Regards Martin -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Oracle : no suitable driver
I have in my CLASSPATH
/home/oracle/oracle/product/10.2.0/db_1/jdbc/lib/ojdbc14_g.jar
using in xmlBlaster.properties
JdbcDriver.drivers=oracle.jdbc.driver.OracleDriver
and an url
JdbcStorage[Oracle]=org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin,\
url=jdbc:oracle:thin:@localhost:1521:xmlb,\
user=xmlblaster,\
password=,\
connectionPoolSize=1,\
connectionBusyTimeout=9,\
maxWaitingThreads=300,\
tableNamePrefix=XB_,\
entriesTableName=ENTRIES,\
dbAdmin=true
StoragePlugin[JDBC][1.0]=${JdbcStorage[Oracle]}
QueuePlugin[JDBC][1.0]=${JdbcStorage[Oracle]}
and this works fine for me,
regards
Marcel
[EMAIL PROTECTED] wrote:
Hello
I try to use Oracle as persistence layer. I'v add the ojdbc14.jar in
the lib directory of xmlblaster. I still get the following error : (I
tried with SQLServer and got the same error)
java.sql.SQLException: No suitable driver found for
jdbc:oracle:thin:@benotesdev:1521:orcl
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at
org.xmlBlaster.util.queue.jdbc.JdbcConnectionPool.addConnectionToPool(JdbcConnectionPool.java:362)
at
org.xmlBlaster.util.queue.jdbc.JdbcConnectionPool.connect(JdbcConnectionPool.java:392)
at
org.xmlBlaster.util.queue.jdbc.JdbcConnectionPool.initialize(JdbcConnectionPool.java:613)
at
org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.getJdbcQueueManagerCommonTable(JdbcQueueCommonTablePlugin.java:161)
at
org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.initialize(JdbcQueueCommonTablePlugin.java:223)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.java:84)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.java:60)
at
org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin.initialize(CacheQueueInterceptorPlugin.java:292)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.java:84)
at
org.xmlBlaster.util.queue.QueuePluginManager.getPlugin(QueuePluginManager.java:74)
at
org.xmlBlaster.authentication.SubjectInfo.createSubjectQueue(SubjectInfo.java:275)
at
org.xmlBlaster.authentication.SubjectInfo.toAlive(SubjectInfo.java:247)
at
org.xmlBlaster.authentication.Authenticate.unsecureCreateSession(Authenticate.java:160)
at
org.xmlBlaster.engine.RequestBroker.init(RequestBroker.java:233)
at
org.xmlBlaster.engine.XmlBlasterImpl.init(XmlBlasterImpl.java:68)
at
org.xmlBlaster.authentication.Authenticate.init(Authenticate.java:98)
at
org.xmlBlaster.engine.runlevel.RunlevelManager.initPluginManagers(RunlevelManager.java:127)
at org.xmlBlaster.Main.init(Main.java:185)
at org.xmlBlaster.Main.init(Main.java:122)
at org.xmlBlaster.Main.main(Main.java:604)
Jun 25, 2007 4:40:10 PM SEVERE 10-XmlBlaster.MainThread RL0
org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin
initialize:
subject:/node/xmlBlaster_10_110_21_7_3412/client/__RequestBroker_in
ternal[xmlBlaster_10_110_21_7_3412]: Could not initialize the
persistent queue
'subject:/node/xmlBlaster_10_110_21_7_3412/client/__RequestBroker_internal[xmlBlaster_10_110_21_7_3412]'.
Is the JDBC Dri
ver jar file in the CLASSPATH ? Is the DB up and running ? We continue
RAM based ...XmlBlasterException errorCode=[resource.db.unavailable]
serverSideException=true location=[org.xmlBlaster.util.queue
.jdbc.JdbcQueueCommonTablePlugin-subject:/node/xmlBlaster_10_110_21_7_3412/client/__RequestBroker_internal[xmlBlaster_10_110_21_7_3412]/type
'JDBC' version '1.0'] message=[#exported getJdbcCommonTable
QueueManager: sql exception when initializing the connection pool :
java.sql.SQLException: No suitable driver found for
jdbc:oracle:thin:@benotesdev:1521:orcl] [See URL
http://www.xmlblaster.org/xmlBl
aster/doc/requirements/admin.errorcodes.listing.html#resource.db.unavailable]
The propery settings are:
queue relating='subject'/
errorCode=resource.db.unavailable message=#exported
getJdbcCommonTableQueueManager: sql exception when initializing the
connection pool : java.sql.SQLException: No suitable driver found for
jdbc:oracl
e:thin:@benotesdev:1521:orcl
at
org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.getJdbcQueueManagerCommonTable(JdbcQueueCommonTablePlugin.java:185)
As another trial, I've add the ojdbc14.jar file to the CLASSPATH
directory. This gave the same problem.
What am I doing wrong ?
Best regards
*
Koen Boutsen *
--
Marcel Ruff
http://www.xmlBlaster.org
Re: [xmlblaster] Strange error when unsubscribing
Hi again, (1) after some code review together with Michele we think that we have found the bug and have commitet the patch to svn: o #16185 Fixed using ServerScope in ConnectQos which used wrong ServerEntryFactory on client side (2) Additionally we have fixed a bug which occurres only when the same cluster slave connects to many master cluster nodes: o #16187 Fixed cluster client queue to have unique storageId Use -xmlBlaster/cluster/useLegacyClientQueueName true forces old behavior Robison: If you have entries remaining in a cluster client queue or plugin client queue you need to set: xmlBlaster/cluster/useLegacyClientQueueName=true Else the entries are not found on restarting the new xmlBlaster. Preferrably, if you can throw away those messages don't set anything to have the new behavior. regards, Marcel David Robison wrote: 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
Re: [xmlblaster] Strange error when unsubscribing
(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) May 23, 2007 12:08:52 PM INFO 6901718-pool-1-thread-4878 RL10 org.xmlBlaster.engine.RequestBroker unSubscribe: unSubscribe of '__subId:StauntonSTC-XPATH117993646275700' matched 1 entries in remote cluster It appears that there is a problem unsubscribing but I am unsure what the problem might be. Any thoughts or hints on how to proceed with debugging this problem? Thanks in advance, David Robison -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Panic Crash on xmlBlaster 1.5.1!
David Robison wrote: We upgraded to xmlBlaster 1.5.1 and are periodically experiencing a panic crash of the server. The crash is shown below. This is somewhat similar to another crash we used to get when plugins were publishing messages into the server. Any thoughts as to what the problem might be? Thanks, David Robison Hi David, it seems that there is a corrupt entry in the database. The MethodName should be something like 'publish' or 'subscribe' but not 'msg_xml'. Did you experience any problems with your backend DB? We use a column type='MSG_XML' with capital letters, but nowhere with small letters ... What DB do you use? Is it possible to export the database and send it to me directly for analysis? How often is 'periodically'? Thanks Marcel INFO | jvm 1| 2007/04/04 08:38:59 | java.lang.IllegalArgumentException: MethodName: The given methodName=msg_xml is unknown INFO | jvm 1| 2007/04/04 08:38:59 | stackTrace=java.lang.IllegalArgumentException: MethodName: The given methodName=msg_xml is unknown INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.def.MethodName.toMethodName(MethodName.java:196) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.client.queuemsg.ClientEntryFactory.createEntry(ClientEntryFactory.java:79) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.processResultSet(JdbcManagerCommonTable.java:1181) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2206) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.get(JdbcQueueCommonTablePlugin.java:1223) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.msgstore.cache.PersistenceCachePlugin.get(PersistenceCachePlugin.java:501) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.TopicHandler.getMsgUnitWrapper(TopicHandler.java:865) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.TopicAccessor.lookupDirtyRead(TopicAccessor.java:308) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.lookup(ReferenceEntry.java:344) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.getMsgUnitWrapper(ReferenceEntry.java:174) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.incrementReferenceCounter(ReferenceEntry.java:189) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.removed(ReferenceEntry.java:230) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.ram.RamQueuePlugin.removeRandom(RamQueuePlugin.java:536) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:179) INFO | jvm 1| 2007/04/04 08:38:59 | at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:732) INFO | jvm 1| 2007/04/04 08:38:59 | at java.lang.Thread.run(Unknown Source) INFO | jvm 1| 2007/04/04 08:38:59 | errorCode=resource.db.unknown message=#exported An unknown error with the backend database using JDBC occurred - http://www.xmlblaster.org/xmlBlaster/doc/requirements/admin.errorcodes.listing.html#resource.db.unknown INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.jdbc.JdbcManagerCommonTable.getEntries(JdbcManagerCommonTable.java:2227) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.jdbc.JdbcQueueCommonTablePlugin.get(JdbcQueueCommonTablePlugin.java:1223) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.msgstore.cache.PersistenceCachePlugin.get(PersistenceCachePlugin.java:501) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.TopicHandler.getMsgUnitWrapper(TopicHandler.java:865) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.TopicAccessor.lookupDirtyRead(TopicAccessor.java:308) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.lookup(ReferenceEntry.java:344) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.getMsgUnitWrapper(ReferenceEntry.java:174) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.incrementReferenceCounter(ReferenceEntry.java:189) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.engine.queuemsg.ReferenceEntry.removed(ReferenceEntry.java:230) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.queue.ram.RamQueuePlugin.removeRandom(RamQueuePlugin.java:536) INFO | jvm 1| 2007/04/04 08:38:59 | at org.xmlBlaster.util.dispatch.DispatchWorker.run(DispatchWorker.java:179) INFO | jvm
Re: [xmlblaster] strange error removeResponseListener entry not found
Xavier Roques wrote: Hi, I'm using Xmlblaster 1.1 and in the log of my server, I saw plenty of the following line. xmlBlaster.ssl_socket - [org.xmlBlaster.util.protocol.RequestReplyExecutor:socket://0.0.0.0:7609 ] removeResponseListener(nsgtpk-ivs01-agent:117311195060700) entry not found It is a known problem and how can I get rid of this ? I'm not aware of such an open issue. Can you please provide more details? Do some clients behave unexpected when the logging output is written? Marcel thanks, Xavier.
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
Re: [xmlblaster] Not getting callback on erase
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. The behavior should be similar, I'll try to reproduce it here ... Marcel 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] ANNOUNCE xmlBlaster release 1.5.1
Hi, we would like to announce xmlBlaster release 1.5.1 If is a bug fix release, please upgrade. It is released after massive testing (Java/C/C++). For more details please visit http://www.xmlblaster.org/xmlBlaster/CHANGES http://www.xmlblaster.org/xmlBlaster/RELEASE_NOTES enjoy, the xmlBlaster maintainers
[xmlblaster] C and C++ eclipse project files
Hi, we provide now (current svn) some eclipse project files to compile and debug the C and/or the C++ client library and demo executables on Linux/UNIX. You need eclipse 3.2 or higher (http://www.eclipse.org) and the CDT plugin 3.1.0 or higher (http://www.eclipse.org/cdt/). Please set following environment variables (or eclipse macros) so that eclipse finds the needed shared third party libs: #Example for a 32 bit compilation with self provided zlib, sqlite, xerces export usr_lib_dir=/usr/lib export zlib_include_dir=/opt/zlib-bin/include export zlib_lib_dir=/opt/zlib-bin/lib export sqlite_include_dir=/opt/sqlite-bin/include export sqlite_lib_dir=/opt/sqlite-bin/lib export xerces_include_dir=/opt/xerces-c-src_2_7_0-bin/include export xerces_lib_dir=/opt/xerces-c-src_2_7_0-bin/lib or for a 64 bit system: # C/C++ compilation with eclipse 3.2 and CDT 3.1.0 64 bit # all external libs were installed as RPMs (Suse example) export usr_lib_dir=/usr/lib64 export zlib_include_dir=/usr/include export zlib_lib_dir=/usr/lib64 export sqlite_include_dir=/usr/include export sqlite_lib_dir=/usr/lib64 export xerces_include_dir=/usr/include export xerces_lib_dir=/usr/lib64 The eclipse project files (.cdtbuild, .cdtproject, .project) reside in xmlBlaster/src/c xmlBlaster/demo/c/socket xmlBlaster/src/c++ xmlBlaster/demo/c++ you can import them over the eclipse menues: File - Import - General - Existing Projects into Workspace and add e.g. xmlBlaster/src/c++ for 'Select root directory'. enjoy, Marcel PS: For Windows and Windows CE you'll find some VC++ 2005 project files PPS: The build/ant/cpptasks building mechanism is still supported
Re: [xmlblaster] Annoying Warning about recv failed
The warning
an 21, 2007 4:29:29 PM WARNING 19-XmlBlaster.SOCKET RL10
org.xmlBlaster.protocol.socket.HandleClient run: Error parsing TCP data from
'/192.168.1.102:4178', check if client and server have identical compression or
SSL settings: java.net.socketException: Software caused connection abort: recv
failed
is emitted when the socket handle throws an exception.
It could happen when the client closes the socket very quickly
before the server has processed a disconnect.
But it can also be a hint for a misbehaving client.
If you want to suppress it try the command line (or xmlBlaster.properties entry)
-logging/org.xmlBlaster.protocol.socket.HandleClient SEVERE
Marcel
chris lau wrote:
okay, I did some testing on my webservice. What I found out is really bizarre.
Basically, I stripped the webservice down to a simple
connect as in the following code:
I_XmlBlasterAccess con = null;
Global glob = null;
try {
glob = new Global();
con = glob.getXmlBlasterAccess();
ConnectQos qos = new ConnectQos(glob);
qos.setSessionName(new SessionName(glob, test_publisher));
System.out.println (Connecting);
con.connect(qos, null);
} catch (XmlBlasterException e) {
} finally {
System.out.println (Disconnecting);
try { Thread.sleep(1000); } catch (InterruptedException e) {}
if (con != null) {
if (con.isConnected())
con.disconnect(new DisconnectQos(glob));
}
}
In the finally section, I upped the sleep time to 5000 instead of 1000 so I
could tell when the disconnect would happen and when the recv-failed message
appeared. It looks like the recv-failed message appears on disconnect. So to
confirm this, I commented out the disconnect and the message doesn't appear
after the client quits. I did this a few times to confirm.
I then added another Thread.sleep command of 5 seconds right after the
disconnect so I could confirm that it was the disconnect command causing this
warning. After looking at the blaster console I was able to count 5 seconds,
then the recv-failed message appears, then counted another 5 seconds, and my
client program resumes from it's call to the webservice.
Is there anyway I coded the disconnect call wrong?
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: [xmlblaster] Annoying Warning about recv failed
Hi Chris, i assume this chain: Client C# SOAP/SSL servlet : java xmlBlaster client -SOCKET--- xmlBlaster server Your problem is that the java client looses connection to the server. The exception tells me that the SOCKET connection will be shutdown. As your publish arrives there must be a reconnect behind the scene. I'm quite sure that your java xmlBlaster client has some coding problem or it is another client showing the behaviour. 1. Try to test you client 'standalone' outside of tomcat 2. Who does the reconnect after your lost connection? 3. Can you switch on detailed logging inside tomcat showing the xmlBlaster client lifecycle? thanks Marcel chris lau wrote: Hi, Recently, I moved from a pure Java client to a C# .Net 1.1 client. This meant that I had to stop using the xmlblasterappletlib.jar servlet and write my own webservice. Everything is working fine except that I get these annoying java.net.socketexception warnings in the xmlBlaster server console. I don't know why I'm getting these warnings because it doesn't really effect the operation of the client or server (ie. no messages lost or anything). The message is: Jan 21, 2007 4:29:29 PM WARNING 19-XmlBlaster.SOCKET RL10 org.xmlBlaster.protocol.socket.HandleClient run: Error parsing TCP data from '/192.168.1.102:4178', check if client and server have identical compression or SSL settings: java.net.socketException: Software caused connection abort: recv failed So everytime the client publishes a message to the server, I get the above warning on the console. The message reaches it's destination without any problems. Some other relevant details are: 1. Server machine is running Windows XP SP2. 2. Running Apache Tomcat 5.5.15 with a single webservice developed on Netbeans 5.5 3. xmlBlaster 1.4 release. (no cvs versions). 4. webservice and xmlBlaster are on the same machine. 5. Client connects to webservice via SSL, but communication between webservice and xmlBlaster is not using SSL. Actually, I turned of the SSL between the client and webservice and I still get the same message. I don't know. I'm lost. Is it some property that I didn't configure properly or is it something in my code that I didn't do right? Or is it something to do with Tomcat? Any help would be appreciated. Chris. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [xmlblaster] Annoying Warning about recv failed
If you use a positive session id like client/joe/session/1 (or joe/1) you MUST assure that only such client exists, if by mistake two of them get alive they will throw each other out of the server ... Could it be such a behaviour? regards Marcel chris lau wrote: hmm... your points have me thinking Marcel. The chain is correct. The client only sends data to the web service. The data determines what the webservice does. It is the webservice that connects, publishes, retrieves and returns data to the client. Messages are published in PTP mode. 1. I have will have to test. 2. It is only the webservice that talks to the blaster server. Nobody else. 3. This has me thinking that I forgot to close the connection to the server before exiting? - Original Message From: Marcel Ruff [EMAIL PROTECTED] To: xmlblaster@server.xmlBlaster.org Sent: Tuesday, January 23, 2007 3:18:42 AM Subject: Re: [xmlblaster] Annoying Warning about recv failed Hi Chris, i assume this chain: Client C# SOAP/SSL servlet : java xmlBlaster client -SOCKET--- xmlBlaster server Your problem is that the java client looses connection to the server. The exception tells me that the SOCKET connection will be shutdown. As your publish arrives there must be a reconnect behind the scene. I'm quite sure that your java xmlBlaster client has some coding problem or it is another client showing the behaviour. 1. Try to test you client 'standalone' outside of tomcat 2. Who does the reconnect after your lost connection? 3. Can you switch on detailed logging inside tomcat showing the xmlBlaster client lifecycle? thanks Marcel chris lau wrote: Hi, Recently, I moved from a pure Java client to a C# .Net 1.1 client. This meant that I had to stop using the xmlblasterappletlib.jar servlet and write my own webservice. Everything is working fine except that I get these annoying java.net.socketexception warnings in the xmlBlaster server console. I don't know why I'm getting these warnings because it doesn't really effect the operation of the client or server (ie. no messages lost or anything). The message is: Jan 21, 2007 4:29:29 PM WARNING 19-XmlBlaster.SOCKET RL10 org.xmlBlaster.protocol.socket.HandleClient run: Error parsing TCP data from '/192.168.1.102:4178', check if client and server have identical compression or SSL settings: java.net.socketException: Software caused connection abort: recv failed So everytime the client publishes a message to the server, I get the above warning on the console. The message reaches it's destination without any problems. Some other relevant details are: 1. Server machine is running Windows XP SP2. 2. Running Apache Tomcat 5.5.15 with a single webservice developed on Netbeans 5.5 3. xmlBlaster 1.4 release. (no cvs versions). 4. webservice and xmlBlaster are on the same machine. 5. Client connects to webservice via SSL, but communication between webservice and xmlBlaster is not using SSL. Actually, I turned of the SSL between the client and webservice and I still get the same message. I don't know. I'm lost. Is it some property that I didn't configure properly or is it something in my code that I didn't do right? Or is it something to do with Tomcat? Any help would be appreciated. Chris. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [xmlblaster] GPRS / Different IP
Ok, this is now fixed in the current svn, thanks for your patience Marcel Marcel Ruff wrote: Ok, thanks for the details! I will try the case of changing client side IP address with a java client as soon as i find time for it and come back to this issue, thanks for reporting, Marcel Matthew Monson wrote: Hi Marcel, On 11/28/06, *Marcel Ruff* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Matthew Monson wrote: Hello, I'm using xmlBlaster for a GPRS receipting solution which provides the end user with the ability to issue prepaid electricity tokens to a consumer. The message server is running at the local municipality and so is the server providing the token numbers. My problem is that every now and again the GPRS connection drops and the client needs to redial the GSM modem and establish a connection back to VodacomISP, whereby getting a brand new IP address. Unfortunately the client cannot reconnect to the message server unless I exit the application and go back in, basically killing the old connection and creating a new one. The connection does change ALIVE - POLLING, but can never connect to the server after redial and there's nothing happening in the log file on the server. I'm assuming its the IP address because the software works perfectly on a LAN? The IP address of the server (xmlBlaster) is not changing, so you think it is the client side IP address? Yes the client is allocated a different IP address every time it dials up and it's connects to the xmlBlaster server which has a public IP address. Is your client a java software? On which OS? Which xmlBlaster version do you use? Yes it's a java 1.6 app running on Windows XP at the moment. And the server is xmlBlaster 1.2 running on Suse Linux Enterprise 9. This solution is ptp so I managed to kind of get a workaround by just connecting using a different session name eg. machine2/2, and setting the old sessions to expire after 10min, but I'm sure there must be a better way. Yes, this is a hack... I'm using the RAW SOCKET and SSL protocols and passing the message server the same client session name everytime, my question is, what in your opinion should the settings be firstly on the message server and secondly on the client to enable a client with a different IP address to reconnect to an existing session. Could you please try if it runs fine without SSL ? First thing I tried, unfortunately still doesn't reconnect. I also had zlib full stream compression on, but also made no difference. A very simple example of the xmlBlaster.properties and the client arguments would be appreciated as I'm still quite new to xmlBlaster and java. This is a fail save client: java javaclients.HelloWorldSubscribe - session.name http://session.name client/joe/session/1 -dispatch/callback/retries -1 if the server disappears or the network disappears it will automatically reconnect, I also tried this example but the same behaviour occurs. It just doesn't ever reconnect to the server and the server never shows anything in the logs. I've coded the app to retry the connection 5 times and then first disconnect and reconnect again, the server then shows a reconnect coming from a different IP address and port. This should be fine for now but I'm still gonna try using a GPRS router which will have a static IP address and port, maybe it'll make a difference. Thanks, Matthew regards Marcel Thanks, Matthew
Re: [xmlblaster] OSX Testing Errors
/xmlblaster/demo/c/socket/Publisher.c:171: error: 'verbose'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:186: warning: implicit
declaration of function 'strcpyAlloc'
/opt/xmlblaster/demo/c/socket/Publisher.c:201: error: 'subscribable'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:203: error:
'persistentPublish' undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:204: error: 'forceUpdate'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:205: error: 'forceDestroy'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:243: error: 'oneway'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:244: error: 'MsgUnitArr'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:244: error: parse error
before 'msgUnitArr'
/opt/xmlblaster/demo/c/socket/Publisher.c:245: error: 'msgUnitArr'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:252: warning: implicit
declaration of function 'freeMsgUnitData'
/opt/xmlblaster/demo/c/socket/Publisher.c:267: error: 'true'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:269: error: parse error
before 'interactive'
/opt/xmlblaster/demo/c/socket/Publisher.c:279: error: 'QosArr'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:279: error: 'resp'
undeclared (first use in this function)
/opt/xmlblaster/demo/c/socket/Publisher.c:280: warning: ISO C90
forbids mixed declarations and code
/opt/xmlblaster/demo/c/socket/Publisher.c:290: warning: implicit
declaration of function 'freeQosArr'
Compiling (with zlib compression and sqlite queue switched on):
gcc -Wall -pedantic -Wno-long-long -D_REENTRANT -c -g
-DXMLBLASTER_PERSISTENT_QUEUE=1 -DXMLBLASTER_ZLIB=1
-I/home/xmlblast/xmlBlaster/build.tmp/src/c
/home/xmlblast/xmlBlaster/demo/c/socket/Publisher.c
Linking:
gcc -Wl,-rpath=/home/xmlblast/xmlBlaster/lib:/usr/lib64:/usr/lib64 -g -o
Publisher ../../../../build.tmp/objCD/Publisher.o
-L/home/xmlblast/xmlBlaster/lib -lxmlBlasterClientCD -L/usr/lib64
-lsqlite -L/usr/lib64 -lz -lpthread
It is quite simple, you can do it without build or makefile directly
with the above command,
On 1/14/07, Marcel Ruff [EMAIL PROTECTED] wrote:
Rizwan Kassim wrote:
A brand new behavior ...
sudo ./build -verbose -DCFLAGS=-I/usr/lib/malloc clean
sudo ./build -verbose -DCFLAGS=-I/usr/lib/malloc all
(compiles fine, with or without -DCFLAGS=-I/usr/lib/malloc)
sudo ./build -verbose -DCFLAGS=-I/usr/lib/malloc runTests
outputs the mess below in [1].
Any advice?
The linking below:
gcc -g -o Publisher ../../../../build.tmp/objCD/Publisher.o
looks somehow castrated, no libxmlBlasterClientCD.so?
Here are complete examples from my build:
Compiling (with zlib compression and sqlite queue switched on):
gcc -Wall -pedantic -Wno-long-long -D_REENTRANT -c -g
-DXMLBLASTER_PERSISTENT_QUEUE=1 -DXMLBLASTER_ZLIB=1
-I/home/xmlblast/xmlBlaster/build.tmp/src/c
/home/xmlblast/xmlBlaster/demo/c/socket/Publisher.c
Linking:
gcc -Wl,-rpath=/home/xmlblast/xmlBlaster/lib:/usr/lib64:/usr/lib64 -g -o
Publisher ../../../../build.tmp/objCD/Publisher.o
-L/home/xmlblast/xmlBlaster/lib -lxmlBlasterClientCD -L/usr/lib64
-lsqlite -L/usr/lib64 -lz -lpthread
It is quite simple, you can do it without build or makefile directly
with the above command,
Marcel
[1]
compileCExe:
[echo] Compiling of C test client './demo/c/socket/bin/Publisher'
to './demo/c/socket/bin/Publisher'
Property ${LDFLAGS} has not been set
Property ${LDFLAGS} has not been set
Property ${ICC_HOME} has not been set
Property ${ICC_HOME} has not been set
Property ${LDFLAGS} has not been set
Property ${LDFLAGS} has not been set
Property ${LDFLAGS} has not been set
[cc] 1 total files to be compiled.
[cc] gcc -c -g -I/opt/xmlBlaster/build.tmp/src/c
/opt/xmlBlaster/demo/c/socket/Publisher.c
[cc] Starting link
[cc] gcc -g -o Publisher ../../../../build.tmp/objCD/Publisher.o
[cc] /usr/bin/ld: Undefined symbols:
[cc] _freeMsgUnitData
[cc] _freeQosArr
[cc] _freeXmlBlasterAccessUnparsed
[cc] _getXmlBlasterAccessUnparsed
[cc] _getXmlBlasterVersion
[cc] _sleepMillis
[cc] _strcpyAlloc
[cc] _xmlBlasterAccessUnparsedUsage
[cc] _xmlBlasterFree
[cc] collect2: ld returned 1 exit status
[antcall] Exiting /opt/xmlBlaster/build.xml.
BUILD FAILED
/opt/xmlBlaster/build.xml:3076: The following error occurred while
executing this line:
/opt/xmlBlaster/build.xml:3091: gcc failed with return code 1
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:539)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:388)
at
org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:106
