RE: [jbosscache-dev] Using Apache DBCP in NonManagedConnectionFactory
by Vladimir Blagojevic
Never underestimate people's stupidity, like me for example. On a more
serious note, can this pooling be isolated and then use interchangable
pooling implementations? How does hibernate make it interchangable? They
must be using some adaptation layer?
My main point is to see what they have done and not reinvent the wheel.
> -----Original Message-----
> From: Manik Surtani [mailto:manik@jboss.org]
> Sent: Thursday, October 12, 2006 12:53 PM
> To: Vladimir Blagojevic
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: Re: [jbosscache-dev] Using Apache DBCP in
> NonManagedConnectionFactory
>
> I doubt anyone would use a cache loader if JBC is a cache for
> Hibernate. :-)
>
> This is more for standalone cases, not even within an app
> server since then the app server would provide db conn pooling.
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
State transfer tests in head
by Manik Surtani
Hi,
As a part of refactoring the marshall.Region class to a generic
Region which can be used for eviction as well, Brian and I discussed
removing queueing of calls to inactive regions, since this would be
replaced with FLUSH. As such, I've commented out a few unit tests
that test this queueing in VersionedTestsBase and have commented
accordingly. Vladimir, once we roll in FLUSH and have this working
as expected, could you revisit these tests in state transfer?
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
UseRegionBasedMarshalling flag
by Manik Surtani
Is this flag really necessary? Isn't it fair to say that if a region
is defined with a context classloader then region-based marshalling
should be used for that region?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
RE: [jbosscache-dev] Using Apache DBCP in NonManagedConnectionFactory
by Vladimir Blagojevic
Should ask Hibernate guys what to do? I think they use c3p0 as default.
Any potential pooling issues if someone uses jbc as a second level cache
for hibernate?
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Manik Surtani
> Sent: Thursday, October 12, 2006 10:26 AM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Using Apache DBCP in
> NonManagedConnectionFactory
>
> At the moment, when using the non-managed connection factory
> in the JDBC cache loader, a new connection is created for
> every operation and in high-concurrency environments this can
> exhaust the db connections.
>
> Should we be using a pooling library like Apache's DBCP[1]
> for this?
> Probably increase efficiency a great deal. A user attempting
> to improve throughput hacked in an open connection and stored
> it in thread-local and saw some really big improvements[2].
> His hack is not a solution since it breaks when using
> transactions, but highlights the need for a conn pool for
> people who use this cache loader outside of an app server.
>
> [1] http://jakarta.apache.org/commons/dbcp/
> [2] http://www.jboss.com/index.html?
> module=bb&op=viewtopic&p=3977895#3977895
>
> What do people think?
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years, 1 month
Using Apache DBCP in NonManagedConnectionFactory
by Manik Surtani
At the moment, when using the non-managed connection factory in the
JDBC cache loader, a new connection is created for every operation
and in high-concurrency environments this can exhaust the db
connections.
Should we be using a pooling library like Apache's DBCP[1] for this?
Probably increase efficiency a great deal. A user attempting to
improve throughput hacked in an open connection and stored it in
thread-local and saw some really big improvements[2]. His hack is
not a solution since it breaks when using transactions, but
highlights the need for a conn pool for people who use this cache
loader outside of an app server.
[1] http://jakarta.apache.org/commons/dbcp/
[2] http://www.jboss.com/index.html?
module=bb&op=viewtopic&p=3977895#3977895
What do people think?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
NonManagedConnectionFactory in JDBCCacheLoader
by Manik Surtani
Following up from this thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977381
Any idea why connections created in getConnection() aren't stored in
the ThreadLocal as they are in prepare()? Is this so that the same
connection is used throughout the tx? Does this also make sense that
the conn is not closed in ConnectionFactory.close() if the connection
is the same as the one in ThreadLocal, and is only closed by a commit
() or rollback()?
I presume then that a proper approach here would be to use a HashMap
of connections as a rudimentary pool?
Thanks,
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
RE: [jbosscache-dev] FW: [JBoss JIRA] Created: (JBAS-3753) HAParititonImpl implements org.jgroups.ChannelListener
by Brian Stansberry
I opened a forum thread for this at
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=92428; let's do
any further discussion there.
Brian Stansberry wrote:
> The problem is that when your channel disconnects, you don't
> get a new view. Experiments with HAPartition showed me that.
> You do get one when it reconnects. Mainly the issue is to
> think through the implications of that. Some initial thoughts:
>
> 1) While you're disconnected you can't properly replicate.
> What's the proper behavior -- hold calls in
> ReplicationInterceptor until you reconnect, which will happen
> automatically? Or throw exceptions when you try to send
> messages on the channel (which I'd expect is what happens
> now)? If the latter, it becomes important to have a way to
> communicate to the application that the cache is
> disconnected, so the application can decide whether or not to
> hold calls.
>
> 2) When the new view comes in after reconnect, does the node
> need to reassign it's buddy and transfer state? During the
> period of broken communication leading up to the shunning,
> the buddy probably wasn't getting replication traffic. If
> REPL_ASYNC, the sender would not know this. If we do need to
> reassign buddies, when the new view comes in will the BR code
> recognize it needs to do this?
>
> 3) The channel is always AUTO_GET_STATE. So, when it
> reconnects getState() will be called on the coordinator and
> setState() will be called on the node. This is inappropriate
> in many configurations; basically most of those that don't do
> an initial state transfer. See
> http://jira.jboss.com/jira/browse/JBCACHE-805. If it is
> appropriate, do we handle it properly?
>
> 3) Non-BR case with region-based marshalling. We definitely
> don't want a single monolithic state transfer; won't be able
> to deserialize it. But, we do need to re-transfer the state,
> as we're now out of sync with the cache. Right now we don't do this.
>
> A lot of similar issues apply in the merge case.
>
> -Brian
>
> Manik Surtani wrote:
>> Within JBC, how does this affect? Perhaps triggering a reorg of budy
>> groups? But this is done when a new view is issued anyway.
>>
>>> Hi,
>>>
>>> The below issue pertains to JBC as well. Propagation of awareness
>>> of shunning to user code may be less of an issue, but internal
>>> awareness is important.
>>>
>>> Brian Stansberry (JIRA) wrote:
>>>> HAParititonImpl implements org.jgroups.ChannelListener
>>>> ------------------------------------------------------
>>>>
>>>> Key: JBAS-3753
>>>> URL: http://jira.jboss.com/jira/browse/JBAS-3753
>>>> Project: JBoss Application Server
>>>> Issue Type: Feature Request
>>>> Security Level: Public (Everyone can see)
>>>> Components: Clustering
>>>> Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1
>>>> Reporter: Brian Stansberry
>>>> Assigned To: Brian Stansberry
>>>> Fix For: JBossAS-5.0.1.CR1
>>>>
>>>>
>>>> Currently if a JChannel is shunned and disconnects, higher level
>>>> services are unaware of this and can't take any remedial action.
>>>>
>>>> We need to do something like implement ChannelListener so an
>>>> HAPartition is aware when the events on the underlying channel
>>>> occur. Then devise a scheme to propagate some of the events to user
>>>> code. Preferably this will follow as much as possible the existing
>>>> notification scheme; i.e. pass a new view to HAMembershipListener
>>>> impls that doesn't include the current node.
>>>
>>>
>>>
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss, a division of Red Hat
>>> Ph: 510-396-3864
>>> skype: bstansberry
>>>
>>> _______________________________________________
>>> jbosscache-dev mailing list
>>> jbosscache-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 1 month
RE: [jbosscache-dev] FW: [JBoss JIRA] Created: (JBAS-3753) HAParititonImpl implements org.jgroups.ChannelListener
by Brian Stansberry
The problem is that when your channel disconnects, you don't get a new
view. Experiments with HAPartition showed me that. You do get one when
it reconnects. Mainly the issue is to think through the implications of
that. Some initial thoughts:
1) While you're disconnected you can't properly replicate. What's the
proper behavior -- hold calls in ReplicationInterceptor until you
reconnect, which will happen automatically? Or throw exceptions when
you try to send messages on the channel (which I'd expect is what
happens now)? If the latter, it becomes important to have a way to
communicate to the application that the cache is disconnected, so the
application can decide whether or not to hold calls.
2) When the new view comes in after reconnect, does the node need to
reassign it's buddy and transfer state? During the period of broken
communication leading up to the shunning, the buddy probably wasn't
getting replication traffic. If REPL_ASYNC, the sender would not know
this. If we do need to reassign buddies, when the new view comes in
will the BR code recognize it needs to do this?
3) The channel is always AUTO_GET_STATE. So, when it reconnects
getState() will be called on the coordinator and setState() will be
called on the node. This is inappropriate in many configurations;
basically most of those that don't do an initial state transfer. See
http://jira.jboss.com/jira/browse/JBCACHE-805. If it is appropriate, do
we handle it properly?
3) Non-BR case with region-based marshalling. We definitely don't want a
single monolithic state transfer; won't be able to deserialize it. But,
we do need to re-transfer the state, as we're now out of sync with the
cache. Right now we don't do this.
A lot of similar issues apply in the merge case.
-Brian
Manik Surtani wrote:
> Within JBC, how does this affect? Perhaps triggering a reorg
> of budy groups? But this is done when a new view is issued anyway.
>
>> Hi,
>>
>> The below issue pertains to JBC as well. Propagation of awareness of
>> shunning to user code may be less of an issue, but internal
>> awareness is important.
>>
>> Brian Stansberry (JIRA) wrote:
>>> HAParititonImpl implements org.jgroups.ChannelListener
>>> ------------------------------------------------------
>>>
>>> Key: JBAS-3753
>>> URL: http://jira.jboss.com/jira/browse/JBAS-3753
>>> Project: JBoss Application Server
>>> Issue Type: Feature Request
>>> Security Level: Public (Everyone can see)
>>> Components: Clustering
>>> Affects Versions: JBossAS-4.0.4.GA, JBossAS-3.2.8.SP1
>>> Reporter: Brian Stansberry
>>> Assigned To: Brian Stansberry
>>> Fix For: JBossAS-5.0.1.CR1
>>>
>>>
>>> Currently if a JChannel is shunned and disconnects, higher level
>>> services are unaware of this and can't take any remedial action.
>>>
>>> We need to do something like implement ChannelListener so an
>>> HAPartition is aware when the events on the underlying channel
>>> occur. Then devise a scheme to propagate some of the events to user
>>> code. Preferably this will follow as much as possible the existing
>>> notification scheme; i.e. pass a new view to HAMembershipListener
>>> impls that doesn't include the current node.
>>
>>
>>
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> Ph: 510-396-3864
>> skype: bstansberry
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 1 month
RE: Reinstating CruiseControl for the 1.4.x branch
by Rajesh Rajasekaran
Done.
There will be a run from tonight.
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Tuesday, October 10, 2006 7:57 AM
To: QA
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Reinstating CruiseControl for the 1.4.x branch
Hi,
Some while back we had parallel cruise control runs for JBoss Cache:
on HEAD as well as on Branch_JBossCache_1_4_0. Could we pls
reinstate the latter, since there is a fair bit of work going on on
the 1.4.x branch, and we may release a 1.4.0.SP2 (or 1.4.1) at some
point.
Thanks,
Manik
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
18 years, 1 month
