Menu
▾
▴
babeldoc-devel
|
From: Leech, J. <jl...@vi...> - 2003-07-10 22:43:10
|
I think we need to remove synchronization from the checkIn() and checkOut() methods of PooledJdbc.java, and here's the reason why: It causes deadlock every time the connection pool is exhausted. Example: - All database connections in the pool are being used by various threads. - A thread calls checkOut(), which locks the PooledJdbc object, and the connection pool is waiting for a checkin. - As the various threads finish using their database connections, they call checkIn(), but are locked out. The only problem I see with it doing it is that there's a chance that multiple threads could ask for the first connection, which calls setupJdbc(), and that might be not well behaved. I think moving the setupJdbc to the default constructor would handle this. Thoughts? -Jonathan |
|
From: Bruce M. <br...@mc...> - 2003-07-11 04:32:19
|
Sounds fair - It sounds like you have made a good catch. Commit the code. On Thursday 10 July 2003 06:42 pm, Leech, Jonathan wrote: > I think we need to remove synchronization from the checkIn() and checkOut() > methods of PooledJdbc.java, and here's the reason why: It causes deadlock > every time the connection pool is exhausted. > > Example: > - All database connections in the pool are being used by various threads. > - A thread calls checkOut(), which locks the PooledJdbc object, and the > connection pool is waiting for a checkin. > - As the various threads finish using their database connections, they call > checkIn(), but are locked out. > > The only problem I see with it doing it is that there's a chance that > multiple threads could ask for the first connection, which calls > setupJdbc(), and that might be not well behaved. I think moving the > setupJdbc to the default constructor would handle this. > > Thoughts? > > -Jonathan |
|
From: Stefan K. <ste...@co...> - 2003-07-15 20:41:20
|
Hello,
I have seen that the new RouterPipelineStage has an option wether to copy
the attributes to the new document or not.
I think this should be done generally for all PipelineStage that can split
up documents.
I have the same requirement for XPathSpillter and fixed it into the base
PiplineStage method.
What do you think about introducing a new "standard" stage option, i.e.
"copyAttributes" ?
This could be defaulted to false, so it want break with the existing way.
BTW: During our project we have had tremendous trouble with your
configuration appending mechanism.
I can't give you any more details, I am just happy that we have it now
running.
We ended up with copies of some "config.properties" in our config dir and
removed some from the babeldoc JARs.
We are still on version 1.0, so I am not sure if this is already fixed.
Stefan
protected PipelineStageResult[] processHelper(String[] results)
throws PipelineException, JournalException {
IJournal journal = JournalFactory.getJournal();
PipelineStageResult[] psresults = new
PipelineStageResult[results.length];
String name = this.getNextPipelineStageName();
//Process each of the documents
for (int i = 0; i < results.length; ++i) {
IJournalTicket newTicket = journal.forkTicket(ticket);
PipelineDocument newDoc = new PipelineDocument(results[i].getBytes());
// PATCH: copy attributes
PipelineDocument doc = getDocument() ;
for ( Iterator it = doc.keys().iterator(); it.hasNext() ; ) {
String key = (String) it.next() ;
newDoc.put( key, doc.get( key ) ) ;
}
psresults[i] = new PipelineStageResult(name, newDoc, newTicket);
}
return psresults;
}
|
|
From: Bruce M. <br...@mc...> - 2003-07-15 22:28:02
|
Stefan,
Can you and Jonathon Leech talk about this. I would be interested in a
general solution to the problem of handling attributes when documents are
split / routed etc.
I have been using the 1.1 codebase extensively in a production project and am
fairly sure that the configuration merging works according to design
(hahaha). But seriously, it seems to work ok for me.
I would suggest (hope) that you start using the 1.1 codebase - it is a lot
more robust in a number of areas and especially in configuration.
regards,
Bruce McDonald
On Tuesday 15 July 2003 04:41 pm, Stefan Krieger wrote:
> Hello,
>
> I have seen that the new RouterPipelineStage has an option wether to copy
> the attributes to the new document or not.
> I think this should be done generally for all PipelineStage that can split
> up documents.
> I have the same requirement for XPathSpillter and fixed it into the base
> PiplineStage method.
>
> What do you think about introducing a new "standard" stage option, i.e.
> "copyAttributes" ?
> This could be defaulted to false, so it want break with the existing way.
>
> BTW: During our project we have had tremendous trouble with your
> configuration appending mechanism.
> I can't give you any more details, I am just happy that we have it now
> running.
> We ended up with copies of some "config.properties" in our config dir and
> removed some from the babeldoc JARs.
> We are still on version 1.0, so I am not sure if this is already fixed.
>
> Stefan
>
> protected PipelineStageResult[] processHelper(String[] results)
> throws PipelineException, JournalException {
>
> IJournal journal = JournalFactory.getJournal();
> PipelineStageResult[] psresults = new
> PipelineStageResult[results.length];
> String name = this.getNextPipelineStageName();
> //Process each of the documents
> for (int i = 0; i < results.length; ++i) {
> IJournalTicket newTicket = journal.forkTicket(ticket);
> PipelineDocument newDoc = new
> PipelineDocument(results[i].getBytes()); // PATCH: copy attributes
> PipelineDocument doc = getDocument() ;
> for ( Iterator it = doc.keys().iterator(); it.hasNext() ; ) {
> String key = (String) it.next() ;
> newDoc.put( key, doc.get( key ) ) ;
> }
> psresults[i] = new PipelineStageResult(name, newDoc, newTicket);
> }
> return psresults;
> }
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Babeldoc-devel mailing list
> Bab...@li...
> https://lists.sourceforge.net/lists/listinfo/babeldoc-devel
|
|
From: Bruce M. <br...@mc...> - 2003-07-24 01:32:37
|
Jonathan, I haven't heard from you in some time - how is it going? The work that you have done on babeldoc in recent weeks and months has been excellent. I am hoping to see your work on the xml entity resolver. regards, Bruce. On Thursday 10 July 2003 06:42 pm, Leech, Jonathan wrote: > I think we need to remove synchronization from the checkIn() and checkOut() > methods of PooledJdbc.java, and here's the reason why: It causes deadlock > every time the connection pool is exhausted. > > Example: > - All database connections in the pool are being used by various threads. > - A thread calls checkOut(), which locks the PooledJdbc object, and the > connection pool is waiting for a checkin. > - As the various threads finish using their database connections, they call > checkIn(), but are locked out. > > The only problem I see with it doing it is that there's a chance that > multiple threads could ask for the first connection, which calls > setupJdbc(), and that might be not well behaved. I think moving the > setupJdbc to the default constructor would handle this. > > Thoughts? > > -Jonathan |
|
From: Bruce M. <br...@mc...> - 2003-07-24 01:36:30
|
All, Just wanted to let you know that I am contactable on Yahoo Instant Messenger, id: triphopping_man. Unfortunately the firewall at my current work is somewhat restrictive and sometimes messages get dropped :( Keep trying. regards, Bruce. |
Thanks for helping keep SourceForge clean.
X