Hey To your response that as ActiveMQConnection will have a ExceptionListener already registered against it, what will happen if after getting this activeMQ connection from connection factory I again register a listener against it.
Will this exception handler super seed the already registered handler/ will be a addition to the existing handler. If it superseeds it will I have to explicitly handle every exception that i get now. In case it is just an addition then what all JMS Exceptions will I be getting. Will I get an exception, connection closed(if broker goes down and I had the broker registered with the failover thing in the ur). Basically if I have a exception listener registered against my connection, so shud i be worrying about broker going down if have a faliover thing specified in my url. I am sure I don't need to in case I have no exception listener registered against this connection. Thanks for bearing with me answering till now. :) gnodet wrote: > > On Tue, Feb 3, 2009 at 21:07, soody <atins...@gmail.com> wrote: >> >> Hey >> >> Thx for the reply.. after reading ur blog address i realised that i had >> already referred ur blog in this context. I guess the article was some 2 >> year old article :) >> But this tells me that you are exactly the perfect person to have all my >> doubts cleared:) >> >> >> I am trying to implement pooling. As far as I understood from Pooling >> Code >> of ActiveMq, they are creating some conns, creating multiple sessions on >> them and creating one producer from each of these sessions. Is this the >> correct approach or shud we have multiple producers from each of these >> sessions.So basically this is session pooling. I don't think we are >> pooling >> our producers anywhere. Does making pool of producers also makes sense or >> is >> pooling till this level sufficient. > > What happens is that a single producer is used for a pooled session. > This producer is wrapped into PooledProducer instances, hence the need > for the synchronized block you referred to. I guess the reason is > that creating and closing a producer involves sending messages from > the client to the broker, and a producer can be used to send to any > destination (unlike a consumer), so there's no real reason to use > multiple producers. > >> >>>Also what should be my approach for having pooling(or any thing that >> improves performance) for consumers. > > That's a totally different question. Existing things include: > * JCA connector (using jencks for example) > * Spring JMS layer, especially the DefaultMessageListenerContainer and > related > > I'm also working on a kind of message listener container with some > specific stuff inside (such as being able to asynchronously handle the > received jms message). My work in progress also includes an ActiveMQ > specific version which is more optimized. > > The main problem with consumer pooling is that if you don't consume > messages when the broker dispatches them to the consumer, they will > stay there until the consumer is closed. So you can not really have > consumers waiting in a pool. > >> >> 2) There is this another problem. Sorry for asking so much out of u. >> >> There is this thread in nabble where s.1 had asked how to reconnect to >> activeMQ if their broker goes down.The reply says we need to have >> failover:(tcp://localhost:61616) as the broker url. >> >> I agree with it, but I want to know that in case the broker goes down I >> guess we will be getting JMSException when we try to send messages to it. >> So >> if we have a exceptionListener registered against the connection then we >> can >> code the message listener to make sure it tries to get a new connection. >> >> So if that is the case how does this failover thing works, and if this >> failover thing works and i have a exceptionlistener registered will it >> still >> get the exception. And in what cases will the registered exception >> listener >> receive/won't receive the exception. > > The ConnectionPool class already registers a listener and when a > problem occurs at the transport level, the connection will be > discarded and a new one will be created next time it is requested from > the pooled connection factory. > For the failover, have a look at > http://activemq.apache.org/failover-transport-reference.html > >> >> 3) Also in PooledSesion class in close method why only consumers are >> being >> closed and not producers. > > Consumers are closed to avoid having messages waiting in the consumer > forever. Producers do not have such problems, so there is no need to > close those when the session is returned to the pool. > >> >> >> gnodet wrote: >>> >>> The block synchronizes on the message producer, which means it's here >>> in case the *same* producer is used from several different threads, so >>> it should not have much overhead when using multiple producers (which >>> would be recommand afaik). >>> >>> For the pooling part, the first thing is that consuming messages and >>> pooling is quite incompatible usually. The main problem is that if >>> you keep unused consumers alive, messages can be waiting on the >>> consumer and thus never be actually delivered (if you don't consumer >>> those messages or close the consumer). >>> For session / producer pooling, you should be free to use the pooled >>> connection factory. >>> >>> On Tue, Feb 3, 2009 at 15:55, soody <atins...@gmail.com> wrote: >>>> >>>> I am working on JMS pooling and have a few doubts >>>> 1)I was going through the pool package of ActiveMQ. In >>>> PooledMessageProducer >>>> we have s.th like >>>> >>>> // just in case let only one thread send at once >>>> synchronized (messageProducer) { >>>> messageProducer.send(destination, message, deliveryMode, >>>> priority, timeToLive); >>>> } >>>> >>>> in the send method. >>>> >>>> I am not sure why we need to have the send synchronized. AS far as I >>>> understand we can use as many producers from a session and send msgs in >>>> parallel from them to the same destination.... Only thing that can get >>>> messed up is there will be no order in which these msgs are sent. But I >>>> guess when we decided to use multiple threads to send msgs we have >>>> anyways >>>> made our choice to drop the sequencing order. >>>> >>>> 2)Also there has been much discussion the pooling thing but there is >>>> nothing >>>> concrete. I guess for any JMS client we can write a wrapper around the >>>> PooledConnectionFactory and other classes and make sure that we have a >>>> number of connections and a pool of sessions associated with it. We can >>>> use >>>> these for pooling. >>>> Does it make any diff if we use this for producing or consumption of >>>> msgs. >>>> Please note I am talking about a standalone JMS Client, no springs >>>> included >>>> and a pretty generic client that can work with any JMS provider. >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21811493.html >>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >>>> >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21817781.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > -- View this message in context: http://www.nabble.com/JMS-pooling...-pool-package-in-activeMQ-tp21811493p21827608.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
