From: Graeme Wallace
Date: November 26 2012 5:49pm
Subject: Re: Problem with multithreading and ClusterJ
List-Archive: http://lists.mysql.com/cluster/8439
Message-Id:
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=047d7b6226b0e11a8c04cf698c0f
--047d7b6226b0e11a8c04cf698c0f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Ok tried reducing transaction size down to 4K rows. Works for 2 threads,
but its slower than doing one thread with larger transactions.
If i up the threads to 4, i get the same error as before
Nov 26, 2012 12:44:24 PM com.mysql.clusterj.tie.Utility throwError
SEVERE: Error in NdbJTie: returnCode -1, code 266, mysqlCode 146, status 1,
classification 10, message Time-out in NDB, probably caused by deadlock .
Am I just going about this wrong ? I assumed that as i have a cluster of 10
datanodes i would be able to have lots of threads and therefore lots of
writes going on at the same time. (Caveat - i read the marketing material
for 1 billion reads and writes a second :) )
regards,
Graeme
On Mon, Nov 26, 2012 at 8:44 AM, Magnus Bl=E5udd =
wrote:
> On Mon 26 Nov 2012 04:33:57 PM CET, Graeme Wallace wrote:
>
>> I've tried playing around with transaction size, but the error still
>> remains even if I make the transaction small ie 32K rows AND i make all
>> the
>> primary keys unique - so that each transaction should have a unique set =
of
>> keys.
>>
>> G.
>>
>>
>> On Mon, Nov 26, 2012 at 8:30 AM, Magnus Bl=E5udd
>> **wrote:
>>
>> On Mon 26 Nov 2012 04:09:42 PM CET, Graeme Wallace wrote:
>>>
>>> I'm trying to make my app multi-threaded and running into
>>>> problems.
>>>>
>>>> I have a Session local to each thread that is attempting to write to t=
he
>>>> db. I'm batching up many savePersistent() calls in a transaction - but
>>>> when
>>>> the transaction commits I invariably end up with
>>>>
>>>> Nov 21, 2012 7:22:29 PM com.mysql.clusterj.tie.Utility throwError
>>>> SEVERE: Error in NdbJTie: returnCode -1, code 266, mysqlCode 146, stat=
us
>>>> 1,
>>>> classification 10, message Time-out in NDB, probably caused by deadloc=
k
>>>> .
>>>>
>>>> For reading the docs, it looks like there shouldn't be table locking
>>>> going
>>>> on - so i dont understand what resource is being held by one thread th=
at
>>>> stops the others from being able to write at the same time.
>>>>
>>>> Any clues would be most helpful,
>>>>
>>>> regards,
>>>>
>>>>
>>>> Graeme
>>>>
>>>>
>>>> Check out Matthew's reply in in this forum thread
>>> http://forums.mysql.com/read.****php?25,505712,505757
>>>
>>> >
>>>
>>> "Due to the distributed nature of NDBCLUSTER there is no automatic
>>> deadlock detection mechanism within the NDBCLUSTER engine. The only
>>> indication that the cluster gives that there is a *possible* deadlock i=
s
>>> the "Lock wait timeout exceeded". This error occurs when a given lock
>>> operation takes longer than TransactionDeadlockDetectionTi****meout
>>> (default 1200 ms.). If you have large transactions that lock many rows =
at
>>> once or if you have long running transactions these can prevent this or
>>> transactions from completing quickly. Try to avoid large or long runnin=
g
>>> transactions by breaking them into smaller chunks. The
>>> TransactionDeadlockDetectionTi****meout can also be reached when a node
>>> is
>>> overloaded but has not yet been ejected from the cluster for missing
>>> heartbeats longer than 4xHeartbeatIntervalDbDb (default 1500 ms. each).=
"
>>>
>>> / Magnus
>>>
>>>
>>
>>
>>
> Give it a try with even smaller transactions if possible. Normally better
> to use more threads with smaller transactions.
>
> / Magnus
>
--=20
Graeme Wallace
CTO
FareCompare.com
O: 972 588 1414
M: 214 681 9018
--047d7b6226b0e11a8c04cf698c0f--