You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(44) |
Jun
(10) |
Jul
(4) |
Aug
(3) |
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
From: rohit d. <roh...@gm...> - 2011-11-24 16:22:11
|
Hi, I tried to make changes to my client code and also tried running the transactions in serializable isolation level. Although some of the transaction were getting aborted whenever there were conflicts, but in the end it still got stuck again. I have set up the deadlock timeout in postgres but still it doesn't seem to work. I tried running this with different versions of postgres (postgres 7.2, 7.3, 8.0 and 9.0) but no use. So I guess it's probably because of the bug in Sequoia. It can not handle the SELECT...FOR UPDATE statements properly and it needs to be taken care of. Does anyone know how to report the bug for sequoia? You can check this problem by running BenchmarkSql-2.3 ( http://sourceforge.net/projects/benchmarksql/) with Sequoia and two postgres servers. Please let me know if there is any progress in this regard. thank you very much for all the help. Regards, Rohit On Wed, Nov 23, 2011 at 5:28 PM, rohit dhamane <roh...@gm...>wrote: > Hi Emmanuel, > Thanks a lot. That was really helpful reply. I will try to fix the issue > with my client application and see is it works. > > Regards, > Rohit > > > On Wed, Nov 23, 2011 at 5:21 PM, Emmanuel Cecchet <ce...@gm...>wrote: > >> Hi, >> >> Thank you very much for your quick reply emmanuel. I have already tried >> setting the timeout in load balancer but it doesn't work for me I guess :( >> I have been facing this problem with the SELECT.. FOR UPDATE statements. >> While going through the source code of sequoia I found this in >> >> sequoia-2.10.10-src/src/org/continuent/sequoia/controller/requests/SelectRequest.java >> >> public class SelectRequest extends AbstractRequest implements >> Serializable >> { >> private static final long serialVersionUID = 6498520472410320514L; >> >> /** >> * Set to true if this SelectRequest must be broadcasted on the cluster >> * (useful for queries like SELECT FOR UPDATE >> */ >> private boolean mustBroadcast = false; >> <Line 76> >> >> Do I have to change mustBroadcast to true and recompile the sequoia to >> enable it to do SELECT...FOR UPDATE ? >> >> No this value is automatically set by the parser. When the select >> statement is parsed, it is considered as a write on the table and is >> broadcast to all databases to acquire a write lock. >> >> >> Also, here's the request log from a similar test (it again got stuck at >> same point) . >> I apologize for copy pasting the entire log here. >> >> 06:42:10,221 DEBUG controller.core.PingResponder Response to ping sent >> to /127.0.0.1 >> 06:42:11,207 DEBUG controller.core.PingResponder Received ping data from / >> 127.0.0.1 >> 06:42:11,207 DEBUG controller.core.PingResponder Response to ping sent to >> /127.0.0.1 >> 06:42:12,351 DEBUG sequoia.controller.loadbalancer Building wait-for >> graph... >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer warehouse locked by 13 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer new_order locked by 12 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer district locked by 13 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer Walking wait-for >> graph... >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 17 waits for new_order >> locked by 12 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for >> district locked by 13 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 15 waits for new_order >> locked by 12 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for >> district locked by 13 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 14 waits for warehouse >> locked by 13 >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer Choosing victim node... >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer 0 cycles detected >> 06:42:12,352 DEBUG sequoia.controller.loadbalancer No victim >> >> Looks like transaction 13 is not completing. I have reduced your log to >> the incriminating transactions below: >> >> >> *Request.log* >> >> 06:41:26,450 tpcw B 12 >> 06:41:26,450 tpcw S 175 12 SELECT c_discount, c_last, c_credit, w_tax >> FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? >> AND c_id = ?/<!%I|1|!%><!%I|4|!%><!%I|1258|!%> >> 06:41:26,664 tpcw S 178 12 SELECT d_next_o_id, d_tax FROM district WHERE >> d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|4|!%><!%I|1|!%> >> 06:41:26,673 tpcw W 179 12 INSERT INTO NEW_ORDER (no_o_id, no_d_id, >> no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|4|!%><!%I|1|!%> >> 06:41:26,917 tpcw W 181 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd >> + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = >> ?/<!%I|71|!%><!%I|2|!%><!%I|0|!%><!%I|92253|!%><!%I|2|!%> >> 06:41:27,633 tpcw B 13 >> 06:41:27,633 tpcw W 188 13 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE >> w_id = ?/<!%F|56.68|!%><!%I|1|!%> >> 06:41:27,680 tpcw S 190 13 SELECT w_street_1, w_street_2, w_city, >> w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|1|!%> >> 06:41:27,681 tpcw W 191 13 UPDATE district SET d_ytd = d_ytd + ? WHERE >> d_w_id = ? AND d_id = ?/<!%F|56.68|!%><!%I|1|!%><!%I|4|!%> >> 06:41:28,664 tpcw B 14 >> 06:41:28,664 tpcw W 204 14 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE >> w_id = ?/<!%F|4539.02|!%><!%I|2|!%> >> 06:41:30,433 tpcw B 15 >> 06:41:30,433 tpcw S 226 15 SELECT c_discount, c_last, c_credit, w_tax >> FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? >> AND c_id = ?/<!%I|3|!%><!%I|2|!%><!%I|2751|!%> >> 06:41:30,500 tpcw S 231 15 SELECT d_next_o_id, d_tax FROM district WHERE >> d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|3|!%> >> 06:41:30,512 tpcw W 233 15 INSERT INTO NEW_ORDER (no_o_id, no_d_id, >> no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|3|!%> >> 06:41:32,424 tpcw B 17 >> 06:41:32,424 tpcw S 249 17 SELECT c_discount, c_last, c_credit, w_tax >> FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? >> AND c_id = ?/<!%I|2|!%><!%I|2|!%><!%I|1676|!%> >> 06:41:32,487 tpcw S 250 17 SELECT d_next_o_id, d_tax FROM district WHERE >> d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|2|!%> >> 06:41:32,489 tpcw W 251 17 INSERT INTO NEW_ORDER (no_o_id, no_d_id, >> no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|2|!%> >> >> >> I found the problem. The lock that transaction 12 acquired on the >> district table (in its select for update) has not been properly added and >> the deadlock has not been detected. >> So on one side, Sequoia has a bug with not properly updating its lock >> table on this select for update (the query parsing code might have an >> issue). >> On the other side, your transactions are not serializable and they >> deadlock (the application should be fixed). By serialiazing writes per >> table, Sequoia exposes these bugs faster than if you were running directly >> on top of the database (but you should be able to obtain the same deadlock >> directly on the database). Actually is stuck on the database deadlock. I >> don't remember if the version of Postgres you are using has a global >> transaction timeout that you can set so that Postgres would kill the >> deadlocked transactions itself (quick fix). >> >> Hope this helps >> Emmanuel >> >> >> >> On Wed, Nov 23, 2011 at 3:09 PM, Emmanuel Cecchet <ce...@gm...>wrote: >> >>> Hi, >>> >>> From your log it looks like everyone is waiting for that transaction 65 >>> to either commit or rollback. >>> If your thread has crashed and there is no rollback or connection >>> closing in a catch block, all the locks are going to be retained forever >>> (thought there is a possibility to set timeout on transactions in the load >>> balancer settings if I recall). >>> Without the log of the exact requests, it's hard to tell you more than >>> that. >>> >>> Keep us posted with your findings, >>> Emmanuel >>> >>> >>> On 11/23/2011 06:30, rohit dhamane wrote: >>> >>> Hi, >>> >>> I have been facing some problem with sequoia. I am trying to run >>> BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with >>> sequoia over two postgresql-7.3 servers but it seems to get stuck >>> indefinitely at the same point. I think it's happening because of the >>> SELECT...FOR UPDATE but not really sure how :( It seems that the >>> transactions are getting into a deadlock. Here's the out put when I turned >>> on the debug mode. >>> >>> 02:56:49,388 DEBUG controller.core.PingResponder Received ping data >>> from /127.0.0.1 >>> 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent >>> to /127.0.0.1 >>> 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for >>> graph... >>> 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 >>> 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 >>> 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 >>> 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for >>> graph... >>> 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for district >>> locked by 65 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for >>> new_order locked by 64 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for >>> district locked by 65 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for >>> warehouse locked by 65 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for >>> new_order locked by 64 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for >>> district locked by 65 >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim >>> node... >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected >>> 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim >>> 02:56:50,389 DEBUG controller.core.PingResponder Received ping data from >>> /127.0.0.1 >>> 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent >>> to /127.0.0.1 >>> >>> >>> >>> Here's my configuration file.. >>> >>> <?xml version="1.0" encoding="UTF-8"?>^M >>> <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" " >>> http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M >>> ^M >>> <SEQUOIA>^M >>> ^M >>> <VirtualDatabase name="tpcw">^M >>> ^M >>> <AuthenticationManager>^M >>> <Admin>^M >>> <User username="postgres" password=""/>^M >>> </Admin> ^M >>> <VirtualUsers>^M >>> <VirtualLogin vLogin="postgres" vPassword=""/>^M >>> </VirtualUsers>^M >>> </AuthenticationManager>^M >>> ^M >>> <DatabaseBackend name="localhost" driver="org.postgresql.Driver" >>> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >>> url="jdbc:postgresql://localhost:6551/tpcw" connectionTestStatement="select >>> now()">^M >>> >>> <ConnectionManager vLogin="postgres" rLogin="postgres" >>> rPassword="">^M >>> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >>> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >>> </ConnectionManager>^M >>> </DatabaseBackend>^M >>> ^M >>> <DatabaseBackend name="Remote" driver="org.postgresql.Driver" >>> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >>> url="jdbc:postgresql://192.168.164.136:6552/tpcw" >>> connectionTestStatement="select now()">^M >>> <ConnectionManager vLogin="postgres" rLogin="postgres" >>> rPassword="">^M >>> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >>> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >>> </ConnectionManager>^M >>> </DatabaseBackend>^M >>> <RequestManager>^M >>> <RequestScheduler>^M >>> <RAIDb-1Scheduler level="passThrough"/>^M >>> </RequestScheduler>^M >>> ^M >>> <RequestCache>^M >>> <MetadataCache/>^M >>> <ParsingCache/> ^M >>> <ResultCache granularity="table" />^M >>> </RequestCache>^M >>> ^M >>> <LoadBalancer transactionIsolation="serializable">^M >>> <RAIDb-1>^M >>> <WaitForCompletion policy="all" >>> deadlockTimeoutInMs="30000"/>^M >>> <RAIDb-1-RoundRobin/>^M >>> </RAIDb-1>^M >>> </LoadBalancer>^M >>> </RequestManager>^M >>> ^M >>> </VirtualDatabase>^M >>> ^M >>> </SEQUOIA>^M >>> >>> If anybody has anu idea why this happens please let me know. I would >>> appreciate it a lot. Thanks in advance. >>> >>> Regards, >>> Rohit >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense.http://p.sf.net/sfu/splunk-novd2d >>> >>> >>> >>> _______________________________________________ >>> Sequoiadb-discuss mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss >>> >>> >>> >> >> > |
From: rohit d. <roh...@gm...> - 2011-11-23 16:29:22
|
Hi Emmanuel, Thanks a lot. That was really helpful reply. I will try to fix the issue with my client application and see is it works. Regards, Rohit On Wed, Nov 23, 2011 at 5:21 PM, Emmanuel Cecchet <ce...@gm...> wrote: > Hi, > > Thank you very much for your quick reply emmanuel. I have already tried > setting the timeout in load balancer but it doesn't work for me I guess :( > I have been facing this problem with the SELECT.. FOR UPDATE statements. > While going through the source code of sequoia I found this in > > sequoia-2.10.10-src/src/org/continuent/sequoia/controller/requests/SelectRequest.java > > public class SelectRequest extends AbstractRequest implements > Serializable > { > private static final long serialVersionUID = 6498520472410320514L; > > /** > * Set to true if this SelectRequest must be broadcasted on the cluster > * (useful for queries like SELECT FOR UPDATE > */ > private boolean mustBroadcast = false; > <Line 76> > > Do I have to change mustBroadcast to true and recompile the sequoia to > enable it to do SELECT...FOR UPDATE ? > > No this value is automatically set by the parser. When the select > statement is parsed, it is considered as a write on the table and is > broadcast to all databases to acquire a write lock. > > > Also, here's the request log from a similar test (it again got stuck at > same point) . > I apologize for copy pasting the entire log here. > > 06:42:10,221 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 > 06:42:11,207 DEBUG controller.core.PingResponder Received ping data from / > 127.0.0.1 > 06:42:11,207 DEBUG controller.core.PingResponder Response to ping sent to / > 127.0.0.1 > 06:42:12,351 DEBUG sequoia.controller.loadbalancer Building wait-for > graph... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer warehouse locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer new_order locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer Walking wait-for > graph... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 17 waits for new_order > locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for > district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 15 waits for new_order > locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for > district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 14 waits for warehouse > locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer Choosing victim node... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 0 cycles detected > 06:42:12,352 DEBUG sequoia.controller.loadbalancer No victim > > Looks like transaction 13 is not completing. I have reduced your log to > the incriminating transactions below: > > > *Request.log* > > 06:41:26,450 tpcw B 12 > 06:41:26,450 tpcw S 175 12 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? > AND c_id = ?/<!%I|1|!%><!%I|4|!%><!%I|1258|!%> > 06:41:26,664 tpcw S 178 12 SELECT d_next_o_id, d_tax FROM district WHERE > d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|4|!%><!%I|1|!%> > 06:41:26,673 tpcw W 179 12 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|4|!%><!%I|1|!%> > 06:41:26,917 tpcw W 181 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd > + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = > ?/<!%I|71|!%><!%I|2|!%><!%I|0|!%><!%I|92253|!%><!%I|2|!%> > 06:41:27,633 tpcw B 13 > 06:41:27,633 tpcw W 188 13 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE > w_id = ?/<!%F|56.68|!%><!%I|1|!%> > 06:41:27,680 tpcw S 190 13 SELECT w_street_1, w_street_2, w_city, w_state, > w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|1|!%> > 06:41:27,681 tpcw W 191 13 UPDATE district SET d_ytd = d_ytd + ? WHERE > d_w_id = ? AND d_id = ?/<!%F|56.68|!%><!%I|1|!%><!%I|4|!%> > 06:41:28,664 tpcw B 14 > 06:41:28,664 tpcw W 204 14 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE > w_id = ?/<!%F|4539.02|!%><!%I|2|!%> > 06:41:30,433 tpcw B 15 > 06:41:30,433 tpcw S 226 15 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? > AND c_id = ?/<!%I|3|!%><!%I|2|!%><!%I|2751|!%> > 06:41:30,500 tpcw S 231 15 SELECT d_next_o_id, d_tax FROM district WHERE > d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|3|!%> > 06:41:30,512 tpcw W 233 15 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|3|!%> > 06:41:32,424 tpcw B 17 > 06:41:32,424 tpcw S 249 17 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? > AND c_id = ?/<!%I|2|!%><!%I|2|!%><!%I|1676|!%> > 06:41:32,487 tpcw S 250 17 SELECT d_next_o_id, d_tax FROM district WHERE > d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|2|!%> > 06:41:32,489 tpcw W 251 17 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|2|!%> > > > I found the problem. The lock that transaction 12 acquired on the district > table (in its select for update) has not been properly added and the > deadlock has not been detected. > So on one side, Sequoia has a bug with not properly updating its lock > table on this select for update (the query parsing code might have an > issue). > On the other side, your transactions are not serializable and they > deadlock (the application should be fixed). By serialiazing writes per > table, Sequoia exposes these bugs faster than if you were running directly > on top of the database (but you should be able to obtain the same deadlock > directly on the database). Actually is stuck on the database deadlock. I > don't remember if the version of Postgres you are using has a global > transaction timeout that you can set so that Postgres would kill the > deadlocked transactions itself (quick fix). > > Hope this helps > Emmanuel > > > > On Wed, Nov 23, 2011 at 3:09 PM, Emmanuel Cecchet <ce...@gm...>wrote: > >> Hi, >> >> From your log it looks like everyone is waiting for that transaction 65 >> to either commit or rollback. >> If your thread has crashed and there is no rollback or connection closing >> in a catch block, all the locks are going to be retained forever (thought >> there is a possibility to set timeout on transactions in the load balancer >> settings if I recall). >> Without the log of the exact requests, it's hard to tell you more than >> that. >> >> Keep us posted with your findings, >> Emmanuel >> >> >> On 11/23/2011 06:30, rohit dhamane wrote: >> >> Hi, >> >> I have been facing some problem with sequoia. I am trying to run >> BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with >> sequoia over two postgresql-7.3 servers but it seems to get stuck >> indefinitely at the same point. I think it's happening because of the >> SELECT...FOR UPDATE but not really sure how :( It seems that the >> transactions are getting into a deadlock. Here's the out put when I turned >> on the debug mode. >> >> 02:56:49,388 DEBUG controller.core.PingResponder Received ping data >> from /127.0.0.1 >> 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent to >> /127.0.0.1 >> 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for >> graph... >> 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for >> graph... >> 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for district >> locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for new_order >> locked by 64 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for >> district locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for warehouse >> locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for new_order >> locked by 64 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for >> district locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim node... >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim >> 02:56:50,389 DEBUG controller.core.PingResponder Received ping data from / >> 127.0.0.1 >> 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent to >> /127.0.0.1 >> >> >> >> Here's my configuration file.. >> >> <?xml version="1.0" encoding="UTF-8"?>^M >> <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" " >> http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M >> ^M >> <SEQUOIA>^M >> ^M >> <VirtualDatabase name="tpcw">^M >> ^M >> <AuthenticationManager>^M >> <Admin>^M >> <User username="postgres" password=""/>^M >> </Admin> ^M >> <VirtualUsers>^M >> <VirtualLogin vLogin="postgres" vPassword=""/>^M >> </VirtualUsers>^M >> </AuthenticationManager>^M >> ^M >> <DatabaseBackend name="localhost" driver="org.postgresql.Driver" >> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >> url="jdbc:postgresql://localhost:6551/tpcw" connectionTestStatement="select >> now()">^M >> >> <ConnectionManager vLogin="postgres" rLogin="postgres" >> rPassword="">^M >> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >> </ConnectionManager>^M >> </DatabaseBackend>^M >> ^M >> <DatabaseBackend name="Remote" driver="org.postgresql.Driver" >> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >> url="jdbc:postgresql://192.168.164.136:6552/tpcw" >> connectionTestStatement="select now()">^M >> <ConnectionManager vLogin="postgres" rLogin="postgres" >> rPassword="">^M >> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >> </ConnectionManager>^M >> </DatabaseBackend>^M >> <RequestManager>^M >> <RequestScheduler>^M >> <RAIDb-1Scheduler level="passThrough"/>^M >> </RequestScheduler>^M >> ^M >> <RequestCache>^M >> <MetadataCache/>^M >> <ParsingCache/> ^M >> <ResultCache granularity="table" />^M >> </RequestCache>^M >> ^M >> <LoadBalancer transactionIsolation="serializable">^M >> <RAIDb-1>^M >> <WaitForCompletion policy="all" >> deadlockTimeoutInMs="30000"/>^M >> <RAIDb-1-RoundRobin/>^M >> </RAIDb-1>^M >> </LoadBalancer>^M >> </RequestManager>^M >> ^M >> </VirtualDatabase>^M >> ^M >> </SEQUOIA>^M >> >> If anybody has anu idea why this happens please let me know. I would >> appreciate it a lot. Thanks in advance. >> >> Regards, >> Rohit >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense.http://p.sf.net/sfu/splunk-novd2d >> >> >> >> _______________________________________________ >> Sequoiadb-discuss mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss >> >> >> > > |
From: Emmanuel C. <ce...@gm...> - 2011-11-23 16:21:26
|
Hi, > Thank you very much for your quick reply emmanuel. I have already > tried setting the timeout in load balancer but it doesn't work for me > I guess :( > I have been facing this problem with the SELECT.. FOR UPDATE > statements. While going through the source code of sequoia I found > this in > sequoia-2.10.10-src/src/org/continuent/sequoia/controller/requests/SelectRequest.java > > > public class SelectRequest extends AbstractRequest implements Serializable > { > private static final long serialVersionUID = 6498520472410320514L; > > /** > * Set to true if this SelectRequest must be broadcasted on the cluster > * (useful for queries like SELECT FOR UPDATE > */ > private boolean mustBroadcast =false; <Line 76> > > Do I have to change mustBroadcast to true and recompile the sequoia to > enable it to do SELECT...FOR UPDATE ? No this value is automatically set by the parser. When the select statement is parsed, it is considered as a write on the table and is broadcast to all databases to acquire a write lock. > > Also, here's the request log from a similar test (it again got stuck > at same point) . > I apologize for copy pasting the entire log here. > > 06:42:10,221 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > 06:42:11,207 DEBUG controller.core.PingResponder Received ping data > from /127.0.0.1 <http://127.0.0.1> > 06:42:11,207 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > 06:42:12,351 DEBUG sequoia.controller.loadbalancer Building wait-for > graph... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer warehouse locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer new_order locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer Walking wait-for > graph... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 17 waits for > new_order locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for > district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 15 waits for > new_order locked by 12 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for > district locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 14 waits for > warehouse locked by 13 > 06:42:12,352 DEBUG sequoia.controller.loadbalancer Choosing victim node... > 06:42:12,352 DEBUG sequoia.controller.loadbalancer 0 cycles detected > 06:42:12,352 DEBUG sequoia.controller.loadbalancer No victim Looks like transaction 13 is not completing. I have reduced your log to the incriminating transactions below: > > *_Request.log_* > > 06:41:26,450 tpcw B 12 > 06:41:26,450 tpcw S 175 12 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id > = ? AND c_id = ?/<!%I|1|!%><!%I|4|!%><!%I|1258|!%> > 06:41:26,664 tpcw S 178 12 SELECT d_next_o_id, d_tax FROM district > WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|4|!%><!%I|1|!%> > 06:41:26,673 tpcw W 179 12 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|4|!%><!%I|1|!%> > 06:41:26,917 tpcw W 181 0 UPDATE stock SET s_quantity = ? , s_ytd = > s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND > s_w_id = ?/<!%I|71|!%><!%I|2|!%><!%I|0|!%><!%I|92253|!%><!%I|2|!%> > 06:41:27,633 tpcw B 13 > 06:41:27,633 tpcw W 188 13 UPDATE warehouse SET w_ytd = w_ytd + ? > WHERE w_id = ?/<!%F|56.68|!%><!%I|1|!%> > 06:41:27,680 tpcw S 190 13 SELECT w_street_1, w_street_2, w_city, > w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|1|!%> > 06:41:27,681 tpcw W 191 13 UPDATE district SET d_ytd = d_ytd + ? WHERE > d_w_id = ? AND d_id = ?/<!%F|56.68|!%><!%I|1|!%><!%I|4|!%> > 06:41:28,664 tpcw B 14 > 06:41:28,664 tpcw W 204 14 UPDATE warehouse SET w_ytd = w_ytd + ? > WHERE w_id = ?/<!%F|4539.02|!%><!%I|2|!%> > 06:41:30,433 tpcw B 15 > 06:41:30,433 tpcw S 226 15 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id > = ? AND c_id = ?/<!%I|3|!%><!%I|2|!%><!%I|2751|!%> > 06:41:30,500 tpcw S 231 15 SELECT d_next_o_id, d_tax FROM district > WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|3|!%> > 06:41:30,512 tpcw W 233 15 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|3|!%> > 06:41:32,424 tpcw B 17 > 06:41:32,424 tpcw S 249 17 SELECT c_discount, c_last, c_credit, w_tax > FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id > = ? AND c_id = ?/<!%I|2|!%><!%I|2|!%><!%I|1676|!%> > 06:41:32,487 tpcw S 250 17 SELECT d_next_o_id, d_tax FROM district > WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|2|!%> > 06:41:32,489 tpcw W 251 17 INSERT INTO NEW_ORDER (no_o_id, no_d_id, > no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|2|!%> I found the problem. The lock that transaction 12 acquired on the district table (in its select for update) has not been properly added and the deadlock has not been detected. So on one side, Sequoia has a bug with not properly updating its lock table on this select for update (the query parsing code might have an issue). On the other side, your transactions are not serializable and they deadlock (the application should be fixed). By serialiazing writes per table, Sequoia exposes these bugs faster than if you were running directly on top of the database (but you should be able to obtain the same deadlock directly on the database). Actually is stuck on the database deadlock. I don't remember if the version of Postgres you are using has a global transaction timeout that you can set so that Postgres would kill the deadlocked transactions itself (quick fix). Hope this helps Emmanuel > > On Wed, Nov 23, 2011 at 3:09 PM, Emmanuel Cecchet <ce...@gm... > <mailto:ce...@gm...>> wrote: > > Hi, > > From your log it looks like everyone is waiting for that > transaction 65 to either commit or rollback. > If your thread has crashed and there is no rollback or connection > closing in a catch block, all the locks are going to be retained > forever (thought there is a possibility to set timeout on > transactions in the load balancer settings if I recall). > Without the log of the exact requests, it's hard to tell you more > than that. > > Keep us posted with your findings, > Emmanuel > > > On 11/23/2011 06:30, rohit dhamane wrote: >> Hi, >> >> I have been facing some problem with sequoia. I am trying to run >> BenchmarkSql-2.3 >> (http://sourceforge.net/projects/benchmarksql/) with sequoia over >> two postgresql-7.3 servers but it seems to get stuck indefinitely >> at the same point. I think it's happening because of the >> SELECT...FOR UPDATE but not really sure how :( It seems that the >> transactions are getting into a deadlock. Here's the out put when >> I turned on the debug mode. >> >> 02:56:49,388 DEBUG controller.core.PingResponder Received ping >> data from /127.0.0.1 <http://127.0.0.1> >> 02:56:49,388 DEBUG controller.core.PingResponder Response to ping >> sent to /127.0.0.1 <http://127.0.0.1> >> 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building >> wait-for graph... >> 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order >> locked by 64 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer district >> locked by 65 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse >> locked by 65 >> 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking >> wait-for graph... >> 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for >> district locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for >> new_order locked by 64 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits >> for district locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for >> warehouse locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for >> new_order locked by 64 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits >> for district locked by 65 >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing >> victim node... >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected >> 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim >> 02:56:50,389 DEBUG controller.core.PingResponder Received ping >> data from /127.0.0.1 <http://127.0.0.1> >> 02:56:50,389 DEBUG controller.core.PingResponder Response to ping >> sent to /127.0.0.1 <http://127.0.0.1> >> >> >> >> Here's my configuration file.. >> >> <?xml version="1.0" encoding="UTF-8"?>^M >> <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA >> @VERSION@//EN" >> "http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M >> ^M >> <SEQUOIA>^M >> ^M >> <VirtualDatabase name="tpcw">^M >> ^M >> <AuthenticationManager>^M >> <Admin>^M >> <User username="postgres" password=""/>^M >> </Admin> ^M >> <VirtualUsers>^M >> <VirtualLogin vLogin="postgres" vPassword=""/>^M >> </VirtualUsers>^M >> </AuthenticationManager>^M >> ^M >> <DatabaseBackend name="localhost" driver="org.postgresql.Driver" >> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >> url="jdbc:postgresql://localhost:6551/tpcw" >> connectionTestStatement="select now()">^M >> >> <ConnectionManager vLogin="postgres" rLogin="postgres" >> rPassword="">^M >> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >> </ConnectionManager>^M >> </DatabaseBackend>^M >> ^M >> <DatabaseBackend name="Remote" driver="org.postgresql.Driver" >> driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" >> url="jdbc:postgresql://192.168.164.136:6552/tpcw >> <http://192.168.164.136:6552/tpcw>" >> connectionTestStatement="select now()">^M >> <ConnectionManager vLogin="postgres" rLogin="postgres" >> rPassword="">^M >> <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" >> maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M >> </ConnectionManager>^M >> </DatabaseBackend>^M >> <RequestManager>^M >> <RequestScheduler>^M >> <RAIDb-1Scheduler level="passThrough"/>^M >> </RequestScheduler>^M >> ^M >> <RequestCache>^M >> <MetadataCache/>^M >> <ParsingCache/> ^M >> <ResultCache granularity="table" />^M >> </RequestCache>^M >> ^M >> <LoadBalancer transactionIsolation="serializable">^M >> <RAIDb-1>^M >> <WaitForCompletion policy="all" >> deadlockTimeoutInMs="30000"/>^M >> <RAIDb-1-RoundRobin/>^M >> </RAIDb-1>^M >> </LoadBalancer>^M >> </RequestManager>^M >> ^M >> </VirtualDatabase>^M >> ^M >> </SEQUOIA>^M >> >> If anybody has anu idea why this happens please let me know. I >> would appreciate it a lot. Thanks in advance. >> >> Regards, >> Rohit >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> >> >> _______________________________________________ >> Sequoiadb-discuss mailing list >> Seq...@li... <mailto:Seq...@li...> >> https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss > > |
From: rohit d. <roh...@gm...> - 2011-11-23 14:56:46
|
Hi, Thank you very much for your quick reply emmanuel. I have already tried setting the timeout in load balancer but it doesn't work for me I guess :( I have been facing this problem with the SELECT.. FOR UPDATE statements. While going through the source code of sequoia I found this in sequoia-2.10.10-src/src/org/continuent/sequoia/controller/requests/SelectRequest.java public class SelectRequest extends AbstractRequest implements Serializable { private static final long serialVersionUID = 6498520472410320514L; /** * Set to true if this SelectRequest must be broadcasted on the cluster * (useful for queries like SELECT FOR UPDATE */ private boolean mustBroadcast = false; <Line 76> Do I have to change mustBroadcast to true and recompile the sequoia to enable it to do SELECT...FOR UPDATE ? Also, here's the request log from a similar test (it again got stuck at same point) . I apologize for copy pasting the entire log here. 06:42:10,221 DEBUG controller.core.PingResponder Response to ping sent to / 127.0.0.1 06:42:11,207 DEBUG controller.core.PingResponder Received ping data from / 127.0.0.1 06:42:11,207 DEBUG controller.core.PingResponder Response to ping sent to / 127.0.0.1 06:42:12,351 DEBUG sequoia.controller.loadbalancer Building wait-for graph... 06:42:12,352 DEBUG sequoia.controller.loadbalancer warehouse locked by 13 06:42:12,352 DEBUG sequoia.controller.loadbalancer new_order locked by 12 06:42:12,352 DEBUG sequoia.controller.loadbalancer district locked by 13 06:42:12,352 DEBUG sequoia.controller.loadbalancer Walking wait-for graph... 06:42:12,352 DEBUG sequoia.controller.loadbalancer 17 waits for new_order locked by 12 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for district locked by 13 06:42:12,352 DEBUG sequoia.controller.loadbalancer 15 waits for new_order locked by 12 06:42:12,352 DEBUG sequoia.controller.loadbalancer 12 waits for district locked by 13 06:42:12,352 DEBUG sequoia.controller.loadbalancer 14 waits for warehouse locked by 13 06:42:12,352 DEBUG sequoia.controller.loadbalancer Choosing victim node... 06:42:12,352 DEBUG sequoia.controller.loadbalancer 0 cycles detected 06:42:12,352 DEBUG sequoia.controller.loadbalancer No victim *Request.log* 06:41:10,856 tpcw B 0 06:41:10,856 tpcw B 1 06:41:10,857 tpcw B 2 06:41:10,857 tpcw B 3 06:41:10,858 tpcw B 4 06:41:10,866 tpcw S 0 2 SELECT d_next_o_id FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|1|!%><!%I|5|!%> 06:41:10,867 tpcw S 1 1 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|1|!%><!%I|9|!%><!%I|2895|!%> 06:41:10,868 tpcw W 2 3 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|2224.39|!%><!%I|3|!%> 06:41:10,869 tpcw W 3 4 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|3794.01|!%><!%I|2|!%> 06:41:10,894 tpcw S 4 0 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|2|!%><!%I|8|!%><!%I|1673|!%> 06:41:11,616 tpcw S 5 2 SELECT COUNT(DISTINCT (s_i_id)) AS stock_count FROM order_line, stock WHERE ol_w_id = ? AND ol_d_id = ? AND ol_o_id < ? AND ol_o_id >= ? - 20 AND s_w_id = ? AND s_i_id = ol_i_id AND s_quantity < ?/<!%I|1|!%><!%I|5|!%><!%I|3001|!%><!%I|3001|!%><!%I|1|!%><!%I|10|!%> 06:41:11,620 tpcw S 6 3 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|3|!%> 06:41:11,628 tpcw S 7 4 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|2|!%> 06:41:11,629 tpcw W 8 3 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|2224.39|!%><!%I|3|!%><!%I|3|!%> 06:41:11,634 tpcw W 9 4 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|3794.01|!%><!%I|2|!%><!%I|3|!%> 06:41:11,640 tpcw S 10 1 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|9|!%><!%I|1|!%> 06:41:11,649 tpcw S 11 3 SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|3|!%><!%I|3|!%> 06:41:11,659 tpcw S 12 4 SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|2|!%><!%I|3|!%> 06:41:11,660 tpcw S 13 3 SELECT c_first, c_middle, c_last, c_street_1, c_street_2, c_city, c_state, c_zip, c_phone, c_credit, c_credit_lim, c_discount, c_balance, c_since FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%I|1|!%><!%I|7|!%><!%I|2065|!%> 06:41:11,671 tpcw S 14 4 SELECT c_first, c_middle, c_last, c_street_1, c_street_2, c_city, c_state, c_zip, c_phone, c_credit, c_credit_lim, c_discount, c_balance, c_since FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%I|2|!%><!%I|3|!%><!%I|556|!%> 06:41:11,677 tpcw W 15 1 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%> 06:41:11,682 tpcw W 16 1 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|9|!%><!%I|1|!%> 06:41:11,688 tpcw W 17 1 INSERT INTO OORDER (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?, ?, ?, ?, ?, ?, ?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|2895|!%><!%T|2011-11-23 06:41:11.687|!%><!%I|15|!%><!%I|1|!%> 06:41:11,736 tpcw S 18 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|59171|!%> 06:41:11,792 tpcw S 19 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|59171|!%><!%I|1|!%> 06:41:12,065 tpcw W 20 4 UPDATE customer SET c_balance = ? WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%F|3784.01|!%><!%I|2|!%><!%I|3|!%><!%I|556|!%> 06:41:12,097 tpcw S 21 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|70974|!%> 06:41:14,573 tpcw S 22 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|70974|!%><!%I|1|!%> 06:41:14,725 tpcw S 23 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|98499|!%> 06:41:14,757 tpcw S 24 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|98499|!%><!%I|1|!%> 06:41:14,803 tpcw C 2 06:41:14,830 tpcw B 5 06:41:14,830 tpcw S 25 5 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|1|!%><!%I|6|!%><!%I|1768|!%> 06:41:14,942 tpcw S 26 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|13039|!%> 06:41:14,974 tpcw S 27 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|13039|!%><!%I|1|!%> 06:41:14,975 tpcw S 28 5 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|6|!%><!%I|1|!%> 06:41:14,990 tpcw W 29 5 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%> 06:41:15,150 tpcw S 30 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|31245|!%> 06:41:15,151 tpcw W 31 5 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|6|!%><!%I|1|!%> 06:41:15,182 tpcw S 32 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|31245|!%><!%I|1|!%> 06:41:15,716 tpcw S 33 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|34982|!%> 06:41:16,059 tpcw S 34 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|34982|!%><!%I|1|!%> 06:41:16,188 tpcw S 35 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|88369|!%> 06:41:16,226 tpcw S 36 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|88369|!%><!%I|1|!%> 06:41:16,364 tpcw S 37 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|44082|!%> 06:41:16,400 tpcw S 38 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|44082|!%><!%I|1|!%> 06:41:16,532 tpcw S 39 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|33528|!%> 06:41:16,564 tpcw S 40 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|33528|!%><!%I|1|!%> 06:41:16,692 tpcw S 41 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|73682|!%> 06:41:16,774 tpcw S 42 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|73682|!%><!%I|1|!%> 06:41:16,901 tpcw S 43 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|35368|!%> 06:41:16,932 tpcw S 44 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|35368|!%><!%I|1|!%> 06:41:17,060 tpcw S 45 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|95292|!%> 06:41:17,120 tpcw S 46 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|95292|!%><!%I|1|!%> 06:41:17,248 tpcw S 47 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|39205|!%> 06:41:17,274 tpcw S 48 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|39205|!%><!%I|1|!%> 06:41:17,399 tpcw S 49 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|4967|!%> 06:41:17,467 tpcw S 50 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|4967|!%><!%I|1|!%> 06:41:17,598 tpcw S 51 1 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|78394|!%> 06:41:17,632 tpcw S 52 1 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|78394|!%><!%I|1|!%> 06:41:17,756 tpcw W 53 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|1|!%><!%I|59171|!%><!%I|1|!%><!%I|5|!%><!%F|151.40001|!%><!%S|vrcLlgBRQAuvuzOAZJsAzoy |!%> 06:41:17,842 tpcw W 54 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|2|!%><!%I|70974|!%><!%I|1|!%><!%I|1|!%><!%F|86.49|!%><!%S|pZcZaRLCyFcnowFdPfxPDBQ |!%> 06:41:17,844 tpcw W 55 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|3|!%><!%I|98499|!%><!%I|1|!%><!%I|9|!%><!%F|485.82|!%><!%S|fUWwSWEyPCRMotSjkebxENF |!%> 06:41:17,857 tpcw W 56 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|4|!%><!%I|13039|!%><!%I|1|!%><!%I|1|!%><!%F|62.54|!%><!%S|UVHyzcSZfKMYWXcVhVnalwe |!%> 06:41:17,864 tpcw W 57 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|5|!%><!%I|31245|!%><!%I|1|!%><!%I|4|!%><!%F|92.72|!%><!%S|ANhLAfQaCQyCeAmdfcDOjEW |!%> 06:41:17,893 tpcw W 58 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|6|!%><!%I|34982|!%><!%I|1|!%><!%I|9|!%><!%F|124.65|!%><!%S|oJnlvWOnGqrLqitJIrpjpAQ |!%> 06:41:17,895 tpcw W 59 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|7|!%><!%I|88369|!%><!%I|1|!%><!%I|5|!%><!%F|350.75|!%><!%S|WXfySGpUjACkuhDMEFHByHC |!%> 06:41:17,918 tpcw W 60 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|8|!%><!%I|44082|!%><!%I|1|!%><!%I|5|!%><!%F|163.0|!%><!%S|oLZuDzfKxwywpPVnuvWIAiN |!%> 06:41:17,920 tpcw W 61 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|9|!%><!%I|33528|!%><!%I|1|!%><!%I|7|!%><!%F|546.56|!%><!%S|RXyGsuHakgICtomGgqXONFG |!%> 06:41:17,953 tpcw W 62 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|10|!%><!%I|73682|!%><!%I|1|!%><!%I|5|!%><!%F|367.94998|!%><!%S|aKHJsOmlboDMYvZpIKhwyft |!%> 06:41:17,959 tpcw W 63 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|11|!%><!%I|35368|!%><!%I|1|!%><!%I|1|!%><!%F|94.42|!%><!%S|CWqYCBPzPvLqwuXYplcNMea |!%> 06:41:17,971 tpcw W 64 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|12|!%><!%I|95292|!%><!%I|1|!%><!%I|10|!%><!%F|145.20001|!%><!%S|ChluQKonyYZKGgOWncwbRYk |!%> 06:41:17,974 tpcw W 65 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|13|!%><!%I|39205|!%><!%I|1|!%><!%I|4|!%><!%F|270.8|!%><!%S|BBekwNuZBNFQTJlaNfbBDru |!%> 06:41:17,975 tpcw W 66 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|14|!%><!%I|4967|!%><!%I|1|!%><!%I|9|!%><!%F|636.12|!%><!%S|xmfTesGnoIfNeySUBFBfvyE |!%> 06:41:18,000 tpcw W 67 1 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|1|!%><!%I|15|!%><!%I|78394|!%><!%I|1|!%><!%I|6|!%><!%F|524.94|!%><!%S|AEWQvhWKeOoBfvkCcwqzYBE |!%> 06:41:18,010 tpcw W 68 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|54|!%><!%I|5|!%><!%I|0|!%><!%I|59171|!%><!%I|1|!%> 06:41:18,733 tpcw W 69 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|17|!%><!%I|1|!%><!%I|0|!%><!%I|70974|!%><!%I|1|!%> 06:41:19,511 tpcw W 70 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|64|!%><!%I|9|!%><!%I|0|!%><!%I|98499|!%><!%I|1|!%> 06:41:19,725 tpcw W 71 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|75|!%><!%I|1|!%><!%I|0|!%><!%I|13039|!%><!%I|1|!%> 06:41:20,272 tpcw W 72 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|61|!%><!%I|4|!%><!%I|0|!%><!%I|31245|!%><!%I|1|!%> 06:41:20,440 tpcw W 73 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|92|!%><!%I|9|!%><!%I|0|!%><!%I|34982|!%><!%I|1|!%> 06:41:20,550 tpcw S 74 0 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|8|!%><!%I|2|!%> 06:41:20,553 tpcw W 75 4 INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)/<!%I|3|!%><!%I|2|!%><!%I|556|!%><!%I|3|!%><!%I|2|!%><!%T|2011-11-23 06:41:20.553|!%><!%F|3794.01|!%><!%S|ETnHrIq RoJeId|!%> 06:41:20,556 tpcw W 76 0 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%> 06:41:20,577 tpcw W 77 3 UPDATE customer SET c_balance = ? WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%F|2214.39|!%><!%I|1|!%><!%I|7|!%><!%I|2065|!%> 06:41:20,595 tpcw C 4 06:41:20,646 tpcw B 6 06:41:20,646 tpcw W 78 6 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|2043.54|!%><!%I|2|!%> 06:41:20,742 tpcw W 79 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|63|!%><!%I|5|!%><!%I|0|!%><!%I|88369|!%><!%I|1|!%> 06:41:20,766 tpcw W 80 3 INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)/<!%I|7|!%><!%I|1|!%><!%I|2065|!%><!%I|3|!%><!%I|3|!%><!%T|2011-11-23 06:41:20.766|!%><!%F|2224.39|!%><!%S|KSKFA EHjrv|!%> 06:41:20,791 tpcw C 3 06:41:20,882 tpcw S 81 6 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|2|!%> 06:41:20,885 tpcw B 7 06:41:20,885 tpcw W 82 7 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|1346.25|!%><!%I|3|!%> 06:41:20,886 tpcw W 83 6 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|2043.54|!%><!%I|2|!%><!%I|2|!%> 06:41:20,982 tpcw S 84 6 SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|2|!%><!%I|2|!%> 06:41:20,984 tpcw W 85 5 INSERT INTO OORDER (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?, ?, ?, ?, ?, ?, ?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|1768|!%><!%T|2011-11-23 06:41:20.984|!%><!%I|7|!%><!%I|0|!%> 06:41:21,001 tpcw W 86 0 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|8|!%><!%I|2|!%> 06:41:21,004 tpcw S 87 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|48526|!%> 06:41:21,015 tpcw W 88 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|88|!%><!%I|5|!%><!%I|0|!%><!%I|44082|!%><!%I|1|!%> 06:41:21,016 tpcw S 89 6 SELECT c_first, c_middle, c_last, c_street_1, c_street_2, c_city, c_state, c_zip, c_phone, c_credit, c_credit_lim, c_discount, c_balance, c_since FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%I|2|!%><!%I|2|!%><!%I|1719|!%> 06:41:21,023 tpcw S 90 7 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|3|!%> 06:41:21,036 tpcw W 91 7 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|1346.25|!%><!%I|3|!%><!%I|5|!%> 06:41:21,103 tpcw S 92 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|48526|!%><!%I|1|!%> 06:41:21,124 tpcw W 93 6 UPDATE customer SET c_balance = ? WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%F|2033.54|!%><!%I|2|!%><!%I|2|!%><!%I|1719|!%> 06:41:21,352 tpcw W 94 6 INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)/<!%I|2|!%><!%I|2|!%><!%I|1719|!%><!%I|2|!%><!%I|2|!%><!%T|2011-11-23 06:41:21.351|!%><!%F|2043.54|!%><!%S|ETnHrIq aCmlVGpTR|!%> 06:41:21,368 tpcw C 6 06:41:21,369 tpcw S 95 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|82743|!%> 06:41:21,370 tpcw W 96 0 INSERT INTO OORDER (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?, ?, ?, ?, ?, ?, ?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|1673|!%><!%T|2011-11-23 06:41:21.37|!%><!%I|5|!%><!%I|1|!%> 06:41:21,408 tpcw S 97 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|82743|!%><!%I|1|!%> 06:41:21,409 tpcw W 98 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|13|!%><!%I|7|!%><!%I|0|!%><!%I|33528|!%><!%I|1|!%> 06:41:21,413 tpcw B 8 06:41:21,414 tpcw S 99 8 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|2|!%><!%I|5|!%><!%I|1045|!%> 06:41:21,602 tpcw S 100 8 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|5|!%><!%I|2|!%> 06:41:21,613 tpcw W 101 8 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%> 06:41:21,644 tpcw S 102 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|91839|!%> 06:41:21,673 tpcw S 103 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|91839|!%><!%I|1|!%> 06:41:21,803 tpcw S 104 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|69174|!%> 06:41:21,818 tpcw W 105 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|84|!%><!%I|5|!%><!%I|0|!%><!%I|73682|!%><!%I|1|!%> 06:41:22,103 tpcw W 106 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|14|!%><!%I|1|!%><!%I|0|!%><!%I|35368|!%><!%I|1|!%> 06:41:22,250 tpcw S 107 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|69174|!%><!%I|3|!%> 06:41:22,381 tpcw S 108 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|74595|!%> 06:41:22,398 tpcw W 109 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|15|!%><!%I|10|!%><!%I|0|!%><!%I|95292|!%><!%I|1|!%> 06:41:22,420 tpcw S 110 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|74595|!%><!%I|1|!%> 06:41:22,654 tpcw S 111 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|29433|!%> 06:41:22,719 tpcw W 112 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|60|!%><!%I|4|!%><!%I|0|!%><!%I|39205|!%><!%I|1|!%> 06:41:22,905 tpcw S 113 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|29433|!%><!%I|1|!%> 06:41:23,026 tpcw W 114 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|26|!%><!%I|9|!%><!%I|0|!%><!%I|4967|!%><!%I|1|!%> 06:41:23,037 tpcw S 115 5 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|56570|!%> 06:41:23,097 tpcw S 116 5 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|56570|!%><!%I|1|!%> 06:41:23,309 tpcw W 117 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|1|!%><!%I|48526|!%><!%I|1|!%><!%I|3|!%><!%F|60.03|!%><!%S|vEVTlEfvRTxqgaLfwqMMktH |!%> 06:41:23,358 tpcw W 118 1 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|100|!%><!%I|6|!%><!%I|0|!%><!%I|78394|!%><!%I|1|!%> 06:41:23,598 tpcw W 119 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|2|!%><!%I|82743|!%><!%I|1|!%><!%I|3|!%><!%F|197.94|!%><!%S|jsbuQENoDVDVBOWDrgzFOlk |!%> 06:41:23,599 tpcw C 1 06:41:23,600 tpcw S 120 7 SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|3|!%><!%I|5|!%> 06:41:23,615 tpcw S 121 0 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|72586|!%> 06:41:23,616 tpcw S 122 7 SELECT c_first, c_middle, c_last, c_street_1, c_street_2, c_city, c_state, c_zip, c_phone, c_credit, c_credit_lim, c_discount, c_balance, c_since FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%I|3|!%><!%I|5|!%><!%I|200|!%> 06:41:23,620 tpcw W 123 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|3|!%><!%I|91839|!%><!%I|1|!%><!%I|4|!%><!%F|4.96|!%><!%S|RKyukJgHBcMRfXlRvJPitjI |!%> 06:41:23,620 tpcw W 124 8 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|5|!%><!%I|2|!%> 06:41:23,648 tpcw S 125 0 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|72586|!%><!%I|2|!%> 06:41:23,665 tpcw B 9 06:41:23,667 tpcw W 126 9 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|1812.77|!%><!%I|1|!%> 06:41:23,676 tpcw W 127 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|4|!%><!%I|69174|!%><!%I|3|!%><!%I|9|!%><!%F|806.30994|!%><!%S|JCqsEIPleHcbXsUcyocJOfv |!%> 06:41:23,692 tpcw W 128 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|5|!%><!%I|74595|!%><!%I|1|!%><!%I|5|!%><!%F|142.9|!%><!%S|slKonwWQvzHVOtHYjIODLyv |!%> 06:41:23,704 tpcw W 129 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|6|!%><!%I|29433|!%><!%I|1|!%><!%I|8|!%><!%F|336.56|!%><!%S|wEmjoexrhJcDFXiWWevsPok |!%> 06:41:23,740 tpcw W 130 5 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|6|!%><!%I|1|!%><!%I|7|!%><!%I|56570|!%><!%I|1|!%><!%I|10|!%><!%F|223.2|!%><!%S|xwOZxAeysVbTilriDmLQzPb |!%> 06:41:23,776 tpcw W 131 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|57|!%><!%I|3|!%><!%I|0|!%><!%I|48526|!%><!%I|1|!%> 06:41:23,841 tpcw S 132 0 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|92253|!%> 06:41:23,841 tpcw W 133 7 UPDATE customer SET c_balance = ? WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%F|1336.25|!%><!%I|3|!%><!%I|5|!%><!%I|200|!%> 06:41:23,911 tpcw S 134 0 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|92253|!%><!%I|2|!%> 06:41:24,042 tpcw W 135 7 INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)/<!%I|5|!%><!%I|3|!%><!%I|200|!%><!%I|5|!%><!%I|3|!%><!%T|2011-11-23 06:41:24.042|!%><!%F|1346.25|!%><!%S|KSKFA MaPpAIQZ|!%> 06:41:24,057 tpcw C 7 06:41:24,097 tpcw B 10 06:41:24,097 tpcw S 136 10 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|3|!%><!%I|9|!%><!%I|1667|!%> 06:41:24,116 tpcw S 137 0 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|49995|!%> 06:41:24,117 tpcw W 138 8 INSERT INTO OORDER (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?, ?, ?, ?, ?, ?, ?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|1045|!%><!%T|2011-11-23 06:41:24.116|!%><!%I|10|!%><!%I|1|!%> 06:41:24,128 tpcw S 139 9 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|1|!%> 06:41:24,130 tpcw W 140 9 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|1812.77|!%><!%I|1|!%><!%I|9|!%> 06:41:24,154 tpcw S 141 0 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|49995|!%><!%I|2|!%> 06:41:24,248 tpcw W 142 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|52|!%><!%I|3|!%><!%I|0|!%><!%I|82743|!%><!%I|1|!%> 06:41:24,321 tpcw S 143 10 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|9|!%><!%I|3|!%> 06:41:24,332 tpcw S 144 0 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|1321|!%> 06:41:24,344 tpcw W 145 10 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%> 06:41:24,396 tpcw S 146 0 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|1321|!%><!%I|2|!%> 06:41:24,545 tpcw S 147 0 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|62727|!%> 06:41:24,628 tpcw W 148 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|35|!%><!%I|4|!%><!%I|0|!%><!%I|91839|!%><!%I|1|!%> 06:41:24,940 tpcw W 149 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|14|!%><!%I|9|!%><!%I|1|!%><!%I|69174|!%><!%I|3|!%> 06:41:25,191 tpcw S 150 0 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|62727|!%><!%I|2|!%> 06:41:25,261 tpcw W 151 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|23|!%><!%I|5|!%><!%I|0|!%><!%I|74595|!%><!%I|1|!%> 06:41:25,352 tpcw W 152 0 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|1|!%><!%I|72586|!%><!%I|2|!%><!%I|9|!%><!%F|694.71|!%><!%S|igDaNrjkeoNInuCZKxVsObX |!%> 06:41:25,556 tpcw W 153 0 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|2|!%><!%I|92253|!%><!%I|2|!%><!%I|2|!%><!%F|159.6|!%><!%S|gQpOtFaWyBQMJjmFmbCqFzD |!%> 06:41:25,564 tpcw W 154 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|49|!%><!%I|8|!%><!%I|0|!%><!%I|29433|!%><!%I|1|!%> 06:41:25,565 tpcw S 155 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|61982|!%> 06:41:25,566 tpcw S 156 9 SELECT d_street_1, d_street_2, d_city, d_state, d_zip, d_name FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|1|!%><!%I|9|!%> 06:41:25,566 tpcw W 157 10 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|9|!%><!%I|3|!%> 06:41:25,568 tpcw S 158 9 SELECT c_first, c_middle, c_last, c_street_1, c_street_2, c_city, c_state, c_zip, c_phone, c_credit, c_credit_lim, c_discount, c_balance, c_since FROM customer WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%I|1|!%><!%I|9|!%><!%I|1468|!%> 06:41:25,603 tpcw W 159 0 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|3|!%><!%I|49995|!%><!%I|2|!%><!%I|2|!%><!%F|30.58|!%><!%S|ePjOMHXSqKkFqNgIHGyVjqr |!%> 06:41:25,612 tpcw S 160 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|61982|!%><!%I|2|!%> 06:41:25,737 tpcw W 161 9 UPDATE customer SET c_balance = ? WHERE c_w_id = ? AND c_d_id = ? AND c_id = ?/<!%F|1802.77|!%><!%I|1|!%><!%I|9|!%><!%I|1468|!%> 06:41:25,913 tpcw W 162 9 INSERT INTO history (h_c_d_id, h_c_w_id, h_c_id, h_d_id, h_w_id, h_date, h_amount, h_data) VALUES (?,?,?,?,?,?,?,?)/<!%I|9|!%><!%I|1|!%><!%I|1468|!%><!%I|9|!%><!%I|1|!%><!%T|2011-11-23 06:41:25.912|!%><!%F|1812.77|!%><!%S|GKSrRrF AfKRvpkG|!%> 06:41:25,922 tpcw S 163 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|99656|!%> 06:41:25,928 tpcw C 9 06:41:25,943 tpcw W 164 0 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|4|!%><!%I|1321|!%><!%I|2|!%><!%I|4|!%><!%F|364.64|!%><!%S|ldbeTSMMSfNFyPILvVlCLvY |!%> 06:41:25,951 tpcw W 165 5 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|61|!%><!%I|10|!%><!%I|0|!%><!%I|56570|!%><!%I|1|!%> 06:41:25,953 tpcw W 166 10 INSERT INTO OORDER (o_id, o_d_id, o_w_id, o_c_id, o_entry_d, o_ol_cnt, o_all_local) VALUES (?, ?, ?, ?, ?, ?, ?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|1667|!%><!%T|2011-11-23 06:41:25.952|!%><!%I|6|!%><!%I|1|!%> 06:41:25,958 tpcw W 167 0 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|8|!%><!%I|2|!%><!%I|5|!%><!%I|62727|!%><!%I|2|!%><!%I|6|!%><!%F|228.54001|!%><!%S|BrXsDVZCNXYVZkkCKkiwHvm |!%> 06:41:25,959 tpcw S 168 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|1349|!%> 06:41:25,962 tpcw B 11 06:41:25,962 tpcw S 169 11 SELECT d_next_o_id FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|1|!%><!%I|7|!%> 06:41:25,969 tpcw S 170 11 SELECT COUNT(DISTINCT (s_i_id)) AS stock_count FROM order_line, stock WHERE ol_w_id = ? AND ol_d_id = ? AND ol_o_id < ? AND ol_o_id >= ? - 20 AND s_w_id = ? AND s_i_id = ol_i_id AND s_quantity < ?/<!%I|1|!%><!%I|7|!%><!%I|3001|!%><!%I|3001|!%><!%I|1|!%><!%I|12|!%> 06:41:26,003 tpcw S 171 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|1349|!%><!%I|3|!%> 06:41:26,081 tpcw S 172 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|99656|!%><!%I|2|!%> 06:41:26,390 tpcw W 173 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|91|!%><!%I|9|!%><!%I|0|!%><!%I|72586|!%><!%I|2|!%> 06:41:26,403 tpcw C 5 06:41:26,412 tpcw S 174 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|13580|!%> 06:41:26,450 tpcw B 12 06:41:26,450 tpcw S 175 12 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|1|!%><!%I|4|!%><!%I|1258|!%> 06:41:26,524 tpcw S 176 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|13675|!%> 06:41:26,533 tpcw S 177 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|13580|!%><!%I|3|!%> 06:41:26,664 tpcw S 178 12 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|4|!%><!%I|1|!%> 06:41:26,673 tpcw W 179 12 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|4|!%><!%I|1|!%> 06:41:26,711 tpcw S 180 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|13675|!%><!%I|2|!%> 06:41:26,917 tpcw W 181 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|71|!%><!%I|2|!%><!%I|0|!%><!%I|92253|!%><!%I|2|!%> 06:41:26,968 tpcw S 182 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|92047|!%> 06:41:27,080 tpcw S 183 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|92047|!%><!%I|3|!%> 06:41:27,152 tpcw S 184 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|77550|!%> 06:41:27,272 tpcw S 185 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|77550|!%><!%I|2|!%> 06:41:27,380 tpcw W 186 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|21|!%><!%I|2|!%><!%I|0|!%><!%I|49995|!%><!%I|2|!%> 06:41:27,552 tpcw S 187 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|53370|!%> 06:41:27,600 tpcw C 11 06:41:27,633 tpcw B 13 06:41:27,633 tpcw W 188 13 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|56.68|!%><!%I|1|!%> 06:41:27,679 tpcw S 189 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|53370|!%><!%I|3|!%> 06:41:27,680 tpcw S 190 13 SELECT w_street_1, w_street_2, w_city, w_state, w_zip, w_name FROM warehouse WHERE w_id = ?/<!%I|1|!%> 06:41:27,681 tpcw W 191 13 UPDATE district SET d_ytd = d_ytd + ? WHERE d_w_id = ? AND d_id = ?/<!%F|56.68|!%><!%I|1|!%><!%I|4|!%> 06:41:27,703 tpcw S 192 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|32582|!%> 06:41:27,801 tpcw S 193 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|32582|!%><!%I|2|!%> 06:41:27,802 tpcw W 194 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|82|!%><!%I|4|!%><!%I|0|!%><!%I|1321|!%><!%I|2|!%> 06:41:28,004 tpcw S 195 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|78070|!%> 06:41:28,104 tpcw S 196 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|31606|!%> 06:41:28,132 tpcw S 197 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|31606|!%><!%I|2|!%> 06:41:28,204 tpcw S 198 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|78070|!%><!%I|3|!%> 06:41:28,224 tpcw W 199 0 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|56|!%><!%I|6|!%><!%I|0|!%><!%I|62727|!%><!%I|2|!%> 06:41:28,308 tpcw S 200 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|91812|!%> 06:41:28,464 tpcw S 201 10 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|51823|!%> 06:41:28,491 tpcw S 202 10 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|51823|!%><!%I|3|!%> 06:41:28,586 tpcw C 0 06:41:28,628 tpcw W 203 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|1|!%><!%I|1349|!%><!%I|3|!%><!%I|4|!%><!%F|98.72|!%><!%S|sevNRneweZgcwvXQwFwaqdS |!%> 06:41:28,664 tpcw B 14 06:41:28,664 tpcw W 204 14 UPDATE warehouse SET w_ytd = w_ytd + ? WHERE w_id = ?/<!%F|4539.02|!%><!%I|2|!%> 06:41:28,675 tpcw S 205 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|91812|!%><!%I|2|!%> 06:41:28,808 tpcw S 206 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|59456|!%> 06:41:28,909 tpcw W 207 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|2|!%><!%I|13580|!%><!%I|3|!%><!%I|5|!%><!%F|304.55|!%><!%S|sVqkDqmGOQjkwAwGjxmvoeL |!%> 06:41:28,912 tpcw W 208 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|3|!%><!%I|92047|!%><!%I|3|!%><!%I|1|!%><!%F|22.47|!%><!%S|RjKFPtkJltyRDmvXImLCrgq |!%> 06:41:28,941 tpcw W 209 12 UPDATE district SET d_next_o_id = d_next_o_id + 1 WHERE d_id = ? AND d_w_id = ?/<!%I|4|!%><!%I|1|!%> 06:41:28,942 tpcw W 210 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|4|!%><!%I|53370|!%><!%I|3|!%><!%I|7|!%><!%F|295.12|!%><!%S|umNbLolmLjPAgWBVpYwlJAG |!%> 06:41:28,956 tpcw W 211 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|5|!%><!%I|78070|!%><!%I|3|!%><!%I|1|!%><!%F|4.32|!%><!%S|dcqflZPdKXeMPGUWROCmARG |!%> 06:41:28,968 tpcw W 212 10 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|9|!%><!%I|3|!%><!%I|6|!%><!%I|51823|!%><!%I|3|!%><!%I|9|!%><!%F|288.27|!%><!%S|qekRXBGXlonhrWsRHImUEIb |!%> 06:41:28,972 tpcw W 213 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|91|!%><!%I|4|!%><!%I|0|!%><!%I|1349|!%><!%I|3|!%> 06:41:29,010 tpcw S 214 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|59456|!%><!%I|2|!%> 06:41:29,240 tpcw S 215 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|64935|!%> 06:41:29,268 tpcw S 216 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|64935|!%><!%I|2|!%> 06:41:29,318 tpcw W 217 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|76|!%><!%I|5|!%><!%I|0|!%><!%I|13580|!%><!%I|3|!%> 06:41:29,471 tpcw S 218 8 SELECT i_price, i_name , i_data FROM item WHERE i_id = ?/<!%I|26020|!%> 06:41:29,571 tpcw W 219 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|84|!%><!%I|1|!%><!%I|0|!%><!%I|92047|!%><!%I|3|!%> 06:41:29,644 tpcw S 220 8 SELECT s_quantity, s_data, s_dist_01, s_dist_02, s_dist_03, s_dist_04, s_dist_05, s_dist_06, s_dist_07, s_dist_08, s_dist_09, s_dist_10 FROM stock WHERE s_i_id = ? AND s_w_id = ? FOR UPDATE/<!%I|26020|!%><!%I|2|!%> 06:41:29,820 tpcw W 221 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|1|!%><!%I|61982|!%><!%I|2|!%><!%I|7|!%><!%F|653.94|!%><!%S|tYvrZXhwISlEvrvhFbvHYou |!%> 06:41:29,899 tpcw W 222 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|47|!%><!%I|7|!%><!%I|0|!%><!%I|53370|!%><!%I|3|!%> 06:41:30,101 tpcw W 223 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|70|!%><!%I|1|!%><!%I|0|!%><!%I|78070|!%><!%I|3|!%> 06:41:30,275 tpcw W 224 10 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|76|!%><!%I|9|!%><!%I|0|!%><!%I|51823|!%><!%I|3|!%> 06:41:30,418 tpcw C 10 06:41:30,432 tpcw W 225 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|2|!%><!%I|99656|!%><!%I|2|!%><!%I|2|!%><!%F|132.56|!%><!%S|vHfWLTJHoLolyupcuTAOTnI |!%> 06:41:30,433 tpcw B 15 06:41:30,433 tpcw S 226 15 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|3|!%><!%I|2|!%><!%I|2751|!%> 06:41:30,447 tpcw W 227 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|3|!%><!%I|13675|!%><!%I|2|!%><!%I|5|!%><!%F|106.95|!%><!%S|sZsDKLyxyqhIEYVIfwhinqV |!%> 06:41:30,453 tpcw W 228 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|4|!%><!%I|77550|!%><!%I|2|!%><!%I|9|!%><!%F|540.36|!%><!%S|iABrztaqeNsOWamhrfcrfyr |!%> 06:41:30,460 tpcw W 229 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|5|!%><!%I|32582|!%><!%I|2|!%><!%I|7|!%><!%F|488.60004|!%><!%S|KdiLjjxccjHrSQjNAUtZNBn |!%> 06:41:30,489 tpcw W 230 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|6|!%><!%I|31606|!%><!%I|2|!%><!%I|1|!%><!%F|48.08|!%><!%S|BKlOYSFUoUAfSRVixsDNxMS |!%> 06:41:30,500 tpcw S 231 15 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|3|!%> 06:41:30,501 tpcw W 232 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|7|!%><!%I|91812|!%><!%I|2|!%><!%I|10|!%><!%F|515.4|!%><!%S|bzRngWVKpGKAOkImHPHzGan |!%> 06:41:30,512 tpcw W 233 15 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|3|!%> 06:41:30,517 tpcw W 234 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|8|!%><!%I|59456|!%><!%I|2|!%><!%I|10|!%><!%F|274.8|!%><!%S|qKRBoYrEBVokJIufYReGJKA |!%> 06:41:30,519 tpcw W 235 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|9|!%><!%I|64935|!%><!%I|2|!%><!%I|4|!%><!%F|346.8|!%><!%S|IusEFfalAzThjupMOvhMdrY |!%> 06:41:30,522 tpcw W 236 8 INSERT INTO order_line (ol_o_id, ol_d_id, ol_w_id, ol_number, ol_i_id, ol_supply_w_id, ol_quantity, ol_amount, ol_dist_info) VALUES (?,?,?,?,?,?,?,?,?)/<!%I|3001|!%><!%I|5|!%><!%I|2|!%><!%I|10|!%><!%I|26020|!%><!%I|2|!%><!%I|6|!%><!%F|558.24|!%><!%S|AVzcvSzbfnSZaVxldoJEJIb |!%> 06:41:30,524 tpcw W 237 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|45|!%><!%I|7|!%><!%I|0|!%><!%I|61982|!%><!%I|2|!%> 06:41:30,681 tpcw W 238 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|81|!%><!%I|2|!%><!%I|0|!%><!%I|99656|!%><!%I|2|!%> 06:41:30,824 tpcw W 239 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|63|!%><!%I|5|!%><!%I|0|!%><!%I|13675|!%><!%I|2|!%> 06:41:30,969 tpcw W 240 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|78|!%><!%I|9|!%><!%I|0|!%><!%I|77550|!%><!%I|2|!%> 06:41:31,116 tpcw W 241 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|37|!%><!%I|7|!%><!%I|0|!%><!%I|32582|!%><!%I|2|!%> 06:41:31,289 tpcw W 242 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|59|!%><!%I|1|!%><!%I|0|!%><!%I|31606|!%><!%I|2|!%> 06:41:31,433 tpcw W 243 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|45|!%><!%I|10|!%><!%I|0|!%><!%I|91812|!%><!%I|2|!%> 06:41:31,576 tpcw W 244 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|83|!%><!%I|10|!%><!%I|0|!%><!%I|59456|!%><!%I|2|!%> 06:41:31,720 tpcw W 245 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|39|!%><!%I|4|!%><!%I|0|!%><!%I|64935|!%><!%I|2|!%> 06:41:31,864 tpcw W 246 8 UPDATE stock SET s_quantity = ? , s_ytd = s_ytd + ?, s_remote_cnt = s_remote_cnt + ? WHERE s_i_id = ? AND s_w_id = ?/<!%I|69|!%><!%I|6|!%><!%I|0|!%><!%I|26020|!%><!%I|2|!%> 06:41:32,008 tpcw C 8 06:41:32,018 tpcw B 16 06:41:32,018 tpcw S 247 16 SELECT d_next_o_id FROM district WHERE d_w_id = ? AND d_id = ?/<!%I|2|!%><!%I|3|!%> 06:41:32,019 tpcw S 248 16 SELECT COUNT(DISTINCT (s_i_id)) AS stock_count FROM order_line, stock WHERE ol_w_id = ? AND ol_d_id = ? AND ol_o_id < ? AND ol_o_id >= ? - 20 AND s_w_id = ? AND s_i_id = ol_i_id AND s_quantity < ?/<!%I|2|!%><!%I|3|!%><!%I|3001|!%><!%I|3001|!%><!%I|2|!%><!%I|12|!%> 06:41:32,421 tpcw C 16 06:41:32,424 tpcw B 17 06:41:32,424 tpcw S 249 17 SELECT c_discount, c_last, c_credit, w_tax FROM customer, warehouse WHERE w_id = ? AND w_id = c_w_id AND c_d_id = ? AND c_id = ?/<!%I|2|!%><!%I|2|!%><!%I|1676|!%> 06:41:32,487 tpcw S 250 17 SELECT d_next_o_id, d_tax FROM district WHERE d_id = ? AND d_w_id = ? FOR UPDATE/<!%I|2|!%><!%I|2|!%> 06:41:32,489 tpcw W 251 17 INSERT INTO NEW_ORDER (no_o_id, no_d_id, no_w_id) VALUES ( ?, ?, ?)/<!%I|3001|!%><!%I|2|!%><!%I|2|!%> On Wed, Nov 23, 2011 at 3:09 PM, Emmanuel Cecchet <ce...@gm...> wrote: > Hi, > > From your log it looks like everyone is waiting for that transaction 65 to > either commit or rollback. > If your thread has crashed and there is no rollback or connection closing > in a catch block, all the locks are going to be retained forever (thought > there is a possibility to set timeout on transactions in the load balancer > settings if I recall). > Without the log of the exact requests, it's hard to tell you more than > that. > > Keep us posted with your findings, > Emmanuel > > > On 11/23/2011 06:30, rohit dhamane wrote: > > Hi, > > I have been facing some problem with sequoia. I am trying to run > BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with > sequoia over two postgresql-7.3 servers but it seems to get stuck > indefinitely at the same point. I think it's happening because of the > SELECT...FOR UPDATE but not really sure how :( It seems that the > transactions are getting into a deadlock. Here's the out put when I turned > on the debug mode. > > 02:56:49,388 DEBUG controller.core.PingResponder Received ping data from > /127.0.0.1 > 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent to / > 127.0.0.1 > 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for > graph... > 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for > graph... > 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for district > locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for new_order > locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for warehouse > locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for new_order > locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim node... > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected > 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim > 02:56:50,389 DEBUG controller.core.PingResponder Received ping data from / > 127.0.0.1 > 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent to / > 127.0.0.1 > > > > Here's my configuration file.. > > <?xml version="1.0" encoding="UTF-8"?>^M > <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" " > http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M > ^M > <SEQUOIA>^M > ^M > <VirtualDatabase name="tpcw">^M > ^M > <AuthenticationManager>^M > <Admin>^M > <User username="postgres" password=""/>^M > </Admin> ^M > <VirtualUsers>^M > <VirtualLogin vLogin="postgres" vPassword=""/>^M > </VirtualUsers>^M > </AuthenticationManager>^M > ^M > <DatabaseBackend name="localhost" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://localhost:6551/tpcw" connectionTestStatement="select > now()">^M > > <ConnectionManager vLogin="postgres" rLogin="postgres" > rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > ^M > <DatabaseBackend name="Remote" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://192.168.164.136:6552/tpcw" > connectionTestStatement="select now()">^M > <ConnectionManager vLogin="postgres" rLogin="postgres" > rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > <RequestManager>^M > <RequestScheduler>^M > <RAIDb-1Scheduler level="passThrough"/>^M > </RequestScheduler>^M > ^M > <RequestCache>^M > <MetadataCache/>^M > <ParsingCache/> ^M > <ResultCache granularity="table" />^M > </RequestCache>^M > ^M > <LoadBalancer transactionIsolation="serializable">^M > <RAIDb-1>^M > <WaitForCompletion policy="all" > deadlockTimeoutInMs="30000"/>^M > <RAIDb-1-RoundRobin/>^M > </RAIDb-1>^M > </LoadBalancer>^M > </RequestManager>^M > ^M > </VirtualDatabase>^M > ^M > </SEQUOIA>^M > > If anybody has anu idea why this happens please let me know. I would > appreciate it a lot. Thanks in advance. > > Regards, > Rohit > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense.http://p.sf.net/sfu/splunk-novd2d > > > > _______________________________________________ > Sequoiadb-discuss mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss > > > |
From: Emmanuel C. <ce...@gm...> - 2011-11-23 14:34:59
|
Hi, From your log it looks like everyone is waiting for that transaction 65 to either commit or rollback. If your thread has crashed and there is no rollback or connection closing in a catch block, all the locks are going to be retained forever (thought there is a possibility to set timeout on transactions in the load balancer settings if I recall). Without the log of the exact requests, it's hard to tell you more than that. Keep us posted with your findings, Emmanuel On 11/23/2011 06:30, rohit dhamane wrote: > Hi, > > I have been facing some problem with sequoia. I am trying to run > BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with > sequoia over two postgresql-7.3 servers but it seems to get stuck > indefinitely at the same point. I think it's happening because of the > SELECT...FOR UPDATE but not really sure how :( It seems that the > transactions are getting into a deadlock. Here's the out put when I > turned on the debug mode. > > 02:56:49,388 DEBUG controller.core.PingResponder Received ping data > from /127.0.0.1 <http://127.0.0.1> > 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for > graph... > 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for > graph... > 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for > new_order locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for > warehouse locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for > new_order locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim node... > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected > 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim > 02:56:50,389 DEBUG controller.core.PingResponder Received ping data > from /127.0.0.1 <http://127.0.0.1> > 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > > > > Here's my configuration file.. > > <?xml version="1.0" encoding="UTF-8"?>^M > <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" > "http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M > ^M > <SEQUOIA>^M > ^M > <VirtualDatabase name="tpcw">^M > ^M > <AuthenticationManager>^M > <Admin>^M > <User username="postgres" password=""/>^M > </Admin> ^M > <VirtualUsers>^M > <VirtualLogin vLogin="postgres" vPassword=""/>^M > </VirtualUsers>^M > </AuthenticationManager>^M > ^M > <DatabaseBackend name="localhost" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://localhost:6551/tpcw" > connectionTestStatement="select now()">^M > > <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > ^M > <DatabaseBackend name="Remote" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://192.168.164.136:6552/tpcw > <http://192.168.164.136:6552/tpcw>" connectionTestStatement="select > now()">^M > <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > <RequestManager>^M > <RequestScheduler>^M > <RAIDb-1Scheduler level="passThrough"/>^M > </RequestScheduler>^M > ^M > <RequestCache>^M > <MetadataCache/>^M > <ParsingCache/> ^M > <ResultCache granularity="table" />^M > </RequestCache>^M > ^M > <LoadBalancer transactionIsolation="serializable">^M > <RAIDb-1>^M > <WaitForCompletion policy="all" > deadlockTimeoutInMs="30000"/>^M > <RAIDb-1-RoundRobin/>^M > </RAIDb-1>^M > </LoadBalancer>^M > </RequestManager>^M > ^M > </VirtualDatabase>^M > ^M > </SEQUOIA>^M > > If anybody has anu idea why this happens please let me know. I would > appreciate it a lot. Thanks in advance. > > Regards, > Rohit > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > > > _______________________________________________ > Sequoiadb-discuss mailing list > Seq...@li... > https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss |
From: Emmanuel C. <ce...@gm...> - 2011-11-23 14:09:34
|
Hi, From your log it looks like everyone is waiting for that transaction 65 to either commit or rollback. If your thread has crashed and there is no rollback or connection closing in a catch block, all the locks are going to be retained forever (thought there is a possibility to set timeout on transactions in the load balancer settings if I recall). Without the log of the exact requests, it's hard to tell you more than that. Keep us posted with your findings, Emmanuel On 11/23/2011 06:30, rohit dhamane wrote: > Hi, > > I have been facing some problem with sequoia. I am trying to run > BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with > sequoia over two postgresql-7.3 servers but it seems to get stuck > indefinitely at the same point. I think it's happening because of the > SELECT...FOR UPDATE but not really sure how :( It seems that the > transactions are getting into a deadlock. Here's the out put when I > turned on the debug mode. > > 02:56:49,388 DEBUG controller.core.PingResponder Received ping data > from /127.0.0.1 <http://127.0.0.1> > 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for > graph... > 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 > 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for > graph... > 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for > new_order locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for > warehouse locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for > new_order locked by 64 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for > district locked by 65 > 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim node... > 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected > 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim > 02:56:50,389 DEBUG controller.core.PingResponder Received ping data > from /127.0.0.1 <http://127.0.0.1> > 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent > to /127.0.0.1 <http://127.0.0.1> > > > > Here's my configuration file.. > > <?xml version="1.0" encoding="UTF-8"?>^M > <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" > "http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M > ^M > <SEQUOIA>^M > ^M > <VirtualDatabase name="tpcw">^M > ^M > <AuthenticationManager>^M > <Admin>^M > <User username="postgres" password=""/>^M > </Admin> ^M > <VirtualUsers>^M > <VirtualLogin vLogin="postgres" vPassword=""/>^M > </VirtualUsers>^M > </AuthenticationManager>^M > ^M > <DatabaseBackend name="localhost" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://localhost:6551/tpcw" > connectionTestStatement="select now()">^M > > <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > ^M > <DatabaseBackend name="Remote" driver="org.postgresql.Driver" > driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" > url="jdbc:postgresql://192.168.164.136:6552/tpcw > <http://192.168.164.136:6552/tpcw>" connectionTestStatement="select > now()">^M > <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M > <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" > maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M > </ConnectionManager>^M > </DatabaseBackend>^M > <RequestManager>^M > <RequestScheduler>^M > <RAIDb-1Scheduler level="passThrough"/>^M > </RequestScheduler>^M > ^M > <RequestCache>^M > <MetadataCache/>^M > <ParsingCache/> ^M > <ResultCache granularity="table" />^M > </RequestCache>^M > ^M > <LoadBalancer transactionIsolation="serializable">^M > <RAIDb-1>^M > <WaitForCompletion policy="all" > deadlockTimeoutInMs="30000"/>^M > <RAIDb-1-RoundRobin/>^M > </RAIDb-1>^M > </LoadBalancer>^M > </RequestManager>^M > ^M > </VirtualDatabase>^M > ^M > </SEQUOIA>^M > > If anybody has anu idea why this happens please let me know. I would > appreciate it a lot. Thanks in advance. > > Regards, > Rohit > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > > > _______________________________________________ > Sequoiadb-discuss mailing list > Seq...@li... > https://lists.sourceforge.net/lists/listinfo/sequoiadb-discuss |
From: rohit d. <roh...@gm...> - 2011-11-23 11:30:45
|
Hi, I have been facing some problem with sequoia. I am trying to run BenchmarkSql-2.3 (http://sourceforge.net/projects/benchmarksql/) with sequoia over two postgresql-7.3 servers but it seems to get stuck indefinitely at the same point. I think it's happening because of the SELECT...FOR UPDATE but not really sure how :( It seems that the transactions are getting into a deadlock. Here's the out put when I turned on the debug mode. 02:56:49,388 DEBUG controller.core.PingResponder Received ping data from / 127.0.0.1 02:56:49,388 DEBUG controller.core.PingResponder Response to ping sent to / 127.0.0.1 02:56:49,775 DEBUG sequoia.controller.loadbalancer Building wait-for graph... 02:56:49,776 DEBUG sequoia.controller.loadbalancer new_order locked by 64 02:56:49,777 DEBUG sequoia.controller.loadbalancer district locked by 65 02:56:49,777 DEBUG sequoia.controller.loadbalancer warehouse locked by 65 02:56:49,777 DEBUG sequoia.controller.loadbalancer Walking wait-for graph... 02:56:49,778 DEBUG sequoia.controller.loadbalancer 64 waits for district locked by 65 02:56:49,779 DEBUG sequoia.controller.loadbalancer 68 waits for new_order locked by 64 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for district locked by 65 02:56:49,779 DEBUG sequoia.controller.loadbalancer 67 waits for warehouse locked by 65 02:56:49,779 DEBUG sequoia.controller.loadbalancer 66 waits for new_order locked by 64 02:56:49,779 DEBUG sequoia.controller.loadbalancer 64 waits for district locked by 65 02:56:49,779 DEBUG sequoia.controller.loadbalancer Choosing victim node... 02:56:49,779 DEBUG sequoia.controller.loadbalancer 0 cycles detected 02:56:49,779 DEBUG sequoia.controller.loadbalancer No victim 02:56:50,389 DEBUG controller.core.PingResponder Received ping data from / 127.0.0.1 02:56:50,389 DEBUG controller.core.PingResponder Response to ping sent to / 127.0.0.1 Here's my configuration file.. <?xml version="1.0" encoding="UTF-8"?>^M <!DOCTYPE SEQUOIA PUBLIC "-//Continuent//DTD SEQUOIA @VERSION@//EN" " http://sequoia.continuent.org/dtds/sequoia-@VERSION@.dtd">^M ^M <SEQUOIA>^M ^M <VirtualDatabase name="tpcw">^M ^M <AuthenticationManager>^M <Admin>^M <User username="postgres" password=""/>^M </Admin> ^M <VirtualUsers>^M <VirtualLogin vLogin="postgres" vPassword=""/>^M </VirtualUsers>^M </AuthenticationManager>^M ^M <DatabaseBackend name="localhost" driver="org.postgresql.Driver" driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" url="jdbc:postgresql://localhost:6551/tpcw" connectionTestStatement="select now()">^M <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M </ConnectionManager>^M </DatabaseBackend>^M ^M <DatabaseBackend name="Remote" driver="org.postgresql.Driver" driverPath="/home/rohit/Software/CJDBC/sequoia-2.10.10-bin/drivers/postgresql7.3.jar" url="jdbc:postgresql://192.168.164.136:6552/tpcw" connectionTestStatement="select now()">^M <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword="">^M <VariablePoolConnectionManager initPoolSize="20" minPoolSize="5" maxPoolSize="0" idleTimeout="180" waitTimeout="0"/>^M </ConnectionManager>^M </DatabaseBackend>^M <RequestManager>^M <RequestScheduler>^M <RAIDb-1Scheduler level="passThrough"/>^M </RequestScheduler>^M ^M <RequestCache>^M <MetadataCache/>^M <ParsingCache/> ^M <ResultCache granularity="table" />^M </RequestCache>^M ^M <LoadBalancer transactionIsolation="serializable">^M <RAIDb-1>^M <WaitForCompletion policy="all" deadlockTimeoutInMs="30000"/>^M <RAIDb-1-RoundRobin/>^M </RAIDb-1>^M </LoadBalancer>^M </RequestManager>^M ^M </VirtualDatabase>^M ^M </SEQUOIA>^M If anybody has anu idea why this happens please let me know. I would appreciate it a lot. Thanks in advance. Regards, Rohit |
From: Emmanuel C. <ma...@fr...> - 2010-09-27 22:08:52
|
Hi, The list has moved to seq...@li... The Postgresql bytea type is not standard. If you are trying to retrieve it using ResultSet.getBytes() it should work. If you are trying a standard ResultSet.getObject() this will require a custom conversion that can be plugged into a BackendObjectConverter object. How are you trying to fetch the bytea field on the client side? Thanks for your interest in Sequoia Emmanuel On 9/27/2010 5:10 PM, John wrote: > Hi, > > Sequoia 2.10.10 > Postgresql 8.3 > > The Sequoia JDBC driver is not correctly returning the values of bytea > fields. The Sequoia backend is using the regular Postgres JDBC driver > (org.postgresql.Driver). Using SQuirreL (query tool), if I connect > using the Postgres driver I get the correct value but if I connect using > the Sequoia driver, I get a corrupted value. > > Has anyone seen this before? Any tips about what I should be looking > at? Thanks. > _______________________________________________ > Sequoia mailing list > Se...@li... > http://forge.continuent.org/mailman/listinfo/sequoia > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development& Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-05-12 02:38:49
|
Hi all, I am looking for a company who would be interesting in funding me part time to either produce a new version of Sequoia or work on a Sequoia related project. Feel free to contact me directly. Thanks Emmanuel -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-05-10 11:03:52
|
Hi Francis, Yes you can send me the distributed virtual database log to double check. But as Hedera did not catch the JGroups messages I don't expect the virtual database to have executed any handler. Don't wait for my analysis of the logs and go ahead with the new experiment. Thanks again for your feedback Emmanuel > Yes, it is enabled. Also, I’m going to try the latest hedera and will > let you know the result. Do you need me to check the other loggings > before I run the test? > > Thanks, > > Seby. > > -----Original Message----- > From: seq...@li... > [mailto:seq...@li...] On Behalf Of > Emmanuel Cecchet > Sent: Saturday, May 08, 2010 3:54 PM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Francis, > > Do you have the traces with > > log4j.logger.org.continuent.sequoia.controller.virtualdatabase set to > DEBUG? > > Could you also try with the latest version of Hedera? > > Sorry for the lag in the responses I have been swamped since I'm back! > > Emmanuel > > > Hello Emmanuel, > > > > > > Yes, all were in debug. Here is the snippet: > > > > > > ###################################### > > > # Hedera group communication loggers # > > > ###################################### > > > # Hedera channels test # > > > log4j.logger.test.org.continuent.hedera.channel=DEBUG, Console, Filetrace > > > log4j.additivity.test.org.continuent.hedera.channel=false > > > # Hedera adapters # > > > log4j.logger.org.continuent.hedera.adapters=DEBUG, Console, Filetrace > > > log4j.additivity.org.continuent.hedera.adapters=false > > > # Hedera factories # > > > log4j.logger.org.continuent.hedera.factory=DEBUG, Console, Filetrace > > > log4j.additivity.org.continuent.hedera.factory=false > > > # Hedera channels # > > > log4j.logger.org.continuent.hedera.channel=DEBUG, Console, Filetrace > > > log4j.additivity.org.continuent.hedera.channel=false > > > # Hedera Group Membership Service # > > > log4j.logger.org.continuent.hedera.gms=DEBUG, Console, Filetrace > > > log4j.additivity.org.continuent.hedera.gms=false > > > # JGroups > > > log4j.logger.org.jgroups=DEBUG, Console, Filetrace > > > log4j.additivity.org.jgroups=false > > > # JGroups protocols > > > log4j.logger.org.jgroups.protocols=DEBUG, Console, Filetrace > > > log4j.additivity.org.jgroups.protocols=false > > > ###################################### > > > > > > I've the distributed logs for the same time-frame. Let me know if you > need that. > > > > > > No, the hedera were not updated. > > > > > > Thanks, > > > Seby. > > > -----Original Message----- > > > From: seq...@li... > [mailto:seq...@li...] On Behalf Of > Emmanuel Cecchet > > > Sent: Tuesday, May 04, 2010 6:20 AM > > > To: Sequoia general mailing list > > > Cc: seq...@li... > > > Subject: Re: [Sequoia] Failure detection > > > > > > Hi Seby, > > > > > > When JGroups reported the MERGE messages in the log, did you have Hedera > > > DEBUG logs enabled too? If this is the case, the message was never > > > handled by Hedera which is a problem. The new view should have been > > > installed anyway by the view synchrony layer and Hedera should at least > > > catch that. > > > Can you confirm is the Hedera logs are enabled? > > > Could you also set the Distributed Virtual Database logs to DEBUG? > > > Did you try to update Hedera to a newer version? > > > > > > Thanks > > > Emmanuel > > > > > > > > >> Hi Emmanuel, > > >> > > >> Do you need more logs on this. Please let me know. > > >> > > >> Thanks, > > >> Seby. > > >> > > >> -----Original Message----- > > >> From: seq...@li... > [mailto:seq...@li...] On Behalf Of > Francis, Seby > > >> Sent: Monday, March 29, 2010 1:51 PM > > >> To: Sequoia general mailing list > > >> Cc: seq...@li... > > >> Subject: Re: [Sequoia] Failure detection > > >> > > >> Hi Emmanuel, > > >> > > >> I've tried different jgroup configuration and now I can see in the > logs that the groups are merging. But for some reason, Sequoia never > shows that it is merged. Ie; when I ran 'show controllers' on console > I see only that particular host. Below is the snippet from one of the > host. I see the similar on the other host showing the merge. Let me > know if you would like to see the debug logs during the time-frame. > > >> > > >> 2010-03-29 06:59:45,683 DEBUG jgroups.protocols.VERIFY_SUSPECT > diff=1507, mbr 10.0.0.33:35974 is dead (passing up SUSPECT event) > > >> 2010-03-29 06:59:45,687 DEBUG continuent.hedera.gms JGroups reported > suspected member:10.0.0.33:35974 > > >> 2010-03-29 06:59:45,688 DEBUG continuent.hedera.gms > Member(address=/10.0.0.33:35974, uid=db2) leaves Group(gid=db2). > > >> > > >> 2010-03-29 06:59:45,868 INFO controller.requestmanager.cleanup > Waiting 30000ms for client of controller 562949953421312 to failover > > >> 2010-03-29 07:00:15,875 INFO controller.requestmanager.cleanup > Cleanup for controller 562949953421312 failure is completed. > > >> > > >> ----- > > >> 2010-03-29 07:03:14,725 DEBUG protocols.pbcast.GMS I > (10.0.0.23:49731) will be the leader. Starting the merge task for > [10.0.0.33:35974, 10.0.0.23:49731] > > >> 2010-03-29 07:03:14,726 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 > running merge task, coordinators are [10.0.0.33:35974, 10.0.0.23:49731] > > >> 2010-03-29 07:03:14,730 DEBUG protocols.pbcast.GMS Merge leader > 10.0.0.23:49731 sending MERGE_REQ to [10.0.0.33:35974, 10.0.0.23:49731] > > >> 2010-03-29 07:03:14,746 DEBUG jgroups.protocols.UDP sending msg to > 10.0.0.23:49731, src=10.0.0.23:49731, headers are GMS: > GmsHeader[MERGE_RSP]: view=[10.0.0.23:49731|2] [10.0.0.23:49731], > digest=10.0.0.23:49731: [44 : 47 (47)], merge_rejected=false, > merge_id=[10.0.0.23:49731|1269860594727], UNICAST: [UNICAST: DATA, > seqno=4], UDP: [channel_name=db2] > > >> 2010-03-29 07:03:14,748 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 > responded to 10.0.0.23:49731, merge_id=[10.0.0.23:49731|1269860594727] > > >> 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader > 10.0.0.23:49731 expects 2 responses, so far got 2 responses > > >> 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader > 10.0.0.23:49731 collected 2 merge response(s) in 36 ms > > >> 2010-03-29 07:03:14,772 DEBUG protocols.pbcast.GMS Merge leader > 10.0.0.23:49731 computed new merged view that will be > MergeView::[10.0.0.23:49731|3] [10.0.0.23:49731, 10.0.0.33:35974], > subgroups=[[10.0.0.23:49731|2] [10.0.0.23:49731], [10.0.0.33:35974|2] > [10.0.0.33:35974]] > > >> 2010-03-29 07:03:14,773 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 > is sending merge view [10.0.0.23:49731|3] to coordinators > [10.0.0.33:35974, 10.0.0.23:49731 > > >> > > >> Seby. > > >> > > >> -----Original Message----- > > >> From: seq...@li... > [mailto:seq...@li...] On Behalf Of > Emmanuel Cecchet > > >> Sent: Wednesday, March 24, 2010 10:41 AM > > >> To: Sequoia general mailing list > > >> Cc: seq...@li... > > >> Subject: Re: [Sequoia] Failure detection > > >> > > >> Hi Seby, > > >> > > >> Sorry for the late reply, I have been very busy these past days. > > >> This seems to be a JGroups issue that could probably be better answered > > >> by Bela Ban on the JGroups mailing list. I have seen emails these past > > >> days on the list with people having similar problem. > > >> I would recommend that you post an email on the JGroups mailing list > > >> with your JGroups configuration and the messages you see regarding > MERGE > > >> failing. > > >> > > >> Keep me posted > > >> Emmanuel > > >> > > >> > > >> > > >>> Also, here is the error which I see from the logs: > > >>> > > >>> 2010-03-22 08:31:15,912 DEBUG protocols.pbcast.GMS Merge leader > 10.10.10.23:39729 expects 2 responses, so far got 1 responses > > >>> 2010-03-22 08:31:15,913 DEBUG protocols.pbcast.GMS Merge leader > 10.10.10.23:39729 waiting 382 msecs for merge responses > > >>> 2010-03-22 08:31:16,313 DEBUG protocols.pbcast.GMS At > 10.10.10.23:39729 cancelling merge due to timer timeout (5000 ms) > > >>> 2010-03-22 08:31:16,314 DEBUG protocols.pbcast.GMS cancelling merge > (merge_id=[10.10.10.23:39729|1269261071286]) > > >>> 2010-03-22 08:31:16,316 DEBUG protocols.pbcast.GMS resumed ViewHandler > > >>> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader > 10.10.10.23:39729 expects 2 responses, so far got 0 responses > > >>> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader > 10.10.10.23:39729 collected 0 merge response(s) in 5027 ms > > >>> 2010-03-22 08:31:16,318 WARN protocols.pbcast.GMS Merge aborted. > Merge leader did not get MergeData from all subgroup coordinators > [10.10.10.33:38822, 10.10.10.23:39729] > > >>> > > >>> -----Original Message----- > > >>> From: Francis, Seby > > >>> Sent: Monday, March 22, 2010 1:03 PM > > >>> To: 'Sequoia general mailing list' > > >>> Cc: seq...@li... > > >>> Subject: RE: [Sequoia] Failure detection > > >>> > > >>> Hi Emmanuel, > > >>> > > >>> I've updated my jgroups to the version which you have mentioned, > but I still see the issue with Merging the groups. One of the > controller lost track after the failure and won't merge. Can you > please give me a hand to figure out where it goes wrong. I've the > debug logs. Shall I send the logs as a zip file. > > >>> > > >>> Thanks, > > >>> Seby. > > >>> > > >>> -----Original Message----- > > >>> From: seq...@li... > [mailto:seq...@li...] On Behalf Of > Emmanuel Cecchet > > >>> Sent: Thursday, March 18, 2010 10:22 PM > > >>> To: Sequoia general mailing list > > >>> Cc: seq...@li... > > >>> Subject: Re: [Sequoia] Failure detection > > >>> > > >>> Hi Seby, > > >>> > > >>> I looked into the mailing list archive and this version of JGroups > has a > > >>> number of significant bugs. An issue was filed > > >>> (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it > > >>> for Sequoia 4. Just using a drop in replacement for JGroups core for > > >>> Sequoia 2.10.10 might work. You might have to update Hedera jars as > well > > >>> but that could work with the old one too. > > >>> > > >>> Let me know if the upgrade does not work > > >>> Emmanuel > > >>> > > >>> > > >>> > > >>> > > >>>> Thanks for your support!! > > >>>> > > >>>> I'm using jgroups-core.jar Version 2.4.2 which came with > > >>>> "sequoia-2.10.10". My solaris test servers have only single interface > > >>>> and I'm using the same ip for both group & db/client > communications. I > > >>>> ran a test again removing "*STATE_TRANSFER*" and attached the > logs. At > > >>>> around 13:36, I took the host1 interface down and opened it around > > >>>> 13:38. After I opened the interface, and when I ran the show > > >>>> controllers on console, host1 showed both controllers while host2 > > >>>> showed its own name in the member list. > > >>>> > > >>>> Regards, > > >>>> > > >>>> Seby. > > >>>> > > >>>> -----Original Message----- > > >>>> Hi Seby, > > >>>> > > >>>> Welcome to the wonderful world of group communications! > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> I've tried various FD options and could not get it working when one > > >>>>> > > >>>>> > > >>>>> > > >>>> of the hosts fail. I can see the message 'A leaving group' on live > > >>>> controller B when I shutdown the interface of A. This is working as > > >>>> expected and the virtual db is still accessible/writable as the > > >>>> controller B is alive. But when I open the interface on A, the > > >>>> controller A shows (show controllers) that the virtual-db is > hosted by > > >>>> controllers A & B while controller B just shows B. And the data > > >>>> inserted into the vdb hosted by controller B is NOT being played > on A. > > >>>> This will cause inconsistencies in the data between the virtual-dbs. > > >>>> Is there a way, we can disable the backend if the network goes down, > > >>>> so that I can recover the db using the backup? > > >>>> > > >>>> > > >>>> There is a problem with your group communication configuration if > > >>>> controllers have different views of the group. That should not happen. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> I've also noticed that in some cases, if I take one of the host > > >>>>> > > >>>>> > > >>>>> > > >>>> interface down, both of them thinks that the other controller failed. > > >>>> This will also create issues. In my case, I only have two controllers > > >>>> hosted. Is it possible to ping a network gateway? That way the > > >>>> controller know that it is the one which failed and can disable the > > >>>> backend. > > >>>> > > >>>> > > >>>> The best solution is to use the same interface for group > communication > > >>>> and client/database communications. If you use a dedicated network > for > > >>>> group communications and this network fails, you will end up with a > > >>>> network partition and this is very bad. If all communications go > > >>>> through the same interface, when it goes down, all communications are > > >>>> down and the controller will not be able to serve stale data. > > >>>> > > >>>> You don't need STATE_TRANSFER as Sequoia has its own state transfer > > >>>> protocol when a new member joins a group. Which version of JGroups > are > > >>>> you using? Could you send me the log with JGroups messages that you > > >>>> see on each controller by activating them in log4j.properties. I > would > > >>>> need the initial sequence when you start the cluster and the messages > > >>>> you see when the failure is detected and when the failed controller > > >>>> joins back. There might be a problem with the timeout settings of the > > >>>> different component of the stack. > > >>>> > > >>>> Keep me posted with your findings > > >>>> > > >>>> Emmanuel > > >>>> > > >>>> > ------------------------------------------------------------------------ > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > -- > > Emmanuel Cecchet > > FTO @ Frog Thinker > > Open Source Development & Consulting > > -- > > Web: http://www.frogthinker.org > > email: ma...@fr... > > Skype: emmanuel_cecchet > > _______________________________________________ > > Sequoia mailing list > > Se...@li... > > http://forge.continuent.org/mailman/listinfo/sequoia > > ------------------------------------------------------------------------ > > _______________________________________________ > Sequoia mailing list > Se...@li... > http://forge.continuent.org/mailman/listinfo/sequoia -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-05-08 19:54:33
|
Hi Francis, Do you have the traces with log4j.logger.org.continuent.sequoia.controller.virtualdatabase set to DEBUG? Could you also try with the latest version of Hedera? Sorry for the lag in the responses I have been swamped since I'm back! Emmanuel > Hello Emmanuel, > > Yes, all were in debug. Here is the snippet: > > ###################################### > # Hedera group communication loggers # > ###################################### > # Hedera channels test # > log4j.logger.test.org.continuent.hedera.channel=DEBUG, Console, Filetrace > log4j.additivity.test.org.continuent.hedera.channel=false > # Hedera adapters # > log4j.logger.org.continuent.hedera.adapters=DEBUG, Console, Filetrace > log4j.additivity.org.continuent.hedera.adapters=false > # Hedera factories # > log4j.logger.org.continuent.hedera.factory=DEBUG, Console, Filetrace > log4j.additivity.org.continuent.hedera.factory=false > # Hedera channels # > log4j.logger.org.continuent.hedera.channel=DEBUG, Console, Filetrace > log4j.additivity.org.continuent.hedera.channel=false > # Hedera Group Membership Service # > log4j.logger.org.continuent.hedera.gms=DEBUG, Console, Filetrace > log4j.additivity.org.continuent.hedera.gms=false > # JGroups > log4j.logger.org.jgroups=DEBUG, Console, Filetrace > log4j.additivity.org.jgroups=false > # JGroups protocols > log4j.logger.org.jgroups.protocols=DEBUG, Console, Filetrace > log4j.additivity.org.jgroups.protocols=false > ###################################### > > I've the distributed logs for the same time-frame. Let me know if you need that. > > No, the hedera were not updated. > > Thanks, > Seby. > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Tuesday, May 04, 2010 6:20 AM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Seby, > > When JGroups reported the MERGE messages in the log, did you have Hedera > DEBUG logs enabled too? If this is the case, the message was never > handled by Hedera which is a problem. The new view should have been > installed anyway by the view synchrony layer and Hedera should at least > catch that. > Can you confirm is the Hedera logs are enabled? > Could you also set the Distributed Virtual Database logs to DEBUG? > Did you try to update Hedera to a newer version? > > Thanks > Emmanuel > > >> Hi Emmanuel, >> >> Do you need more logs on this. Please let me know. >> >> Thanks, >> Seby. >> >> -----Original Message----- >> From: seq...@li... [mailto:seq...@li...] On Behalf Of Francis, Seby >> Sent: Monday, March 29, 2010 1:51 PM >> To: Sequoia general mailing list >> Cc: seq...@li... >> Subject: Re: [Sequoia] Failure detection >> >> Hi Emmanuel, >> >> I've tried different jgroup configuration and now I can see in the logs that the groups are merging. But for some reason, Sequoia never shows that it is merged. Ie; when I ran 'show controllers' on console I see only that particular host. Below is the snippet from one of the host. I see the similar on the other host showing the merge. Let me know if you would like to see the debug logs during the time-frame. >> >> 2010-03-29 06:59:45,683 DEBUG jgroups.protocols.VERIFY_SUSPECT diff=1507, mbr 10.0.0.33:35974 is dead (passing up SUSPECT event) >> 2010-03-29 06:59:45,687 DEBUG continuent.hedera.gms JGroups reported suspected member:10.0.0.33:35974 >> 2010-03-29 06:59:45,688 DEBUG continuent.hedera.gms Member(address=/10.0.0.33:35974, uid=db2) leaves Group(gid=db2). >> >> 2010-03-29 06:59:45,868 INFO controller.requestmanager.cleanup Waiting 30000ms for client of controller 562949953421312 to failover >> 2010-03-29 07:00:15,875 INFO controller.requestmanager.cleanup Cleanup for controller 562949953421312 failure is completed. >> >> ----- >> 2010-03-29 07:03:14,725 DEBUG protocols.pbcast.GMS I (10.0.0.23:49731) will be the leader. Starting the merge task for [10.0.0.33:35974, 10.0.0.23:49731] >> 2010-03-29 07:03:14,726 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 running merge task, coordinators are [10.0.0.33:35974, 10.0.0.23:49731] >> 2010-03-29 07:03:14,730 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 sending MERGE_REQ to [10.0.0.33:35974, 10.0.0.23:49731] >> 2010-03-29 07:03:14,746 DEBUG jgroups.protocols.UDP sending msg to 10.0.0.23:49731, src=10.0.0.23:49731, headers are GMS: GmsHeader[MERGE_RSP]: view=[10.0.0.23:49731|2] [10.0.0.23:49731], digest=10.0.0.23:49731: [44 : 47 (47)], merge_rejected=false, merge_id=[10.0.0.23:49731|1269860594727], UNICAST: [UNICAST: DATA, seqno=4], UDP: [channel_name=db2] >> 2010-03-29 07:03:14,748 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 responded to 10.0.0.23:49731, merge_id=[10.0.0.23:49731|1269860594727] >> 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 expects 2 responses, so far got 2 responses >> 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 collected 2 merge response(s) in 36 ms >> 2010-03-29 07:03:14,772 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 computed new merged view that will be MergeView::[10.0.0.23:49731|3] [10.0.0.23:49731, 10.0.0.33:35974], subgroups=[[10.0.0.23:49731|2] [10.0.0.23:49731], [10.0.0.33:35974|2] [10.0.0.33:35974]] >> 2010-03-29 07:03:14,773 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 is sending merge view [10.0.0.23:49731|3] to coordinators [10.0.0.33:35974, 10.0.0.23:49731 >> >> Seby. >> >> -----Original Message----- >> From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet >> Sent: Wednesday, March 24, 2010 10:41 AM >> To: Sequoia general mailing list >> Cc: seq...@li... >> Subject: Re: [Sequoia] Failure detection >> >> Hi Seby, >> >> Sorry for the late reply, I have been very busy these past days. >> This seems to be a JGroups issue that could probably be better answered >> by Bela Ban on the JGroups mailing list. I have seen emails these past >> days on the list with people having similar problem. >> I would recommend that you post an email on the JGroups mailing list >> with your JGroups configuration and the messages you see regarding MERGE >> failing. >> >> Keep me posted >> Emmanuel >> >> >> >>> Also, here is the error which I see from the logs: >>> >>> 2010-03-22 08:31:15,912 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 1 responses >>> 2010-03-22 08:31:15,913 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 waiting 382 msecs for merge responses >>> 2010-03-22 08:31:16,313 DEBUG protocols.pbcast.GMS At 10.10.10.23:39729 cancelling merge due to timer timeout (5000 ms) >>> 2010-03-22 08:31:16,314 DEBUG protocols.pbcast.GMS cancelling merge (merge_id=[10.10.10.23:39729|1269261071286]) >>> 2010-03-22 08:31:16,316 DEBUG protocols.pbcast.GMS resumed ViewHandler >>> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 0 responses >>> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 collected 0 merge response(s) in 5027 ms >>> 2010-03-22 08:31:16,318 WARN protocols.pbcast.GMS Merge aborted. Merge leader did not get MergeData from all subgroup coordinators [10.10.10.33:38822, 10.10.10.23:39729] >>> >>> -----Original Message----- >>> From: Francis, Seby >>> Sent: Monday, March 22, 2010 1:03 PM >>> To: 'Sequoia general mailing list' >>> Cc: seq...@li... >>> Subject: RE: [Sequoia] Failure detection >>> >>> Hi Emmanuel, >>> >>> I've updated my jgroups to the version which you have mentioned, but I still see the issue with Merging the groups. One of the controller lost track after the failure and won't merge. Can you please give me a hand to figure out where it goes wrong. I've the debug logs. Shall I send the logs as a zip file. >>> >>> Thanks, >>> Seby. >>> >>> -----Original Message----- >>> From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet >>> Sent: Thursday, March 18, 2010 10:22 PM >>> To: Sequoia general mailing list >>> Cc: seq...@li... >>> Subject: Re: [Sequoia] Failure detection >>> >>> Hi Seby, >>> >>> I looked into the mailing list archive and this version of JGroups has a >>> number of significant bugs. An issue was filed >>> (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it >>> for Sequoia 4. Just using a drop in replacement for JGroups core for >>> Sequoia 2.10.10 might work. You might have to update Hedera jars as well >>> but that could work with the old one too. >>> >>> Let me know if the upgrade does not work >>> Emmanuel >>> >>> >>> >>> >>>> Thanks for your support!! >>>> >>>> I'm using jgroups-core.jar Version 2.4.2 which came with >>>> "sequoia-2.10.10". My solaris test servers have only single interface >>>> and I'm using the same ip for both group & db/client communications. I >>>> ran a test again removing "*STATE_TRANSFER*" and attached the logs. At >>>> around 13:36, I took the host1 interface down and opened it around >>>> 13:38. After I opened the interface, and when I ran the show >>>> controllers on console, host1 showed both controllers while host2 >>>> showed its own name in the member list. >>>> >>>> Regards, >>>> >>>> Seby. >>>> >>>> -----Original Message----- >>>> Hi Seby, >>>> >>>> Welcome to the wonderful world of group communications! >>>> >>>> >>>> >>>> >>>>> I've tried various FD options and could not get it working when one >>>>> >>>>> >>>>> >>>> of the hosts fail. I can see the message 'A leaving group' on live >>>> controller B when I shutdown the interface of A. This is working as >>>> expected and the virtual db is still accessible/writable as the >>>> controller B is alive. But when I open the interface on A, the >>>> controller A shows (show controllers) that the virtual-db is hosted by >>>> controllers A & B while controller B just shows B. And the data >>>> inserted into the vdb hosted by controller B is NOT being played on A. >>>> This will cause inconsistencies in the data between the virtual-dbs. >>>> Is there a way, we can disable the backend if the network goes down, >>>> so that I can recover the db using the backup? >>>> >>>> >>>> There is a problem with your group communication configuration if >>>> controllers have different views of the group. That should not happen. >>>> >>>> >>>> >>>> >>>>> I've also noticed that in some cases, if I take one of the host >>>>> >>>>> >>>>> >>>> interface down, both of them thinks that the other controller failed. >>>> This will also create issues. In my case, I only have two controllers >>>> hosted. Is it possible to ping a network gateway? That way the >>>> controller know that it is the one which failed and can disable the >>>> backend. >>>> >>>> >>>> The best solution is to use the same interface for group communication >>>> and client/database communications. If you use a dedicated network for >>>> group communications and this network fails, you will end up with a >>>> network partition and this is very bad. If all communications go >>>> through the same interface, when it goes down, all communications are >>>> down and the controller will not be able to serve stale data. >>>> >>>> You don't need STATE_TRANSFER as Sequoia has its own state transfer >>>> protocol when a new member joins a group. Which version of JGroups are >>>> you using? Could you send me the log with JGroups messages that you >>>> see on each controller by activating them in log4j.properties. I would >>>> need the initial sequence when you start the cluster and the messages >>>> you see when the failure is detected and when the failed controller >>>> joins back. There might be a problem with the timeout settings of the >>>> different component of the stack. >>>> >>>> Keep me posted with your findings >>>> >>>> Emmanuel >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>> >>> >>> >> >> > > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-05-04 10:20:15
|
Hi Seby, When JGroups reported the MERGE messages in the log, did you have Hedera DEBUG logs enabled too? If this is the case, the message was never handled by Hedera which is a problem. The new view should have been installed anyway by the view synchrony layer and Hedera should at least catch that. Can you confirm is the Hedera logs are enabled? Could you also set the Distributed Virtual Database logs to DEBUG? Did you try to update Hedera to a newer version? Thanks Emmanuel > Hi Emmanuel, > > Do you need more logs on this. Please let me know. > > Thanks, > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Francis, Seby > Sent: Monday, March 29, 2010 1:51 PM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Emmanuel, > > I've tried different jgroup configuration and now I can see in the logs that the groups are merging. But for some reason, Sequoia never shows that it is merged. Ie; when I ran 'show controllers' on console I see only that particular host. Below is the snippet from one of the host. I see the similar on the other host showing the merge. Let me know if you would like to see the debug logs during the time-frame. > > 2010-03-29 06:59:45,683 DEBUG jgroups.protocols.VERIFY_SUSPECT diff=1507, mbr 10.0.0.33:35974 is dead (passing up SUSPECT event) > 2010-03-29 06:59:45,687 DEBUG continuent.hedera.gms JGroups reported suspected member:10.0.0.33:35974 > 2010-03-29 06:59:45,688 DEBUG continuent.hedera.gms Member(address=/10.0.0.33:35974, uid=db2) leaves Group(gid=db2). > > 2010-03-29 06:59:45,868 INFO controller.requestmanager.cleanup Waiting 30000ms for client of controller 562949953421312 to failover > 2010-03-29 07:00:15,875 INFO controller.requestmanager.cleanup Cleanup for controller 562949953421312 failure is completed. > > ----- > 2010-03-29 07:03:14,725 DEBUG protocols.pbcast.GMS I (10.0.0.23:49731) will be the leader. Starting the merge task for [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,726 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 running merge task, coordinators are [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,730 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 sending MERGE_REQ to [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,746 DEBUG jgroups.protocols.UDP sending msg to 10.0.0.23:49731, src=10.0.0.23:49731, headers are GMS: GmsHeader[MERGE_RSP]: view=[10.0.0.23:49731|2] [10.0.0.23:49731], digest=10.0.0.23:49731: [44 : 47 (47)], merge_rejected=false, merge_id=[10.0.0.23:49731|1269860594727], UNICAST: [UNICAST: DATA, seqno=4], UDP: [channel_name=db2] > 2010-03-29 07:03:14,748 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 responded to 10.0.0.23:49731, merge_id=[10.0.0.23:49731|1269860594727] > 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 expects 2 responses, so far got 2 responses > 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 collected 2 merge response(s) in 36 ms > 2010-03-29 07:03:14,772 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 computed new merged view that will be MergeView::[10.0.0.23:49731|3] [10.0.0.23:49731, 10.0.0.33:35974], subgroups=[[10.0.0.23:49731|2] [10.0.0.23:49731], [10.0.0.33:35974|2] [10.0.0.33:35974]] > 2010-03-29 07:03:14,773 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 is sending merge view [10.0.0.23:49731|3] to coordinators [10.0.0.33:35974, 10.0.0.23:49731 > > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Wednesday, March 24, 2010 10:41 AM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Seby, > > Sorry for the late reply, I have been very busy these past days. > This seems to be a JGroups issue that could probably be better answered > by Bela Ban on the JGroups mailing list. I have seen emails these past > days on the list with people having similar problem. > I would recommend that you post an email on the JGroups mailing list > with your JGroups configuration and the messages you see regarding MERGE > failing. > > Keep me posted > Emmanuel > > >> Also, here is the error which I see from the logs: >> >> 2010-03-22 08:31:15,912 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 1 responses >> 2010-03-22 08:31:15,913 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 waiting 382 msecs for merge responses >> 2010-03-22 08:31:16,313 DEBUG protocols.pbcast.GMS At 10.10.10.23:39729 cancelling merge due to timer timeout (5000 ms) >> 2010-03-22 08:31:16,314 DEBUG protocols.pbcast.GMS cancelling merge (merge_id=[10.10.10.23:39729|1269261071286]) >> 2010-03-22 08:31:16,316 DEBUG protocols.pbcast.GMS resumed ViewHandler >> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 0 responses >> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 collected 0 merge response(s) in 5027 ms >> 2010-03-22 08:31:16,318 WARN protocols.pbcast.GMS Merge aborted. Merge leader did not get MergeData from all subgroup coordinators [10.10.10.33:38822, 10.10.10.23:39729] >> >> -----Original Message----- >> From: Francis, Seby >> Sent: Monday, March 22, 2010 1:03 PM >> To: 'Sequoia general mailing list' >> Cc: seq...@li... >> Subject: RE: [Sequoia] Failure detection >> >> Hi Emmanuel, >> >> I've updated my jgroups to the version which you have mentioned, but I still see the issue with Merging the groups. One of the controller lost track after the failure and won't merge. Can you please give me a hand to figure out where it goes wrong. I've the debug logs. Shall I send the logs as a zip file. >> >> Thanks, >> Seby. >> >> -----Original Message----- >> From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet >> Sent: Thursday, March 18, 2010 10:22 PM >> To: Sequoia general mailing list >> Cc: seq...@li... >> Subject: Re: [Sequoia] Failure detection >> >> Hi Seby, >> >> I looked into the mailing list archive and this version of JGroups has a >> number of significant bugs. An issue was filed >> (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it >> for Sequoia 4. Just using a drop in replacement for JGroups core for >> Sequoia 2.10.10 might work. You might have to update Hedera jars as well >> but that could work with the old one too. >> >> Let me know if the upgrade does not work >> Emmanuel >> >> >> >>> Thanks for your support!! >>> >>> I'm using jgroups-core.jar Version 2.4.2 which came with >>> "sequoia-2.10.10". My solaris test servers have only single interface >>> and I'm using the same ip for both group & db/client communications. I >>> ran a test again removing "*STATE_TRANSFER*" and attached the logs. At >>> around 13:36, I took the host1 interface down and opened it around >>> 13:38. After I opened the interface, and when I ran the show >>> controllers on console, host1 showed both controllers while host2 >>> showed its own name in the member list. >>> >>> Regards, >>> >>> Seby. >>> >>> -----Original Message----- >>> Hi Seby, >>> >>> Welcome to the wonderful world of group communications! >>> >>> >>> >>>> I've tried various FD options and could not get it working when one >>>> >>>> >>> of the hosts fail. I can see the message 'A leaving group' on live >>> controller B when I shutdown the interface of A. This is working as >>> expected and the virtual db is still accessible/writable as the >>> controller B is alive. But when I open the interface on A, the >>> controller A shows (show controllers) that the virtual-db is hosted by >>> controllers A & B while controller B just shows B. And the data >>> inserted into the vdb hosted by controller B is NOT being played on A. >>> This will cause inconsistencies in the data between the virtual-dbs. >>> Is there a way, we can disable the backend if the network goes down, >>> so that I can recover the db using the backup? >>> >>> >>> There is a problem with your group communication configuration if >>> controllers have different views of the group. That should not happen. >>> >>> >>> >>>> I've also noticed that in some cases, if I take one of the host >>>> >>>> >>> interface down, both of them thinks that the other controller failed. >>> This will also create issues. In my case, I only have two controllers >>> hosted. Is it possible to ping a network gateway? That way the >>> controller know that it is the one which failed and can disable the >>> backend. >>> >>> >>> The best solution is to use the same interface for group communication >>> and client/database communications. If you use a dedicated network for >>> group communications and this network fails, you will end up with a >>> network partition and this is very bad. If all communications go >>> through the same interface, when it goes down, all communications are >>> down and the controller will not be able to serve stale data. >>> >>> You don't need STATE_TRANSFER as Sequoia has its own state transfer >>> protocol when a new member joins a group. Which version of JGroups are >>> you using? Could you send me the log with JGroups messages that you >>> see on each controller by activating them in log4j.properties. I would >>> need the initial sequence when you start the cluster and the messages >>> you see when the failure is detected and when the failed controller >>> joins back. There might be a problem with the timeout settings of the >>> different component of the stack. >>> >>> Keep me posted with your findings >>> >>> Emmanuel >>> >>> ------------------------------------------------------------------------ >>> >> >> > > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-05-01 04:01:50
|
Hi Francis, > Are you back? > Not yet, I am in Sydney right now and I am flying back home (it should take about 24 hours). I should be back online on Monday. Talk to you soon Emmanuel > Seby. > -----Original Message----- > From: Francis, Seby > Sent: Monday, April 05, 2010 11:26 PM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: RE: [Sequoia] Failure detection > > Hi Emmanuel, > > Do you need more logs on this. Please let me know. > > Thanks, > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Francis, Seby > Sent: Monday, March 29, 2010 1:51 PM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Emmanuel, > > I've tried different jgroup configuration and now I can see in the logs that the groups are merging. But for some reason, Sequoia never shows that it is merged. Ie; when I ran 'show controllers' on console I see only that particular host. Below is the snippet from one of the host. I see the similar on the other host showing the merge. Let me know if you would like to see the debug logs during the time-frame. > > 2010-03-29 06:59:45,683 DEBUG jgroups.protocols.VERIFY_SUSPECT diff=1507, mbr 10.0.0.33:35974 is dead (passing up SUSPECT event) > 2010-03-29 06:59:45,687 DEBUG continuent.hedera.gms JGroups reported suspected member:10.0.0.33:35974 > 2010-03-29 06:59:45,688 DEBUG continuent.hedera.gms Member(address=/10.0.0.33:35974, uid=db2) leaves Group(gid=db2). > > 2010-03-29 06:59:45,868 INFO controller.requestmanager.cleanup Waiting 30000ms for client of controller 562949953421312 to failover > 2010-03-29 07:00:15,875 INFO controller.requestmanager.cleanup Cleanup for controller 562949953421312 failure is completed. > > ----- > 2010-03-29 07:03:14,725 DEBUG protocols.pbcast.GMS I (10.0.0.23:49731) will be the leader. Starting the merge task for [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,726 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 running merge task, coordinators are [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,730 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 sending MERGE_REQ to [10.0.0.33:35974, 10.0.0.23:49731] > 2010-03-29 07:03:14,746 DEBUG jgroups.protocols.UDP sending msg to 10.0.0.23:49731, src=10.0.0.23:49731, headers are GMS: GmsHeader[MERGE_RSP]: view=[10.0.0.23:49731|2] [10.0.0.23:49731], digest=10.0.0.23:49731: [44 : 47 (47)], merge_rejected=false, merge_id=[10.0.0.23:49731|1269860594727], UNICAST: [UNICAST: DATA, seqno=4], UDP: [channel_name=db2] > 2010-03-29 07:03:14,748 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 responded to 10.0.0.23:49731, merge_id=[10.0.0.23:49731|1269860594727] > 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 expects 2 responses, so far got 2 responses > 2010-03-29 07:03:14,766 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 collected 2 merge response(s) in 36 ms > 2010-03-29 07:03:14,772 DEBUG protocols.pbcast.GMS Merge leader 10.0.0.23:49731 computed new merged view that will be MergeView::[10.0.0.23:49731|3] [10.0.0.23:49731, 10.0.0.33:35974], subgroups=[[10.0.0.23:49731|2] [10.0.0.23:49731], [10.0.0.33:35974|2] [10.0.0.33:35974]] > 2010-03-29 07:03:14,773 DEBUG protocols.pbcast.GMS 10.0.0.23:49731 is sending merge view [10.0.0.23:49731|3] to coordinators [10.0.0.33:35974, 10.0.0.23:49731 > > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Wednesday, March 24, 2010 10:41 AM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Seby, > > Sorry for the late reply, I have been very busy these past days. > This seems to be a JGroups issue that could probably be better answered > by Bela Ban on the JGroups mailing list. I have seen emails these past > days on the list with people having similar problem. > I would recommend that you post an email on the JGroups mailing list > with your JGroups configuration and the messages you see regarding MERGE > failing. > > Keep me posted > Emmanuel > > >> Also, here is the error which I see from the logs: >> >> 2010-03-22 08:31:15,912 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 1 responses >> 2010-03-22 08:31:15,913 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 waiting 382 msecs for merge responses >> 2010-03-22 08:31:16,313 DEBUG protocols.pbcast.GMS At 10.10.10.23:39729 cancelling merge due to timer timeout (5000 ms) >> 2010-03-22 08:31:16,314 DEBUG protocols.pbcast.GMS cancelling merge (merge_id=[10.10.10.23:39729|1269261071286]) >> 2010-03-22 08:31:16,316 DEBUG protocols.pbcast.GMS resumed ViewHandler >> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 0 responses >> 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 collected 0 merge response(s) in 5027 ms >> 2010-03-22 08:31:16,318 WARN protocols.pbcast.GMS Merge aborted. Merge leader did not get MergeData from all subgroup coordinators [10.10.10.33:38822, 10.10.10.23:39729] >> >> -----Original Message----- >> From: Francis, Seby >> Sent: Monday, March 22, 2010 1:03 PM >> To: 'Sequoia general mailing list' >> Cc: seq...@li... >> Subject: RE: [Sequoia] Failure detection >> >> Hi Emmanuel, >> >> I've updated my jgroups to the version which you have mentioned, but I still see the issue with Merging the groups. One of the controller lost track after the failure and won't merge. Can you please give me a hand to figure out where it goes wrong. I've the debug logs. Shall I send the logs as a zip file. >> >> Thanks, >> Seby. >> >> -----Original Message----- >> From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet >> Sent: Thursday, March 18, 2010 10:22 PM >> To: Sequoia general mailing list >> Cc: seq...@li... >> Subject: Re: [Sequoia] Failure detection >> >> Hi Seby, >> >> I looked into the mailing list archive and this version of JGroups has a >> number of significant bugs. An issue was filed >> (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it >> for Sequoia 4. Just using a drop in replacement for JGroups core for >> Sequoia 2.10.10 might work. You might have to update Hedera jars as well >> but that could work with the old one too. >> >> Let me know if the upgrade does not work >> Emmanuel >> >> >> >>> Thanks for your support!! >>> >>> I'm using jgroups-core.jar Version 2.4.2 which came with >>> "sequoia-2.10.10". My solaris test servers have only single interface >>> and I'm using the same ip for both group & db/client communications. I >>> ran a test again removing "*STATE_TRANSFER*" and attached the logs. At >>> around 13:36, I took the host1 interface down and opened it around >>> 13:38. After I opened the interface, and when I ran the show >>> controllers on console, host1 showed both controllers while host2 >>> showed its own name in the member list. >>> >>> Regards, >>> >>> Seby. >>> >>> -----Original Message----- >>> Hi Seby, >>> >>> Welcome to the wonderful world of group communications! >>> >>> >>> >>>> I've tried various FD options and could not get it working when one >>>> >>>> >>> of the hosts fail. I can see the message 'A leaving group' on live >>> controller B when I shutdown the interface of A. This is working as >>> expected and the virtual db is still accessible/writable as the >>> controller B is alive. But when I open the interface on A, the >>> controller A shows (show controllers) that the virtual-db is hosted by >>> controllers A & B while controller B just shows B. And the data >>> inserted into the vdb hosted by controller B is NOT being played on A. >>> This will cause inconsistencies in the data between the virtual-dbs. >>> Is there a way, we can disable the backend if the network goes down, >>> so that I can recover the db using the backup? >>> >>> >>> There is a problem with your group communication configuration if >>> controllers have different views of the group. That should not happen. >>> >>> >>> >>>> I've also noticed that in some cases, if I take one of the host >>>> >>>> >>> interface down, both of them thinks that the other controller failed. >>> This will also create issues. In my case, I only have two controllers >>> hosted. Is it possible to ping a network gateway? That way the >>> controller know that it is the one which failed and can disable the >>> backend. >>> >>> >>> The best solution is to use the same interface for group communication >>> and client/database communications. If you use a dedicated network for >>> group communications and this network fails, you will end up with a >>> network partition and this is very bad. If all communications go >>> through the same interface, when it goes down, all communications are >>> down and the controller will not be able to serve stale data. >>> >>> You don't need STATE_TRANSFER as Sequoia has its own state transfer >>> protocol when a new member joins a group. Which version of JGroups are >>> you using? Could you send me the log with JGroups messages that you >>> see on each controller by activating them in log4j.properties. I would >>> need the initial sequence when you start the cluster and the messages >>> you see when the failure is detected and when the failed controller >>> joins back. There might be a problem with the timeout settings of the >>> different component of the stack. >>> >>> Keep me posted with your findings >>> >>> Emmanuel >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Sequoia mailing list >>> Se...@li... >>> http://forge.continuent.org/mailman/listinfo/sequoia >>> >>> >> >> > > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-03-24 14:41:30
|
Hi Seby, Sorry for the late reply, I have been very busy these past days. This seems to be a JGroups issue that could probably be better answered by Bela Ban on the JGroups mailing list. I have seen emails these past days on the list with people having similar problem. I would recommend that you post an email on the JGroups mailing list with your JGroups configuration and the messages you see regarding MERGE failing. Keep me posted Emmanuel > Also, here is the error which I see from the logs: > > 2010-03-22 08:31:15,912 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 1 responses > 2010-03-22 08:31:15,913 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 waiting 382 msecs for merge responses > 2010-03-22 08:31:16,313 DEBUG protocols.pbcast.GMS At 10.10.10.23:39729 cancelling merge due to timer timeout (5000 ms) > 2010-03-22 08:31:16,314 DEBUG protocols.pbcast.GMS cancelling merge (merge_id=[10.10.10.23:39729|1269261071286]) > 2010-03-22 08:31:16,316 DEBUG protocols.pbcast.GMS resumed ViewHandler > 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 expects 2 responses, so far got 0 responses > 2010-03-22 08:31:16,317 DEBUG protocols.pbcast.GMS Merge leader 10.10.10.23:39729 collected 0 merge response(s) in 5027 ms > 2010-03-22 08:31:16,318 WARN protocols.pbcast.GMS Merge aborted. Merge leader did not get MergeData from all subgroup coordinators [10.10.10.33:38822, 10.10.10.23:39729] > > -----Original Message----- > From: Francis, Seby > Sent: Monday, March 22, 2010 1:03 PM > To: 'Sequoia general mailing list' > Cc: seq...@li... > Subject: RE: [Sequoia] Failure detection > > Hi Emmanuel, > > I've updated my jgroups to the version which you have mentioned, but I still see the issue with Merging the groups. One of the controller lost track after the failure and won't merge. Can you please give me a hand to figure out where it goes wrong. I've the debug logs. Shall I send the logs as a zip file. > > Thanks, > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Thursday, March 18, 2010 10:22 PM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Seby, > > I looked into the mailing list archive and this version of JGroups has a > number of significant bugs. An issue was filed > (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it > for Sequoia 4. Just using a drop in replacement for JGroups core for > Sequoia 2.10.10 might work. You might have to update Hedera jars as well > but that could work with the old one too. > > Let me know if the upgrade does not work > Emmanuel > > >> Thanks for your support!! >> >> I'm using jgroups-core.jar Version 2.4.2 which came with >> "sequoia-2.10.10". My solaris test servers have only single interface >> and I'm using the same ip for both group & db/client communications. I >> ran a test again removing "*STATE_TRANSFER*" and attached the logs. At >> around 13:36, I took the host1 interface down and opened it around >> 13:38. After I opened the interface, and when I ran the show >> controllers on console, host1 showed both controllers while host2 >> showed its own name in the member list. >> >> Regards, >> >> Seby. >> >> -----Original Message----- >> Hi Seby, >> >> Welcome to the wonderful world of group communications! >> >> >>> I've tried various FD options and could not get it working when one >>> >> of the hosts fail. I can see the message 'A leaving group' on live >> controller B when I shutdown the interface of A. This is working as >> expected and the virtual db is still accessible/writable as the >> controller B is alive. But when I open the interface on A, the >> controller A shows (show controllers) that the virtual-db is hosted by >> controllers A & B while controller B just shows B. And the data >> inserted into the vdb hosted by controller B is NOT being played on A. >> This will cause inconsistencies in the data between the virtual-dbs. >> Is there a way, we can disable the backend if the network goes down, >> so that I can recover the db using the backup? >> >> >> There is a problem with your group communication configuration if >> controllers have different views of the group. That should not happen. >> >> >>> I've also noticed that in some cases, if I take one of the host >>> >> interface down, both of them thinks that the other controller failed. >> This will also create issues. In my case, I only have two controllers >> hosted. Is it possible to ping a network gateway? That way the >> controller know that it is the one which failed and can disable the >> backend. >> >> >> The best solution is to use the same interface for group communication >> and client/database communications. If you use a dedicated network for >> group communications and this network fails, you will end up with a >> network partition and this is very bad. If all communications go >> through the same interface, when it goes down, all communications are >> down and the controller will not be able to serve stale data. >> >> You don't need STATE_TRANSFER as Sequoia has its own state transfer >> protocol when a new member joins a group. Which version of JGroups are >> you using? Could you send me the log with JGroups messages that you >> see on each controller by activating them in log4j.properties. I would >> need the initial sequence when you start the cluster and the messages >> you see when the failure is detected and when the failed controller >> joins back. There might be a problem with the timeout settings of the >> different component of the stack. >> >> Keep me posted with your findings >> >> Emmanuel >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Sequoia mailing list >> Se...@li... >> http://forge.continuent.org/mailman/listinfo/sequoia >> > > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-03-19 02:22:05
|
Hi Seby, I looked into the mailing list archive and this version of JGroups has a number of significant bugs. An issue was filed (http://forge.continuent.org/jira/browse/SEQUOIA-1130) and I fixed it for Sequoia 4. Just using a drop in replacement for JGroups core for Sequoia 2.10.10 might work. You might have to update Hedera jars as well but that could work with the old one too. Let me know if the upgrade does not work Emmanuel > Thanks for your support!! > > I’m using jgroups-core.jar Version 2.4.2 which came with > “sequoia-2.10.10”. My solaris test servers have only single interface > and I’m using the same ip for both group & db/client communications. I > ran a test again removing “*STATE_TRANSFER*” and attached the logs. At > around 13:36, I took the host1 interface down and opened it around > 13:38. After I opened the interface, and when I ran the show > controllers on console, host1 showed both controllers while host2 > showed its own name in the member list. > > Regards, > > Seby. > > -----Original Message----- > Hi Seby, > > Welcome to the wonderful world of group communications! > > > I've tried various FD options and could not get it working when one > of the hosts fail. I can see the message 'A leaving group' on live > controller B when I shutdown the interface of A. This is working as > expected and the virtual db is still accessible/writable as the > controller B is alive. But when I open the interface on A, the > controller A shows (show controllers) that the virtual-db is hosted by > controllers A & B while controller B just shows B. And the data > inserted into the vdb hosted by controller B is NOT being played on A. > This will cause inconsistencies in the data between the virtual-dbs. > Is there a way, we can disable the backend if the network goes down, > so that I can recover the db using the backup? > > > > > There is a problem with your group communication configuration if > controllers have different views of the group. That should not happen. > > > I've also noticed that in some cases, if I take one of the host > interface down, both of them thinks that the other controller failed. > This will also create issues. In my case, I only have two controllers > hosted. Is it possible to ping a network gateway? That way the > controller know that it is the one which failed and can disable the > backend. > > > > > The best solution is to use the same interface for group communication > and client/database communications. If you use a dedicated network for > group communications and this network fails, you will end up with a > network partition and this is very bad. If all communications go > through the same interface, when it goes down, all communications are > down and the controller will not be able to serve stale data. > > You don't need STATE_TRANSFER as Sequoia has its own state transfer > protocol when a new member joins a group. Which version of JGroups are > you using? Could you send me the log with JGroups messages that you > see on each controller by activating them in log4j.properties. I would > need the initial sequence when you start the cluster and the messages > you see when the failure is detected and when the failed controller > joins back. There might be a problem with the timeout settings of the > different component of the stack. > > Keep me posted with your findings > > Emmanuel > > ------------------------------------------------------------------------ > > _______________________________________________ > Sequoia mailing list > Se...@li... > http://forge.continuent.org/mailman/listinfo/sequoia -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-03-18 12:38:44
|
Hi Seby, Welcome to the wonderful world of group communications! > I've tried various FD options and could not get it working when one of the hosts fail. I can see the message 'A leaving group' on live controller B when I shutdown the interface of A. This is working as expected and the virtual db is still accessible/writable as the controller B is alive. But when I open the interface on A, the controller A shows (show controllers) that the virtual-db is hosted by controllers A & B while controller B just shows B. And the data inserted into the vdb hosted by controller B is NOT being played on A. This will cause inconsistencies in the data between the virtual-dbs. Is there a way, we can disable the backend if the network goes down, so that I can recover the db using the backup? > There is a problem with your group communication configuration if controllers have different views of the group. That should not happen. > I've also noticed that in some cases, if I take one of the host interface down, both of them thinks that the other controller failed. This will also create issues. In my case, I only have two controllers hosted. Is it possible to ping a network gateway? That way the controller know that it is the one which failed and can disable the backend. > The best solution is to use the same interface for group communication and client/database communications. If you use a dedicated network for group communications and this network fails, you will end up with a network partition and this is very bad. If all communications go through the same interface, when it goes down, all communications are down and the controller will not be able to serve stale data. > I've attached my config xml file which I'm using for the above failure test. It would be nice if the failed controller can join back automatically to the group or disable the backend by its own. > > Thanks, > Seby. > ---------------------------------------------------------------------------------------------------------------- > Start: sequencer.xml file from hostA. The only diff in hostB is the bind_addr. > ---------------------------------------------------------------------------------------------------------------- > <config> > <UDP bind_addr="A" > mcast_port="45566" > mcast_addr="228.8.8.9" > tos="16" > ucast_recv_buf_size="20000000" > ucast_send_buf_size="640000" > mcast_recv_buf_size="25000000" > mcast_send_buf_size="640000" > loopback="false" > discard_incompatible_packets="true" > max_bundle_size="64000" > max_bundle_timeout="30" > use_incoming_packet_handler="true" > use_outgoing_packet_handler="false" > ip_ttl="2" > down_thread="false" up_thread="false" > enable_bundling="true"/> > <PING timeout="2000" > down_thread="false" up_thread="false" num_initial_members="3"/> > <MERGE2 max_interval="10000" > down_thread="false" up_thread="false" min_interval="5000"/> > <FD_SOCK down_thread="false" up_thread="false"/> > <FD timeout="2500" max_tries="5" down_thread="false" up_thread="false" shun="true"/> > <VERIFY_SUSPECT timeout="1500" down_thread="false"/> > <pbcast.NAKACK max_xmit_size="60000" > use_mcast_xmit="false" gc_lag="0" > retransmit_timeout="100,200,300,600,1200,2400,4800" > down_thread="false" up_thread="false" > discard_delivered_msgs="true"/> > <UNICAST timeout="300,600,1200,2400,3600" > down_thread="false" up_thread="false"/> > <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" > down_thread="false" up_thread="false" > max_bytes="400000"/> > <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" /> > <pbcast.GMS print_local_addr="true" join_timeout="3000" > down_thread="false" up_thread="false" > join_retry_timeout="2000" shun="true" handle_concurrent_startup="true" /> > <SEQUENCER down_thread="false" up_thread="false" /> > <FC max_credits="2000000" down_thread="false" up_thread="false" > min_threshold="0.10"/> > <pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/> > </config> > ---------------------------------------------------------------------------------------------------------------- > End: sequencer.xml > ---------------------------------------------------------------------------------------------------------------- > You don't need STATE_TRANSFER as Sequoia has its own state transfer protocol when a new member joins a group. Which version of JGroups are you using? Could you send me the log with JGroups messages that you see on each controller by activating them in log4j.properties. I would need the initial sequence when you start the cluster and the messages you see when the failure is detected and when the failed controller joins back. There might be a problem with the timeout settings of the different component of the stack. Keep me posted with your findings Emmanuel > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Tuesday, March 16, 2010 9:21 AM > To: Sequoia general mailing list > Cc: seq...@li... > Subject: Re: [Sequoia] Failure detection > > Hi Francis, > > When a group communication network failure happens, if no write was > pending at the time the failure was detected, the recovery is going to > be automatic. If a write was pending during the failure, there is no way > to know if the other controller really performed that write properly and > it is considered as failed. You then have to start the controller > recovery sequence (you can automate the script). The procedure is > described in section '8.1 Recover from a controller node failure' of the > Sequoia 2.10 management guide (pdf can be found in the doc directory). > > Hope this helps > Emmanuel > > >> Thank you Emmanuel! I've enabled the FD, FD_SOCK & VERIFY_SUSPECT in sequencer.xml and I could see the insert statements are now working. >> >> I do have another question. After the interface came back up, I see that the backend re-joins the group but, it never replays the insert statements occurred when it was down. Is that supposed to do automatically? Is there a way to make it automated. >> >> Thanks, >> Seby. >> >> -----Original Message----- >> From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet >> Sent: Saturday, March 13, 2010 12:51 PM >> To: Sequoia general mailing list >> Subject: Re: [Sequoia] Failure detection >> >> Hi Seby, >> >> >>> I setup sequoia in my lab having two controllers on two Solaris hosts. Each controller has one postgres backed attached. This dbs are in these Solaris servers itself. The controllers use group communication (jgroup) to sync updates/writes. >>> >>> For a failure test, I shutdown the interface on one of the host, but the other controller/host never figured this and my INSERT statement started failing. There were no errors I could see in the controller log. As soon I open the interface, I can see the request are being played and the data getting inserted to the db. >>> >>> Could you please let me know how the jgroup detects the network failures? >>> >>> >> This depends on your JGroups configuration. >> If you are using a TCP based failure detector, the detection will depend >> on your operating system TCP settings. Otherwise you should be able to >> setup the timeout in your gossip server or udp-based failure detector. >> >> Hope this helps >> Emmanuel >> >> >> > > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2010-03-16 13:48:09
|
Hi Francis, When a group communication network failure happens, if no write was pending at the time the failure was detected, the recovery is going to be automatic. If a write was pending during the failure, there is no way to know if the other controller really performed that write properly and it is considered as failed. You then have to start the controller recovery sequence (you can automate the script). The procedure is described in section '8.1 Recover from a controller node failure' of the Sequoia 2.10 management guide (pdf can be found in the doc directory). Hope this helps Emmanuel > Thank you Emmanuel! I've enabled the FD, FD_SOCK & VERIFY_SUSPECT in sequencer.xml and I could see the insert statements are now working. > > I do have another question. After the interface came back up, I see that the backend re-joins the group but, it never replays the insert statements occurred when it was down. Is that supposed to do automatically? Is there a way to make it automated. > > Thanks, > Seby. > > -----Original Message----- > From: seq...@li... [mailto:seq...@li...] On Behalf Of Emmanuel Cecchet > Sent: Saturday, March 13, 2010 12:51 PM > To: Sequoia general mailing list > Subject: Re: [Sequoia] Failure detection > > Hi Seby, > >> I setup sequoia in my lab having two controllers on two Solaris hosts. Each controller has one postgres backed attached. This dbs are in these Solaris servers itself. The controllers use group communication (jgroup) to sync updates/writes. >> >> For a failure test, I shutdown the interface on one of the host, but the other controller/host never figured this and my INSERT statement started failing. There were no errors I could see in the controller log. As soon I open the interface, I can see the request are being played and the data getting inserted to the db. >> >> Could you please let me know how the jgroup detects the network failures? >> > This depends on your JGroups configuration. > If you are using a TCP based failure detector, the detection will depend > on your operating system TCP settings. Otherwise you should be able to > setup the timeout in your gossip server or udp-based failure detector. > > Hope this helps > Emmanuel > > -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: BESSON-DEBLON,
Pierre \(S. H. TECH\) <PIE...@ai...> - 2009-12-04 16:32:22
|
Sorry for previous mail .... Hi, We have a problem with our sequoia : we have 2 controllers, the JDBC URL looks like that jdbc jdbc:sequoia://cont1,cont2/db. If we have cont1 down and cont2 with a deactivated backend, the requests fail even when cont2 backend is reactivated. Digging in the source code, the following code seems suspicious : ControllerPingSender.run() : .... for (Iterator it = controllers.getControllerIterator(); it.hasNext();) { ControllerInfo ctrl = (ControllerInfo) it.next(); sendPingTo(ctrl); } When the first controller is unreachable, the sendPing will throw an exception and the sendPing will not be sent to others. What will be the consequences ? Could it explain our problem ? Pierre Besson-Deblon The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. |
From: BESSON-DEBLON,
Pierre \(S. H. TECH\) <PIE...@ai...> - 2009-12-04 15:45:03
|
Hi, We have a problem with our sequoia : we have 2 controllers, the JDBC URL looks like that jdbc jdbc:sequoia://cont1,cont2/db. If we have cont1 down and cont2 with a deactivated backend, the requests fail even when cont2 backend is reactivated. Digging in the source code, the following code seems suspicious : ControllerPingSender.run() : : when 1 of the controller is down and the other have a backend disabled -----Message d'origine----- De : Emmanuel Cecchet [mailto:ma...@fr...] Envoyé : 18 November 2009 18:46 À : seq...@li... Cc : Sequoia general mailing list Objet : Re: [Sequoiadb-discuss] [Sequoia] about sequoia procedure call Hi, The sequoia mailing list has moved to seq...@li... Hi everyone, presently I encounter a problem about how to call procedures through sequoia virtual database console. Suppose a backend has a procedure in the form 'proc(IN id integer not null,IN name char(32) not null, IN score float with null)'. And I tried executing the procedure like this: {call proc(101,'student',80.0)} But such statement will raise exceptions from backend database which says errors like "invalid procedure call syntax". So I debugged the source code only to find the exceptions occurs from AbstractLoadBalancer.java, in function AbstractLoadBalancer::setupCallableStatement(), statement "cs = c.prepareCall(backend.transformQuery(proc)); ". If I executed like this: {call proc(?,?,?)} The above exception will disappear but no parameters in the procedure was assigned any value. So is this a bug in source code ? Or if not, how can I call the procedure correctly? If you use a CallableStatement, you are suppose to call a stored procedure this way: CallableStatement cs = connection.prepareCall({call proc(?,?,?)}); cs.setInt(1, 101); cs.setString(2, "student"); cs.setFloat(3, 80.0); cs.executeQuery() or cs.executeUpdate() depending on the result returned. Check for CallableStatement examples in the JDBC documentation. Thanks for your interest in Sequoia. Emmanuel -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. |
From: Emmanuel C. <ma...@fr...> - 2009-11-18 18:12:33
|
Hi, The sequoia mailing list has moved to seq...@li... > > Hi everyone, presently I encounter a problem about how to call > procedures through sequoia virtual database > > console. Suppose a backend has a procedure in the form 'proc(IN id > integer not null,IN name char(32) not null, > IN score float with null)'. And I tried executing the procedure like this: > {call proc(101,'student',80.0)} > But such statement will raise exceptions from backend database which > says errors like "invalid procedure call > syntax". So I debugged the source code only to find the exceptions > occurs from AbstractLoadBalancer.java, in function > AbstractLoadBalancer::setupCallableStatement(), statement > "cs = c.prepareCall(backend.transformQuery(proc)); ". > If I executed like this: > {call proc(?,?,?)} > The above exception will disappear but no parameters in the procedure > was assigned any value. > So is this a bug in source code ? Or if not, how can I call the > procedure correctly? > If you use a CallableStatement, you are suppose to call a stored procedure this way: CallableStatement cs = connection.prepareCall({call proc(?,?,?)}); cs.setInt(1, 101); cs.setString(2, "student"); cs.setFloat(3, 80.0); cs.executeQuery() or cs.executeUpdate() depending on the result returned. Check for CallableStatement examples in the JDBC documentation. Thanks for your interest in Sequoia. Emmanuel -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Julio L. <jc...@ho...> - 2009-11-04 19:36:07
|
Hi Emmanuel This is my current connection Manager configuration, it seems to be working now. In the previous version of sequoia I had minPoolSize=20 Thanks <ConnectionManager vLogin="postgres" rLogin="postgres" rPassword=""> <VariablePoolConnectionManager initPoolSize="100" minPoolSize="0" maxPoolSize="0" idleTimeout="180" waitTimeout="0"/> </ConnectionManager> Date: Tue, 3 Nov 2009 17:00:43 -0500 From: ma...@fr... To: se...@li... CC: seq...@li... Subject: Re: [Sequoia] sequoia 2.10.10. Hi Julio, This looks like a bug. What is your connection manager configuration on your db1 backend? If the problem persists I suggest that you file a new bug in JIRA. Thanks for your feedback Emmanuel Hi all I know the list has been moved, but I haven't get any reply back from this in that list.(sorry Emmanuel to bother you with this) I just update sequoia from 2.10.0 to 2.10.10 We are running a volume test with 1000 clients sending insert transactions to the DB We have 2 postgresql backends(8.3.5) After three hours we got these error messages and one backend was disabled This did not happen with the previous version of sequoia Any Ideas? Thanks in advance 2009-10-29 12:38:20,881 INFO controller.core.PingResponder Ping responder started 2009-10-29 15:52:29,090 FATAL backend.DatabaseBackend.db1 Unexpected error while executing task: StatementExecuteUpdateTask from transaction 1160899 (INSERT INTO table1 (f1, f2, f3, f4, f5, f6, f7, f8, f9,f10, f11, f12, f13, f14, f15, f16, f17, f18, f19, f20, f21, f22, f23, f24, f25,f26) VALUES(?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?)/*RQT*//<!%L|5364374|!%><!%I|2554|!%><!%T|2009-10-29 15:52:29.048|!%><!%S||!%><!%I|2600|!%><!%I|1|!%><!%N|4|!%><!%D|4.0|!%><!%1|0 .0|!%><!%I|0|!%><!%I|0|!%><!%I|2600|!%><!%S|awg|!%><!%S|perf__150028|!%><!%D|0.0|!%><!%I|1000|!%><!%N|-5|!%><!%I|1|!%><!%D|1.0|!%><!%I|1|!%><! %S||!%><!%I|1000|!%><!%L|5364374|!%><!%D|0.0|!%><!%N|4|!%><!%L|5364374|!%>) (0) java.lang.NullPointerException at java.util.LinkedList.remove(LinkedList.java:647) at java.util.LinkedList.removeLast(LinkedList.java:144) at org.continuent.sequoia.controller.connection.VariablePoolConnectionManager.getConnection(VariablePoolConnectionManager.java:468) at org.continuent.sequoia.controller.connection.AbstractConnectionManager.getRenewedConnectionInAutoCommit(AbstractConnectionManager.j ava:427) at org.continuent.sequoia.controller.connection.AbstractConnectionManager.getConnectionForTransaction(AbstractConnectionManager.java:4 59) at org.continuent.sequoia.controller.loadbalancer.AbstractLoadBalancer.getConnectionAndBeginTransaction(AbstractLoadBalancer.java:1793 ) at org.continuent.sequoia.controller.backend.DatabaseBackend.getConnectionForTransactionAndLazyBeginIfNeeded(DatabaseBackend.java:849) at org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeInTransaction(StatementExecuteUpdateTask.jav a:280) at org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeTask(StatementExecuteUpdateTask.java:118) at org.continuent.sequoia.controller.loadbalancer.tasks.AbstractTask.execute(AbstractTask.java:141) at org.continuent.sequoia.controller.loadbalancer.BackendWorkerThread.run(BackendWorkerThread.java:197) 2009-10-29 15:52:29,105 ERROR controller.loadbalancer.RAIDb1 Request SELECT nextval('table1_id_seq')/... failed on backend db1 (null) Thanks _______________________________________________ Sequoia mailing list Se...@li... http://forge.continuent.org/mailman/listinfo/sequoia -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2009-11-03 22:00:58
|
Hi Julio, This looks like a bug. What is your connection manager configuration on your db1 backend? If the problem persists I suggest that you file a new bug in JIRA. Thanks for your feedback Emmanuel > Hi all > I know the list has been moved, but I haven't get any reply back from > this in that list.(sorry Emmanuel to bother you with this) > > I just update sequoia from 2.10.0 to 2.10.10 > > We are running a volume test with 1000 clients sending insert > transactions to the DB > We have 2 postgresql backends(8.3.5) <javascript:;> > > After three hours we got these error messages and one backend was disabled > > This did not happen with the previous version of sequoia > > Any Ideas? > > Thanks in advance > > > 2009-10-29 12:38:20,881 INFO controller.core.PingResponder Ping > responder started > 2009-10-29 15:52:29,090 FATAL backend.DatabaseBackend.db1 Unexpected > error while executing task: StatementExecuteUpdateTask from > transaction 1160899 (INSERT INTO table1 (f1, f2, f3, f4, f5, f6, f7, > f8, f9,f10, f11, f12, f13, f14, f15, f16, f17, f18, f19, f20, f21, > f22, f23, f24, f25,f26) VALUES(?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, > ?,?,?,?,?, ?)/*RQT*//<!%L|5364374|!%><!%I|2554|!%><!%T|2009-10-29 > 15:52:29.048|!%><!%S||!%><!%I|2600|!%><!%I|1|!%><!%N|4|!%><!%D|4.0|!%><!%1|0 > .0|!%><!%I|0|!%><!%I|0|!%><!%I|2600|!%><!%S|awg|!%><!%S|perf__150028|!%><!%D|0.0|!%><!%I|1000|!%><!%N|-5|!%><!%I|1|!%><!%D|1.0|!%><!%I|1|!%><! > %S||!%><!%I|1000|!%><!%L|5364374|!%><!%D|0.0|!%><!%N|4|!%><!%L|5364374|!%>) > (0) > java.lang.NullPointerException > at java.util.LinkedList.remove(LinkedList.java:647) > at java.util.LinkedList.removeLast(LinkedList.java:144) > at > org.continuent.sequoia.controller.connection.VariablePoolConnectionManager.getConnection(VariablePoolConnectionManager.java:468) > at > org.continuent.sequoia.controller.connection.AbstractConnectionManager.getRenewedConnectionInAutoCommit(AbstractConnectionManager.j > ava:427) > at > org.continuent.sequoia.controller.connection.AbstractConnectionManager.getConnectionForTransaction(AbstractConnectionManager.java:4 > 59) > at > org.continuent.sequoia.controller.loadbalancer.AbstractLoadBalancer.getConnectionAndBeginTransaction(AbstractLoadBalancer.java:1793 > ) > at > org.continuent.sequoia.controller.backend.DatabaseBackend.getConnectionForTransactionAndLazyBeginIfNeeded(DatabaseBackend.java:849) > at > org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeInTransaction(StatementExecuteUpdateTask.jav > a:280) > at > org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeTask(StatementExecuteUpdateTask.java:118) > at > org.continuent.sequoia.controller.loadbalancer.tasks.AbstractTask.execute(AbstractTask.java:141) > at > org.continuent.sequoia.controller.loadbalancer.BackendWorkerThread.run(BackendWorkerThread.java:197) > 2009-10-29 15:52:29,105 ERROR controller.loadbalancer.RAIDb1 Request > SELECT nextval('table1_id_seq')/... failed on backend db1 (null) > > > > Thanks > ------------------------------------------------------------------------ > > _______________________________________________ > Sequoia mailing list > Se...@li... > http://forge.continuent.org/mailman/listinfo/sequoia -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Julio L. <jc...@ho...> - 2009-10-30 15:11:11
|
From: jc...@ho... To: seq...@li... Subject: sequoia-2.10.10 Date: Fri, 30 Oct 2009 15:03:16 +0000 Hi all I just update sequoia from 2.10.0 to 2.10.10 We are running a volume test with 1000 clients sending insert transactions to the DB We have 2 postgresql backends After three hours we got these error messages and one backend was disabled This did not happen with the previous version of sequoia Any Ideas? Thanks in advance 2009-10-29 12:38:20,881 INFO controller.core.PingResponder Ping responder started 2009-10-29 15:52:29,090 FATAL backend.DatabaseBackend.db1 Unexpected error while executing task: StatementExecuteUpdateTask from transaction 1160899 (INSERT INTO table1 (f1, f2, f3, f4, f5, f6, f7, f8, f9,f10, f11, f12, f13, f14, f15, f16, f17, f18, f19, f20, f21, f22, f23, f24, f25,f26) VALUES(?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?,?,?,?,?, ?)/*RQT*//<!%L|5364374|!%><!%I|2554|!%><!%T|2009-10-29 15:52:29.048|!%><!%S||!%><!%I|2600|!%><!%I|1|!%><!%N|4|!%><!%D|4.0|!%><!%1|0 .0|!%><!%I|0|!%><!%I|0|!%><!%I|2600|!%><!%S|awg|!%><!%S|perf__150028|!%><!%D|0.0|!%><!%I|1000|!%><!%N|-5|!%><!%I|1|!%><!%D|1.0|!%><!%I|1|!%><! %S||!%><!%I|1000|!%><!%L|5364374|!%><!%D|0.0|!%><!%N|4|!%><!%L|5364374|!%>) (0) java.lang.NullPointerException at java.util.LinkedList.remove(LinkedList.java:647) at java.util.LinkedList.removeLast(LinkedList.java:144) at org.continuent.sequoia.controller.connection.VariablePoolConnectionManager.getConnection(VariablePoolConnectionManager.java:468) at org.continuent.sequoia.controller.connection.AbstractConnectionManager.getRenewedConnectionInAutoCommit(AbstractConnectionManager.j ava:427) at org.continuent.sequoia.controller.connection.AbstractConnectionManager.getConnectionForTransaction(AbstractConnectionManager.java:4 59) at org.continuent.sequoia.controller.loadbalancer.AbstractLoadBalancer.getConnectionAndBeginTransaction(AbstractLoadBalancer.java:1793 ) at org.continuent.sequoia.controller.backend.DatabaseBackend.getConnectionForTransactionAndLazyBeginIfNeeded(DatabaseBackend.java:849) at org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeInTransaction(StatementExecuteUpdateTask.jav a:280) at org.continuent.sequoia.controller.loadbalancer.tasks.StatementExecuteUpdateTask.executeTask(StatementExecuteUpdateTask.java:118) at org.continuent.sequoia.controller.loadbalancer.tasks.AbstractTask.execute(AbstractTask.java:141) at org.continuent.sequoia.controller.loadbalancer.BackendWorkerThread.run(BackendWorkerThread.java:197) 2009-10-29 15:52:29,105 ERROR controller.loadbalancer.RAIDb1 Request SELECT nextval('table1_id_seq')/... failed on backend db1 (null) Thanks |
From: Emmanuel C. <ma...@fr...> - 2009-10-27 17:01:53
|
Hi Julio, Note that the Sequoia mailing list is now at seq...@li.... > We run sequoia 2.10, ,backend is postgresql 8.3.5 > Os Suse Linux 10.2 I guess that you are using Sequoia 2.10.10 otherwise I would suggest that you upgrade to that version first. > This statement is failing in sequoia > > delete from c1 where promotionid=? and itemfactoryname=? and > (promotionid, itemfactoryname, item, datemodified) NOT in (select > promotionid, itemfactoryname, item, datemodified from view_c1 p1 where > p1.datemodified in (select max(p2.datemodified) from view_c1p2 where > p2.promotionid = p1.promotionid and p2.itemfactoryname = > p1.itemfactoryname and p2.item = p1.item and p2.restartdate1 = > p1.restartdate1))/<!%I|1001|!%><!%S|stub|!%> > > > These are the errors > > 2009-10-27 12:13:09,829 WARN controller.RequestManager.db1 Failed to > execute request delete from c1 where p... because of > (org.continuent.sequoia.controller.requests.StoredProcedure) > java.lang.ClassCastException: > org.continuent.sequoia.controller.requests.StoredProcedure > at > org.continuent.sequoia.controller.loadbalancer.raidb1.RAIDb1.callStoredProcedure(RAIDb1.java:851) > at > org.continuent.sequoia.controller.loadbalancer.raidb1.RAIDb1.statementExecute(RAIDb1.java:281) > at > org.continuent.sequoia.controller.requestmanager.RequestManager.loadBalanceStatementExecute(RequestManager.java:974) > at > org.continuent.sequoia.controller.requestmanager.RequestManager.statementExecute(RequestManager.java:769) > at > org.continuent.sequoia.controller.virtualdatabase.VirtualDatabase.statementExecute(VirtualDatabase.java:735) > at > org.continuent.sequoia.controller.virtualdatabase.VirtualDatabaseWorkerThread.statementExecute(VirtualDatabaseWorkerThread.java:2312) > at > org.continuent.sequoia.controller.virtualdatabase.VirtualDatabaseWorkerThread.run(VirtualDatabaseWorkerThread.java:445) > 2009-10-27 12:13:09,834 WARN > virtualdatabase.VirtualDatabaseWorkerThread.abrazo Error during > command execution (Cannot abort transaction 0 since current worker > thread is assigned to transaction 0) > 2009-10-27 12:13:09,852 WARN > virtualdatabase.VirtualDatabaseWorkerThread.abrazo Transaction 0 was > aborted by database > > > Any ideas ? There is a problem with the parser that somehow confuses your delete query with a stored procedure call. An easy fix is to use statement.executeUpdate() instead of statement.execute(). It is a relatively bad practice to use statement.execute() and it will always be slower for Sequoia since it has to do extra processing to try to figure out what you are executing. There was a bug in earlier versions of Sequoia that triggered that problem but it should be fixed in 2.10.10. Keep us posted with your findings. Emmanuel -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |
From: Emmanuel C. <ma...@fr...> - 2009-10-19 18:00:14
|
Hi Lahiru, The Sequoia mailing list has moved to seq...@li.... Tungsten and Sequoia have different purpose. Tungsten offers asynchronous replication (like MySQL replication) and Sequoia offers synchronous replication (all nodes are fully synchronized at all times). Depending on your consistency needs, performance and reliability requirements you might choose one or the other. A good place to start with Sequoia is the pdf documentation that is shipped in the distribution. Hope this helps, Emmanuel > > I'm looking forward to use Sequoia to use as a third party clustering > application to cluster my database (MySQL)which runs in few nodes in > Amazon EC2 which connects to another application in EC2. > > Can someone provide me some more information on where should I start > or do you prefer me to use Tungsten rather using Sequoia. > > Regards > Lahiru > > -- > Lahiru Gunathilake > Software Engineer - WSO2 Inc. > ------------------------------------------------------------------------ > > _______________________________________________ > Sequoia mailing list > Se...@li... > http://forge.continuent.org/mailman/listinfo/sequoia -- Emmanuel Cecchet FTO @ Frog Thinker Open Source Development & Consulting -- Web: http://www.frogthinker.org email: ma...@fr... Skype: emmanuel_cecchet |