/key
qosduplicateUpdatesfalse/duplicateUpdates/qos
Note also that after this event, if I restart client #1, it again
starts receiving messages, but xmlBlaster will then start throwing
out NullPointerExceptions very frequently (same as one above) and
the memory consumption starts growing.
--
David
away for the test case, but we encountered
more NPEs when we pointed our development code against it. However,
I noticed there were some more changes this morning, so I did another
update and now with the latest changes, it no longer seems to have
any problems. Thank you!
--
David Kerry
so it should have been deleted
immediately.
Continued restarting of server2/serverlogin will
cause the same message to get continually posted
again and again when it should receive nothing at
all.
--
David Kerry
testpub.pl
Description: Perl program
server2.pl
Description: Perl program
it to clean up properly.
--
David Kerry
server2.pl
Description: Perl program
On Wed, Oct 30, 2002 at 08:50:26AM +0100, Marcel Ruff wrote:
David Kerry wrote:
Ok folks, another volatile message bug...
snip
Hi David,
it is good to have such a volatile tester!
I'm busy the next days but this needs to be resolved a.s.a.p.
thanks for reporting
Marcel
been
in a bit of a rush at the moment, and copy/paste of the older
examples has been my source of code for quick hacking/testing.
As a quick observation, I do note that the xmlBlaster::*.pm
modules seem to be missing subscribe/unsubscribe methods however.
--
David Kerry
this work?
Thanks
--
David Kerry
Ahh... the description sounds perfect for my needs. In all my searching
I missed that one somehow.
I'll give it a go here and see how it works out.
Thanks!
--
David Kerry
On Fri, May 07, 2004 at 07:47:42PM +0200, Michele Laghi wrote:
Hi David,
what you describe should be handled
On Tue, Jun 08, 2004 at 06:08:19PM +0200, Marcel Ruff wrote:
David Kerry wrote:
snip
So I guess the question is - how can I force xmlblaster to check
for dead topics more often and clean them out?
Hi David,
you've summarized it quite exactly already.
The best solution is to use named
receive the messages.
Any ideas? Is this a bug, or am I likely doing something wrong
still?
Oh, fyi - I'm using version 0.901 at the moment.
--
David Kerry
Another way is to switch off history:
java javaclients.HelloWorldPublish -destroyDelay 0
-queue/history/maxEntries 0
).
--
David Kerry ([EMAIL PROTECTED])
[Jun 10, 2004 8:37:46 PM ERROR
XmlBlaster.DispatchWorkerPool.xmlBlaster_172_23_254_15_3412-1
DispatchManager-callback:/node/xmlBlaster_172_23_254_15_3412/client/eds_prod/-12]
Callback failed: errorCode=internal.unknown message=Message 108691426684501
On Fri, Jun 11, 2004 at 10:30:03AM +0200, Marcel Ruff wrote:
Marcel Ruff wrote:
David Kerry wrote:
Hi,
I've been trying out the latest cvs code of xmlblaster and the
following error got thrown out into the log.
After this, one of our clients started misbehaving as well
and restarting
support in my application (parse errors in
xmlblaster header files is the result).
I would recommend renaming those constants (XBLOG_xxx maybe?), or
using the syslog.h versions instead.
--
David Kerry
)
at java.lang.Thread.run(Thread.java:534)
--
David Kerry
)
at org.xmlBlaster.protocol.socket.HandleClient.handleMessage(Han
This was fairly easy to reproduce depending on how long I took to
hit a key in the HelloWorldPublish demo after it published the message,
but before it erased it.
--
David Kerry
,
onAdministrativeCreate=false)
24-May-2006 6:50:13 PM org.xmlBlaster.engine.TopicHandler toDead
FINER: Entering toDead(oldState=UNREFERENCED)
--
David Kerry
)
at java.lang.Thread.run(Thread.java:595)
--
David Kerry
On Thu, May 25, 2006 at 01:54:18PM -0400, David Kerry wrote:
Hello All,
We've managed to quell all the recent exceptions we've been having
with the head version of xmlblaster. However, we're still experiencing
a case of occasional lost
:
java.lang.NullPointerException
Also, since I'm here - any word on resolving some of the other
multi-thread race issues we keep banging into? For some reason,
our access patterns seem to expose them more than anyone else it seems.
--
David Kerry
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?
--
David Kerry
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
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?
--
David Kerry
.
--
David Kerry
and just eliminate the server-side session timeout perhaps?
2) If the client reaches the 'DEAD' state, it shouldn't accept
and queue more messages for publishing that it will never/can never
publish.
--
David Kerry
On Thu, Apr 03, 2008 at 09:32:41AM +0200, Marcel Ruff wrote:
Hi David,
I think
23 matches
Mail list logo
