Jon,
If the request is in autocommit, Sequoia will try to close the current
connection, get a new one and retry the query (just in case the
connection was bad and needed to be replaced).
If the query still fails, we need to wait for the answer of all backends
to see if others did succeed. If everyone failed, the error is returned
to the user (usually bad SQL or constraint violation) and everything
continues normally. It is only when we are sure that others have
succeeded that we decide to disable the backend (in force mode). You
should be able to get a 'DISABLING' signal (JMX notification) while the
backend is being disabled. The 'DISABLED' notification is only sent once
notification is complete and this requires all remaining connections to
be terminated (might incur additional TCP timeouts) and in-flight
request/transactions to be canceled/aborted.
Hope this helps,
Emmanuel
After doing more testing, I found that this behavior will actually be
ok, but I still have a question:
It appears that if the connection dies, Sequoia waits until TCP
timeout before returning the results of the attempted query. In other
words, the “Unable to remove task” warning and error messages don’t
occur until after the TCP timeout, whereas if the TCP connection is
reestablished immediately following the failed insert, the warning and
error messages immediately post. Is this the expected behavior?
My initial thoughts were that as soon as the insert fails (times out
and aborts) Sequoia should immediately disable the backend and post
the errors. It appears that the return blocks until a full TCP failure
is detected (assuming a connection failure). Since the backend is
going to be disabled anyway, why does it wait for the TCP timeout
before it changes the state of the backend?
Thanks for all your help,
Jon
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of
*Emmanuel Cecchet
*Sent:* Thursday, September 04, 2008 11:19 AM
*To:* Sequoia general mailing list
*Subject:* Re: [Sequoia] State delay when connection lost
Jonathan,
The speed problem is due to TCP timeouts. The only way to detect an
unplugged cable is to wait for the TCP timeout to expire (JDBC drivers
use TPC connections and Sequoia JDBC driver uses a UDP ping on top of
that).
The TCP timeout depends on your OS settings and are independent of
Sequoia.
Hope this helps,
Emmanuel
When running Sequoia with two backends connected through a 10/100
switch, I pulled the Ethernet cable from one machine. I then did an
insert on the virtual DB. It took about 15 seconds for the controller
to post a failure. Immediately thereafter, I used the console to get
the status of the backend that was disconnected. After typing the
command “show backend *” it took well over a minute for the results to
be posted. I then attempted another insert and the stats immediately
showed after that. I can’t wait for the next write; I need to be able
to know immediately when the controller posts a failure.
I tried the same test using my own console application and the JMX
interface. In my app it simply connects to the JMX server and starts
polling for the backend read/write/initialized status. I got the same
result – it hung for over a minute while trying to poll until I tried
to do another insert. Is there any way to quickly find the state of
the database? I have to notify the users of my software as soon as
Sequoia determines there’s a problem with a backend. I need this
information ASAP. The only thing that I can come up with at this point
is to parse the log entries from the controller, because it seems to
be doing a better job of notifying when there’s a problem. But this
seems hacky, and I don’t want to do it that way.
I want to use JMX to receive notifications from Sequoia when there’s a
problem. I don’t see any notifications being posted. Are there any? If
not, is there a faster way to query that information?
Thanks,
Jonathan Stockho
Software Developer
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
