We generally instantiate a pool per JVM, where the maxActive is (# of bolts using JDBC/num workers+1) (e.g. 64 bolts, 4 workers, 17 conns/JVM).
Pooling is our preferred strategy as the pool will shrink (and thus use less memory on the corresponding SQL server) if it's not being utilized. In either case, t's pushing the management, verification, and reestablishment of broken connections into the pool (which is also why we have 1 extra conn -- for when a conn is tied up running a validation query or is being reestablished). Michael Rose (@Xorlev <https://twitter.com/xorlev>) Senior Platform Engineer, FullContact <http://www.fullcontact.com/> mich...@fullcontact.com On Thu, Feb 20, 2014 at 8:28 AM, Richards Peter <hbkricha...@gmail.com>wrote: > Hi Pablo, > > Your approach is fine. Alternative approach proposed by Brian can be used > if you can group the relevant bolt instance/es, which are communicating to > the database, into the appropriate worker process/es. However with the > alternative approach you shouldn't end up creating separate pools in all > the workers used by the topology. > > Hope this helps. > > Richards Peter. > > > > > On Thu, Feb 20, 2014 at 8:33 PM, Pablo Acuña <pa...@guud.tv> wrote: > >> I keep one connection per bolt and for now it works just fine with many >> bolts. I would also be interested in hearing from someone else and share >> experiences. >> >> For now, I open the connection in the method prepare (and close it in >> cleanup), but to be completely honest, I'm not 100% sure if this is the >> best approach. >> >> cheers, >> Pablo. >> >> >> On Wed, Feb 19, 2014 at 4:41 PM, Brian O'Neill <b...@alumni.brown.edu>wrote: >> >>> Yes. We use JDBI to access MySQL. >>> >>> We've had success with a shared connection pool. (one per JVM) >>> The bolts in the JVM share the pool. >>> >>> But either approach should work (pool per bolt, or connection per bolt). >>> It just depends at what level you want to manage your connections. >>> >>> We do it at the worker level. (n connections per worker) >>> >>> -brian >>> >>> --- >>> >>> Brian O'Neill >>> >>> Chief Technology Officer >>> >>> >>> *Health Market Science* >>> >>> *The Science of Better Results* >>> >>> 2700 Horizon Drive * King of Prussia, PA * 19406 >>> >>> M: 215.588.6024 * @boneill42 <http://www.twitter.com/boneill42> * >>> >>> healthmarketscience.com >>> >>> >>> This information transmitted in this email message is for the intended >>> recipient only and may contain confidential and/or privileged material. If >>> you received this email in error and are not the intended recipient, or the >>> person responsible to deliver it to the intended recipient, please contact >>> the sender at the email above and delete this email and any attachments and >>> destroy any copies thereof. Any review, retransmission, dissemination, >>> copying or other use of, or taking any action in reliance upon, this >>> information by persons or entities other than the intended recipient is >>> strictly prohibited. >>> >>> >>> >>> >>> From: Klausen Schaefersinho <klaus.schaef...@gmail.com> >>> Reply-To: <user@storm.incubator.apache.org> >>> Date: Wednesday, February 19, 2014 at 5:58 AM >>> To: <user@storm.incubator.apache.org> >>> Subject: JDBC Connections >>> >>> Hi, >>> >>> one of my bolt will need to write to a MySql data base. Does anybody has >>> some experience with this? What are the best practices? Use an connection >>> pool? Or keep one connection open per bolt? >>> >>> Cheers, >>> >>> klaus >>> >> >> >
