Help getting Apache's Scarab up again
Hi there, following suggestion from Henning Schemiedehause... I'd like to encourage the people that spoke up in this thread (Thomas, Jorge) to get in contact with the ASF infrastructure team ([EMAIL PROTECTED]) and sort out the Scarab issues and maybe volunteer as Scarab maintainers. ...I'd like to offer my help in what you might need to get your Scarab instance up again. Even though I'm implied in Scarab myself, this help is not bound to anything; If you want help to get it running so you can extract the issues, that's fine. If you want help migrating to an uptodate (and much better ;-) ) version of Scarab, that's even better! If I (or other Scarab committers) can help maintaining Scarab it would be great, because you bet, loosing Apache visibility is a great loose for our project, but I fear I'm not a committer in any Apache prokect, and there might be political/community reasons to disallow this. In this case, I will still be glad to help others to do it. Whatever decision you find better, let me know and we'll look for the best way to start. Greetings, _ Jorge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move the Torque Bugtracker to JIRA
Scott Eade wrote: There has in fact been some recent progress with Scarab over at Tigris - e.g. on their instance you can look at issues without logging in. The trouble is that to get the ASF instance upgraded will require more effort from those involved than can be justified. If there was some momentum behind Scarab things would be quite different, but unfortunately this is not the case. Hi Scott, sad you feel there is no momentum :-( Lots of Turbine/Torque users/devs are involved somehow in Scarab (Youngho, Fabio, Eric, comes to mind) As I've already sent to Turbine's list, Scarab has indeed gained some speed lately, but this should by no means be the reason behind Turbine moving away. Apache was using a very old version of Scarab, and I'm not sure about the problems it caused. Late as it can be, maybe we should have marketed ourselves months ago (I really thought about offering help for upgrading but... late again...) As I told before; feel free to ask if you wanted help in the migration. Regards, _ Jorge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move the Torque Bugtracker to JIRA
Scott Eade wrote: There has in fact been some recent progress with Scarab over at Tigris - e.g. on their instance you can look at issues without logging in. The trouble is that to get the ASF instance upgraded will require more effort from those involved than can be justified. If there was some momentum behind Scarab things would be quite different, but unfortunately this is not the case. Hi Scott, sad you feel there is no momentum :-( Lots of Turbine/Torque users/devs are involved somehow in Scarab (Youngho, Fabio, Eric, comes to mind) As I've already sent to Turbine's list, Scarab has indeed gained some speed lately, but this should by no means be the reason behind Turbine moving away. Apache was using a very old version of Scarab, and I'm not sure about the problems it caused. Late as it can be, maybe we should have marketed ourselves months ago (I really thought about offering help for upgrading but... late again...) As I told before; feel free to ask if you wanted help in the migration. Regards, _ Jorge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IDBROKER generated ids suddenly becomes HUGE
Hi there,
out there in Scarab we're facing a strange bug that is driving us crazy.
We're currently using torque-3.1.1 and torque-gen-3.1.1-dev
You can take a look at the bug here (no user required):
http://www.solitone.org/scarab/issues/id/SCB1514
The problem, in a few words, is that sometimes (recipe still missing)
the ID number returned by the IDBROKER is HUG.
The value is not the primary key for a table (its the number part of the
issue ID, you know scarab ;-) ).
I guess the code below (java, and id_table.xml) is the responsible:
(full code here http://svn.collab.net/viewcvs/scarab/trunk/src
/java/org/tigris/scarab/om/Issue.java?rev=9569view=markup)
It's *old* code, and I don't really know why did it started failing, but
I somehow don't dare to change it...
There are several things I don't understand in it:
* It seems to expect the first call to getIdAsInt failing, and then it
tries again synchronizing the call...
* If it fails again, it asumes it does not exist (!) and then starts the
count from 1 (this might be to make sure it finds a record in ID_TABLE
for a new module)
private int getNextIssueId(Connection con)
throws Exception
{
int id = -1;
String key = getIdTableKey();
DatabaseMap dbMap = IssuePeer.getTableMap().getDatabaseMap();
IDBroker idbroker = dbMap.getIDBroker();
try
{
id = idbroker.getIdAsInt(con, key);
}
catch (Exception e)
{
synchronized (idbroker)
{
try
{
id = idbroker.getIdAsInt(con, key);
}
catch (Exception idRetrievalErr)
{
// a module code entry in the id_table was likely
not
// entered, insert a row into the id_table and try
again.
try
{
saveIdTableKey(con);
id = 1;
}
catch (Exception badException)
{
getLog().error(Could not get an id, even after
+trying to add a module entry into the
ID_TABLE,
e);
getLog()
.error(Error trying to create ID_TABLE
entry for
+ getIdTableKey(), badException);
// throw the original
throw new ScarabException(
L10NKeySet.ExceptionRetrievingIssueId,
badException);
}
}
}
}
return id;
}
This is the definition of the ID_TABLE:
database name=scarab
table name=ID_TABLE idMethod=idbroker
column name=ID_TABLE_ID required=true primaryKey=true
type=INTEGER/
column name=TABLE_NAME required=true size=255
type=VARCHAR/
column name=NEXT_ID type=INTEGER/
column name=QUANTITY type=INTEGER/
unique
unique-column name=TABLE_NAME/
/unique
/table
/database
Any hint about where the problem would be?
Any idea about why is this code so *strange*?
Thanks!!
_
Jorge
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
