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
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?
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
Hi! right. > > The leak sneaked in on 2007-06-19. > > Balázs, for the time being you could activate the EventPlugin (for some > dummy events) > to clean up the leak. Already done that, thanks! I figured that to activate the EventPlugin is not a bad idea regardless of this bug. Balázs
Re: [xmlblaster] Re: memory leak with socket sessions
Hi Marcel,
you are right, a cleanup is needed when shutting down the queue.
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
>>
>>
>
>
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
