[jira] Resolved: (CONNECTORS-112) It is possible to create a new connection of the same name as an existing one
[ https://issues.apache.org/jira/browse/CONNECTORS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved CONNECTORS-112. Resolution: Fixed Fixed. r1005096. Note that a minor API documentation change is also going to be required. > It is possible to create a new connection of the same name as an existing one > - > > Key: CONNECTORS-112 > URL: https://issues.apache.org/jira/browse/CONNECTORS-112 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Reporter: Karl Wright >Assignee: Karl Wright > > If you try to create a new connection that has the same name as an existing > connection, the connection saves fine, but completely replaces the original > connection. This is bad for many reasons, but one of them is that the type > of the connection might change out from under a job, causing carnage of a > major sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CONNECTORS-112) It is possible to create a new connection of the same name as an existing one
[ https://issues.apache.org/jira/browse/CONNECTORS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated CONNECTORS-112: --- Fix Version/s: LCF Release 0.5 > It is possible to create a new connection of the same name as an existing one > - > > Key: CONNECTORS-112 > URL: https://issues.apache.org/jira/browse/CONNECTORS-112 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: LCF Release 0.5 > > > If you try to create a new connection that has the same name as an existing > connection, the connection saves fine, but completely replaces the original > connection. This is bad for many reasons, but one of them is that the type > of the connection might change out from under a job, causing carnage of a > major sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-112) It is possible to create a new connection of the same name as an existing one
[ https://issues.apache.org/jira/browse/CONNECTORS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright reassigned CONNECTORS-112: -- Assignee: Karl Wright > It is possible to create a new connection of the same name as an existing one > - > > Key: CONNECTORS-112 > URL: https://issues.apache.org/jira/browse/CONNECTORS-112 > Project: ManifoldCF > Issue Type: Bug > Components: Framework core >Reporter: Karl Wright >Assignee: Karl Wright > Fix For: LCF Release 0.5 > > > If you try to create a new connection that has the same name as an existing > connection, the connection saves fine, but completely replaces the original > connection. This is bad for many reasons, but one of them is that the type > of the connection might change out from under a job, causing carnage of a > major sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONNECTORS-111) Encountering deadlock using quick-start & derby
[
https://issues.apache.org/jira/browse/CONNECTORS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-111.
Resolution: Fixed
Fix Version/s: LCF Release 0.5
Retry seems to have fixed things.
> Encountering deadlock using quick-start & derby
> ---
>
> Key: CONNECTORS-111
> URL: https://issues.apache.org/jira/browse/CONNECTORS-111
> Project: ManifoldCF
> Issue Type: Bug
> Components: Examples
> Environment: Windows XP Professional SR3, Intel Core 2, 2 GB Ram
>Reporter: Farzad
>Assignee: Karl Wright
> Fix For: LCF Release 0.5
>
>
> Ran into problem with quick-start and thought I might have better luck if I
> manually setup the system. Maybe you can shed a light on the quick-start
> problem. Here is what happened, after running start.jar, I went to the
> crawler UI, configured a null output and a file system repo connector.
> Created a job pointing to a file share \\host\share and started the job.
> After a few seconds I ran into the error message below in the job status
> panel. It said 60 docs found, 9 active, and 52 processed. Any ideas as to why
> I'm seeing this?
> Error: A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is: Lock : ROW, INGESTSTATUS, (1,57) Waiting XID :
> Unknown macro: {6293, X}
> , APP, DELETE FROM ingeststatus WHERE urihash=? AND dockey!=? AND
> connectionname=? Granted XID :
> Unknown macro: {6305, X}
> Lock : ROW, INGESTSTATUS, (1,55) Waiting XID :
> , APP, INSERT INTO ingeststatus
> (id,changecount,dockey,lastversion,firstingest,connectionname,authorityname,urihash,lastoutputversion,lastingest,docuri)
> VALUES (?,?,?,?,?,?,?,?,?,?,?) Granted XID :
> . The selected victim is XID : 6293.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CONNECTORS-111) Encountering deadlock using quick-start & derby
[
https://issues.apache.org/jira/browse/CONNECTORS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reassigned CONNECTORS-111:
--
Assignee: Karl Wright
> Encountering deadlock using quick-start & derby
> ---
>
> Key: CONNECTORS-111
> URL: https://issues.apache.org/jira/browse/CONNECTORS-111
> Project: ManifoldCF
> Issue Type: Bug
> Components: Examples
> Environment: Windows XP Professional SR3, Intel Core 2, 2 GB Ram
>Reporter: Farzad
>Assignee: Karl Wright
> Fix For: LCF Release 0.5
>
>
> Ran into problem with quick-start and thought I might have better luck if I
> manually setup the system. Maybe you can shed a light on the quick-start
> problem. Here is what happened, after running start.jar, I went to the
> crawler UI, configured a null output and a file system repo connector.
> Created a job pointing to a file share \\host\share and started the job.
> After a few seconds I ran into the error message below in the job status
> panel. It said 60 docs found, 9 active, and 52 processed. Any ideas as to why
> I'm seeing this?
> Error: A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is: Lock : ROW, INGESTSTATUS, (1,57) Waiting XID :
> Unknown macro: {6293, X}
> , APP, DELETE FROM ingeststatus WHERE urihash=? AND dockey!=? AND
> connectionname=? Granted XID :
> Unknown macro: {6305, X}
> Lock : ROW, INGESTSTATUS, (1,55) Waiting XID :
> , APP, INSERT INTO ingeststatus
> (id,changecount,dockey,lastversion,firstingest,connectionname,authorityname,urihash,lastoutputversion,lastingest,docuri)
> VALUES (?,?,?,?,?,?,?,?,?,?,?) Granted XID :
> . The selected victim is XID : 6293.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-111) Encountering deadlock using quick-start & derby
[
https://issues.apache.org/jira/browse/CONNECTORS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918507#action_12918507
]
Farzad commented on CONNECTORS-111:
---
I tried your fix this morning and I was able to run the job successfully the
first time after setup. Seems to be resolved. I ran a few other experiments
and they were fine too. Thanks!
> Encountering deadlock using quick-start & derby
> ---
>
> Key: CONNECTORS-111
> URL: https://issues.apache.org/jira/browse/CONNECTORS-111
> Project: ManifoldCF
> Issue Type: Bug
> Components: Examples
> Environment: Windows XP Professional SR3, Intel Core 2, 2 GB Ram
>Reporter: Farzad
>
> Ran into problem with quick-start and thought I might have better luck if I
> manually setup the system. Maybe you can shed a light on the quick-start
> problem. Here is what happened, after running start.jar, I went to the
> crawler UI, configured a null output and a file system repo connector.
> Created a job pointing to a file share \\host\share and started the job.
> After a few seconds I ran into the error message below in the job status
> panel. It said 60 docs found, 9 active, and 52 processed. Any ideas as to why
> I'm seeing this?
> Error: A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is: Lock : ROW, INGESTSTATUS, (1,57) Waiting XID :
> Unknown macro: {6293, X}
> , APP, DELETE FROM ingeststatus WHERE urihash=? AND dockey!=? AND
> connectionname=? Granted XID :
> Unknown macro: {6305, X}
> Lock : ROW, INGESTSTATUS, (1,55) Waiting XID :
> , APP, INSERT INTO ingeststatus
> (id,changecount,dockey,lastversion,firstingest,connectionname,authorityname,urihash,lastoutputversion,lastingest,docuri)
> VALUES (?,?,?,?,?,?,?,?,?,?,?) Granted XID :
> . The selected victim is XID : 6293.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONNECTORS-112) It is possible to create a new connection of the same name as an existing one
It is possible to create a new connection of the same name as an existing one - Key: CONNECTORS-112 URL: https://issues.apache.org/jira/browse/CONNECTORS-112 Project: ManifoldCF Issue Type: Bug Components: Framework core Reporter: Karl Wright If you try to create a new connection that has the same name as an existing connection, the connection saves fine, but completely replaces the original connection. This is bad for many reasons, but one of them is that the type of the connection might change out from under a job, causing carnage of a major sort. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONNECTORS-111) Encountering deadlock using quick-start & derby
[
https://issues.apache.org/jira/browse/CONNECTORS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918460#action_12918460
]
Karl Wright commented on CONNECTORS-111:
Looking at the complaint again:
Error: A lock could not be obtained due to a deadlock, cycle of locks and
waiters is:
Lock : ROW, INGESTSTATUS, (1,57) Waiting XID :6293, APP, DELETE FROM
ingeststatus WHERE urihash=? AND dockey\!=? AND connectionname=? Granted XID
:6305
Lock : ROW, INGESTSTATUS, (1,55) Waiting XID :6305, APP, INSERT INTO
ingeststatus
(id,changecount,dockey,lastversion,firstingest,connectionname,authorityname,urihash,lastoutputversion,lastingest,docuri)
VALUES (?,?,?,?,?,?,?,?,?,?,?) Granted XID :6293
The selected victim is XID : 6293.
... it seems more like this has nothing to do with transactions, and more to do
with an internal lock-ordering problem in Derby itself. So, each database
modification has a potential of throwing one of these exceptions.
I tried to fix that issue by retrying the operation should I be outside of a
transaction. r1004915.
> Encountering deadlock using quick-start & derby
> ---
>
> Key: CONNECTORS-111
> URL: https://issues.apache.org/jira/browse/CONNECTORS-111
> Project: ManifoldCF
> Issue Type: Bug
> Components: Examples
> Environment: Windows XP Professional SR3, Intel Core 2, 2 GB Ram
>Reporter: Farzad
>
> Ran into problem with quick-start and thought I might have better luck if I
> manually setup the system. Maybe you can shed a light on the quick-start
> problem. Here is what happened, after running start.jar, I went to the
> crawler UI, configured a null output and a file system repo connector.
> Created a job pointing to a file share \\host\share and started the job.
> After a few seconds I ran into the error message below in the job status
> panel. It said 60 docs found, 9 active, and 52 processed. Any ideas as to why
> I'm seeing this?
> Error: A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is: Lock : ROW, INGESTSTATUS, (1,57) Waiting XID :
> Unknown macro: {6293, X}
> , APP, DELETE FROM ingeststatus WHERE urihash=? AND dockey!=? AND
> connectionname=? Granted XID :
> Unknown macro: {6305, X}
> Lock : ROW, INGESTSTATUS, (1,55) Waiting XID :
> , APP, INSERT INTO ingeststatus
> (id,changecount,dockey,lastversion,firstingest,connectionname,authorityname,urihash,lastoutputversion,lastingest,docuri)
> VALUES (?,?,?,?,?,?,?,?,?,?,?) Granted XID :
> . The selected victim is XID : 6293.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
