ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
-
Key: CONNECTORS-453
URL: https://issues.apache.org/jira/browse/CONNECTORS-453
Project: ManifoldCF
[
https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reopened CONNECTORS-453:
Reopening for inclusion in 0.5.1
ManifoldCF running with Derby 10.8.1.1
)
ManifoldCF running with Derby 10.8.1.1 has problems pausing and aborting jobs
-
Key: CONNECTORS-453
URL: https://issues.apache.org/jira/browse/CONNECTORS-453
Project
[
https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-453.
Resolution: Fixed
ManifoldCF running with Derby 10.8.1.1 has problems pausing
victim is XID : 147028.
ManifoldCF running with Derby 10.8.1.1 has severe performance problems
--
Key: CONNECTORS-453
URL: https://issues.apache.org/jira/browse/CONNECTORS-453
: {157557, X} Lock : ROW, JOBS, (1,7) Waiting XID : {157557, S} ,
APP, INSERT INTO hopcount (deathmark,parentidhash,id,distance,jobid,linktype)
VALUES (?,?,?,?,?,?) . The selected victim is XID : 157800.
ManifoldCF running with Derby 10.8.1.1 has severe performance problems
ManifoldCF running with Derby 10.8.1.1 has severe performance problems
--
Key: CONNECTORS-453
URL: https://issues.apache.org/jira/browse/CONNECTORS-453
Project: ManifoldCF
Issue Type
[
https://issues.apache.org/jira/browse/CONNECTORS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-453.
Resolution: Fixed
ManifoldCF running with Derby 10.8.1.1 has severe performance
ManifoldCF running with Derby 10.8.1.1 has severe performance problems
--
Key: CONNECTORS-453
URL: https://issues.apache.org/jira/browse/CONNECTORS-453
Project: ManifoldCF
Version/s: ManifoldCF next
Max activity and Max bandwidth reports don't work properly under Derby or
HSQLDB
Key: CONNECTORS-110
URL: https://issues.apache.org/jira/browse/CONNECTORS
Version/s: ManifoldCF next
Implement ability to run ManifoldCF with Derby in multiprocess mode
---
Key: CONNECTORS-178
URL: https://issues.apache.org/jira/browse/CONNECTORS-178
Project
Derby deadlocks in a new way on the IngestStatus table, which isn't caught and
retried
--
Key: CONNECTORS-244
URL: https://issues.apache.org/jira/browse/CONNECTORS-244
[
https://issues.apache.org/jira/browse/CONNECTORS-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reassigned CONNECTORS-225:
--
Assignee: Karl Wright
When using Derby, ManifoldCF incremental indexer sometimes
been resolved, so I'm closing this ticket.
r1131056.
Derby seems too unstable in multithreaded situations to be a good database
for ManifoldCF, so try to add support for HSQLDB
I have not yet made HSQLDB the official Derby replacement, but it is currently
a better embedded option for many situations than Derby is.
Derby seems too unstable in multithreaded situations to be a good database
for ManifoldCF, so try to add support for HSQLDB
the temporary table route, but then PostgreSQL would be
unnecessarily crippled.
Max activity and Max bandwidth reports don't work properly under Derby
--
Key: CONNECTORS-110
URL: https
[
https://issues.apache.org/jira/browse/CONNECTORS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-110:
---
Summary: Max activity and Max bandwidth reports don't work properly under
Derby
. Unfortunately, performance is extremely
slow, even when the number of rows in the temporary table is only a few dozen.
Max activity and Max bandwidth reports don't work properly under Derby or
HSQLDB
the PostgreSQL-specific
parameters, and may be missing some of the Derby ones too
---
Key: CONNECTORS-175
URL: https
documentation property list does not include the PostgreSQL-specific
parameters, and may be missing some of the Derby ones too
---
Key: CONNECTORS-175
The site documentation property list does not include the PostgreSQL-specific
parameters, and may be missing some of the Derby ones too
---
Key
[
https://issues.apache.org/jira/browse/CONNECTORS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright updated CONNECTORS-110:
---
Summary: Max activity and Max bandwidth reports don't work properly under
Derby
Derby database driver needs to periodically update statistics
-
Key: CONNECTORS-170
URL: https://issues.apache.org/jira/browse/CONNECTORS-170
Project: ManifoldCF
Issue Type: Bug
[
https://issues.apache.org/jira/browse/CONNECTORS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reassigned CONNECTORS-170:
--
Assignee: Karl Wright
Derby database driver needs to periodically update
[
https://issues.apache.org/jira/browse/CONNECTORS-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-170.
Resolution: Fixed
Fix Version/s: ManifoldCF 0.2
r1082598.
Derby database
[
https://issues.apache.org/jira/browse/CONNECTORS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006583#comment-13006583
]
Karl Wright commented on CONNECTORS-166:
According to the Derby team, Derby
Crawl seizes up when running Derby
--
Key: CONNECTORS-166
URL: https://issues.apache.org/jira/browse/CONNECTORS-166
Project: ManifoldCF
Issue Type: Bug
Components: Framework crawler agent
Go to current version of Derby, to try and avoid internal deadlocks
---
Key: CONNECTORS-163
URL: https://issues.apache.org/jira/browse/CONNECTORS-163
Project: ManifoldCF
Issue
[
https://issues.apache.org/jira/browse/CONNECTORS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright resolved CONNECTORS-123.
Resolution: Fixed
It looks like this is a Derby bug, but it can be worked around
, when I try to use hsqldb for an actual crawl, in less than 10 seconds
I wind up with a java-level thread deadlock. I've posted the thread dump to
connectors-dev. All the locks seem to be deep inside hsqldb, FWIW, which leads
me to believe that perhaps hsqldb is even less stable than Derby
Derby seems too unstable in multithreaded situations to be a good database for
ManifoldCF, so try to add support for HSQLDB
---
Key: CONNECTORS-114
, 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
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?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wright reassigned CONNECTORS-111:
--
Assignee: Karl Wright
Encountering deadlock using quick-start derby
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
the first time after a clean
setup of ManifoldCF. Subsequent jobs including the same job ran successfully.
Encountering deadlock using quick-start derby
---
Key: CONNECTORS-111
URL: https://issues.apache.org/jira
in question is not apparently within a
database transaction, so it's puzzling to me how a deadlock could develop. The
possibilities are:
(1) Derby detects deadlocks in part by timeout. Perhaps the derby timeout time
is too short.
(2) It could be a plain old Derby bug.
(3) There could
AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1.primary_key, windowstart, etc
FROM
table AS t1
LEFT OUTER JOIN
) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1.primary_key, windowstart, etc
FROM
table AS t1
LEFT OUTER JOIN table AS t2 ON ( t1.bucket = t2.bucket AND
t2
, windowstart, etc
FROM
table AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1.primary_key, windowstart, etc
SELECT
bucket, primary_key, windowstart, etc
FROM
table AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1
bucket, primary_key, windowstart, etc
FROM
table AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1.primary_key
query can be
rewritten in the following ways:
1. Using subqueries
SELECT
bucket, primary_key, windowstart, etc
FROM
table AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't
=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure about that )
SELECT
t1.bucket, t1.primary_key, windowstart, etc
FROM
table AS t1
LEFT OUTER JOIN table AS t2 ON ( t1.bucket
in the following ways:
1. Using subqueries
SELECT
bucket, primary_key, windowstart, etc
FROM
table AS t1
WHERE
windowstart=( SELECT max(windowstart) FROM table AS t2 WHERE
bucket = t1.bucket )
2. Using joins instead of subqueries ( in case Derby doesn't support
subqueries - not sure
For what it's worth, defining a Derby function seems like the only way
to do it. These seem to call arbitrary java that can accept a query
as an argument and return a resultset as the result. But in order to
write such a thing I will need the ability to call Derby at a java
level, I think
The Derby table-result function syntax requires all output columns to
be declared as part of the function definition, and more importantly
it does not seem to allow calls into Derby itself to get results. So
this would not seem to be a viable option for that reason.
Back to square 1, I guess
changes to correct this problem locally, but
can't commit them yet because Derby's functions are limited in the current
release to not allow CLOB arguments. This issue is going to be addressed in
the next release of Derby, see DERBY-4066. The alternative is to build a trunk
version of Derby and use
to use the DERBY-4066 fix properly when
it becomes available. r998576.
Queue status report fails under Derby
-
Key: CONNECTORS-109
URL: https://issues.apache.org/jira/browse/CONNECTORS-109
Project: Apache
Max activity and Max bandwidth reports fail under Derby with a stack trace
--
Key: CONNECTORS-110
URL: https://issues.apache.org/jira/browse/CONNECTORS-110
Project: Apache
activity report, maximum bandwidth report, and
result code report as well.
Queue status report fails under Derby
-
Key: CONNECTORS-109
URL: https://issues.apache.org/jira/browse/CONNECTORS-109
Project: Apache
Olivier Bourgeat [olivier.bourg...@polyspot.com]
Sent: Wednesday, June 09, 2010 4:03 AM
To: connectors-dev@incubator.apache.org
Subject: RE: Derby/JUnit bad interaction - any ideas?
Debian Lenny have openjdk-6:
http://packages.debian.org/fr/source/lenny/openjdk-6
Olivier
Le mardi 08 juin 2010 à 22:37
On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote:
I've been trying to get some basic tests working under Junit. Unfortunately,
I've run into a Derby problem which prevents these tests from working.
What happens is this. Derby, when it creates a database, forces a number of directories
within
This actually did work, oddly enough. I wonder how Derby is undoing the
read-only attribute on those directories? But in any case, I'm revamping the
core setup/shutdown code again so that there's a decent hook in place to do the
derby shutdown.
Karl
-Original Message-
From: ext
I've been trying to get some basic tests working under Junit. Unfortunately,
I've run into a Derby problem which prevents these tests from working.
What happens is this. Derby, when it creates a database, forces a number of
directories within the database to read-only. Unfortunately, unless
On 6/8/10 6:35 AM, karl.wri...@nokia.com wrote:
I've been trying to get some basic tests working under Junit. Unfortunately,
I've run into a Derby problem which prevents these tests from working.
What happens is this. Derby, when it creates a database, forces a number of directories
within
(10/06/08 22:35), karl.wri...@nokia.com wrote:
I've been trying to get some basic tests working under Junit. Unfortunately,
I've run into a Derby problem which prevents these tests from working.
What happens is this. Derby, when it creates a database, forces a number of directories
within
, 2010 10:08 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Derby/JUnit bad interaction - any ideas?
(10/06/08 22:35), karl.wri...@nokia.com wrote:
I've been trying to get some basic tests working under Junit. Unfortunately,
I've run into a Derby problem which prevents these tests from
Yeah, I was pretty surprised too. But on windows it is likely that
File.makeReadOnly() (which is what Derby must be using) doesn't actually do
anything to directories, which would explain the discrepancy.
Karl
-Original Message-
From: ext Mark Miller [mailto:markrmil...@gmail.com
(10/06/08 23:14), karl.wri...@nokia.com wrote:
Yeah, I was pretty surprised too. But on windows it is likely that
File.makeReadOnly() (which is what Derby must be using) doesn't actually do
anything to directories, which would explain the discrepancy.
Karl
If so, luckily Ant hack can
.
Still, things are currently working, so I guess I'll leave them as they are,
for now.
Karl
-Original Message-
From: ext Koji Sekiguchi [mailto:k...@r.email.ne.jp]
Sent: Tuesday, June 08, 2010 10:30 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Derby/JUnit bad interaction
-dev@incubator.apache.org
Subject: Derby/JUnit bad interaction - any ideas?
I've been trying to get some basic tests working under Junit.
Unfortunately, I've run into a Derby problem which prevents these tests
from working.
What happens is this. Derby, when it creates a database, forces
The reason this occurs is because I am using Derby in embedded mode, and the
restriction appears to be a limitation of that mode of operation. However,
this mode is necessary to meet the testing goal, which was the prime motivator
behind doing a Derby implementation. I am sure that if we were
Yup.
Karl
-Original Message-
From: ext Jack Krupansky [mailto:jack.krupan...@lucidimagination.com]
Sent: Friday, June 04, 2010 12:27 AM
To: connectors-dev@incubator.apache.org
Subject: Re: Derby
Just to be clear, the full sequence would be:
1) Start UI app. Agent process should
For what it's worth, after some 5 days of work, and a couple of schema changes
to boot, LCF now runs with Derby.
Some caveats:
(1) You can't run more than one LCF process at a time. That means you need
to either run the daemon or the crawler-ui web application, but you can't run
both
: Thursday, June 03, 2010 5:51 PM
To: connectors-dev@incubator.apache.org
Subject: Re: Derby
(1) You can't run more than one LCF process at a time. That means you
need to either run the daemon or the crawler-ui web application, but you
can't run both at the same time.
How do you Start
) Possibly commit to Solr.
7) AgentStop.
8) Back to step 1 for additional jobs.
Correct?
-- Jack Krupansky
--
From: karl.wri...@nokia.com
Sent: Thursday, June 03, 2010 7:24 PM
To: connectors-dev@incubator.apache.org
Subject: RE: Derby
The daemon does
--
From: karl.wri...@nokia.com
Sent: Thursday, June 03, 2010 5:34 PM
To: connectors-dev@incubator.apache.org
Subject: Derby
For what it's worth, after some 5 days of work, and a couple of schema
changes to boot, LCF now runs with Derby.
Some caveats:
(1) You can't run more than one
68 matches
Mail list logo
