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] Client never leaves the function XmlblasterAccess.connect
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. 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] 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
[xmlblaster] Client never leaves the function XmlblasterAccess.connect
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.