On Fri, 17 Mar 2006, Jason Dillon wrote:
> Prior to escalation to the ASF, a Podling needs to show that :
>
> * it is a worthy and healthy project;
> * it truly fits within the ASF framework;and
> * it "gets" the Apache Way.
>
>
> Part of the way is to resolve conflict with in the community.
I wanted to see what this incubation problem is all about, so I took a
look at the web site http://incubator.apache.org/resolution.html .
It says that the B.o.D. has determined that it's in "the best interests of
the Foundation" to create this incubator PMC charged with "providing
guidance", to h
On Tue, 14 Mar 2006, David Blevins wrote:
> Provisioning of the actual stateful session bean keys is easy to
> isolate, but as I say inventing a client id that you could use as
> part of a stateful session bean's id is not easy.
Would it be enough to generate a cluster-wide unique id?
FYI, I put out 1.0b3 which contains a couple of major bug fixes, which
specifically showed up on windows.
Also, a user reported running the local benchmark and getting 25,000
messages per second (= 300Mbps). Also my new turion64 laptop gets
about 240Mbps, also on a local test.
I'm not sure if reliable multicast in Java would ever
> perform well enough to be worth it from a pure performance perspective.
> I'd love to be proved wrong of course :).
When you have a free hour, see
http://www.bway.net/~lichtner/evs4j.html
I cannot guarantee that you will deci
ure it
> could be used in other places too.
>
> James
>
>
> On 15 Feb 2006, at 19:38, lichtner wrote:
> >
> > Is there any interest in an apache-licensed version of jgroups?
> >
> > I am thinking something along these lines:
> >
> > 1. Well-unde
I'm sure it
> could be used in other places too.
>
> James
>
>
> On 15 Feb 2006, at 19:38, lichtner wrote:
> >
> > Is there any interest in an apache-licensed version of jgroups?
> >
> > I am thinking something along these lines:
> >
> > 1. Well-un
Is there any interest in an apache-licensed version of jgroups?
I am thinking something along these lines:
1. Well-understood layered architecture, of x-kernel, Ensemble, and
JGroups fame.
2. Performance-focused: low thread count per protocol layer (0+), no java
serialization.
3. Simple: imple
On Thu, 9 Feb 2006, Jason Dillon wrote:
> Thanks! My DBA cleared this for me and now XA is working with 1 Oracle
> DS and 1 ActiveMQ CF. I still can not get the 2 Oracle datasources
> working together with XA though.
Glad it worked out.
> Did anyone have a chance to peek at that URL I mailed d
On Tue, 7 Feb 2006, Jason Dillon wrote:
> I've got a db looking into fixing that for me...
>
> And created https://issues.apache.org/jira/browse/GERONIMO-1599
>
> I'm not sure how to fix this though :-(
It looks like line 219 is setting a null xidFactory. It looks like
xidFactory is a GBean attr
Since you crashed so many times and then had to delete the log, which
knows how to clean up the in-doubt transactions, you now have some
transactions which are waiting to be committed or rolled back and are
holding locks (as they should.)
If you have a dba I would get him/her involved.
To do it
It just sounds like a bug, I guess.
On Tue, 7 Feb 2006, Jason Dillon wrote:
> I'm not saying it won't work... but its defintetly not happy with
> TranQL with its throwing an exception for a metadata query instead of
> returning false.
>
> --jason
>
>
> On 2/7/06, [EMAIL PROTECTED] <[EMAIL PROTE
I guess HowlLog.java line 362 should not be throwing an exception.
> And starting up G right after produces this:
>
>
> Booting Geronimo Kernel (in Java 1.4.2_09)...
> Started configuration 1/23 0s geronimo/rmi-naming/1.0/car
> 16:15:06,779 ERROR [GBeanInstanceState] Error while starting; GBe
It's not supposed to do that. It should scan the recovery log, then call
XAResource.recover() before the data source is first used. Since you are
getting an NPE there may be a bug in the code.
>> What do you mean by "corrupts"? Do you mean that the transaction manager
>> does not perform recovery
9.2.x.x does work with XA.
> I'm going to retest everything with the 10.2.0.1.0_g driver... since
> 9.2.* was whack for non-xa I'm not sure that anything would work as
> expected.
>
> --jason
>
>
> On 2/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> > I have a feeling that something else i
> I have a feeling that something else is wrong, as I mentioned before I
> see hanging transactions when using the local adapter in local-tx
> mode. And when I ctrl-c G it corrupts the txlog each time... which is
> very bad IMO.
What do you mean by "corrupts"? Do you mean that the transaction man
-3 should be javax.transaction.xa.XAException.XA_RMERR:
http://java.sun.com/j2ee/1.4/docs/api/constant-values.html#javax.transaction
Anyhow, you are not actually enlisting the oracle resource manager, so
that's a step in the right direction.
I think that Geronimo is not printing the stack trace
nskrit.
>
> Aaron
>
> On 2/6/06, lichtner <[EMAIL PROTECTED]> wrote:
> >
> > ORA-02089: COMMIT is not allowed in a subordinate session
> > Cause: COMMIT was issued in a session that is not the two-phase commit
> > global coordinator.
> > Action: Issue commit at the global coordinator only.
ss as to why this happens :-(
>
> --jason
>
>
> -Original Message-
> From: lichtner <[EMAIL PROTECTED]>
> Date: Mon, 6 Feb 2006 22:06:48
> To:dev@geronimo.apache.org
> Subject: Re: Oracle XA RAR for G1.0?
>
>
> ORA-02089: COMMIT is not allowed in a
ORA-02089: COMMIT is not allowed in a subordinate session
Cause: COMMIT was issued in a session that is not the two-phase commit
global coordinator.
Action: Issue commit at the global coordinator only.
http://oraclesvca2.oracle.com/docs/cd/B19306_01/server.102/b14219/e1500.htm#sthref32
morning against
> > the Oracle 10.1.4.0 classes12.jar.
> >
> > I've published it and it is called tranql/rars/tranql-connector-
> > oracle-xa-1.0-SNAPSHOT.rar
> >
> > If someone can try this out then that would be excellent. I have
> > only compiled it a
On Fri, 3 Feb 2006, David Jencks wrote:
> It is likely to work if you build it. However I don't know that it
> has been used in the last year or more, so I won't make any
> promises. Matt might have tried it, I don't know. We have been a
> bit reluctant to publish it without more evidence that
I don't generally like default things when the default is a completely
arbitrary choice, as is the case here. This is not like a default port
number.
If someone is having trouble configuring a database then he/she or someone
else should write a tool that tries to configure out the settings, not
d
On Mon, 30 Jan 2006, Ryan Thomas wrote:
> > I just took a look at the c-jdbc design and it seems that they have to
> > execute writes one at a time (one insert statement at a time) - because if
> > you start multiple write transaction at the same time then multiple sites
> > could execute the wri
On Fri, 27 Jan 2006, James Strachan wrote:
> > Is anybody working on Derby clustering?
>
> http://sequoia.continuent.org/HomePage
>
> its meant to be mostly ASF licensed now; though given its L/GPL
> heritage of C-JDBC I'd be a little cautious of the licensing
It says that is the "continuation"
I see that the DB section says "Any takers?". You want somebody to write
about clustering of databases which have built-in support, or tools like
C-JDBC?
Is anybody working on Derby clustering?
I would pick one type of clustering at a time, solve that problem, roll it
out, and then move on to the next one. And I would specifically address
each type of clustering requirement separately (e.g. http and entity
beans) because the best solution is different in each case.
On Fri, 27 Jan 2006,
Still, it doesn't seem like there is much interest in using totem. For
session replication you can use primary-backup, if anything.
On Sun, 22 Jan 2006, Geir Magnusson Jr wrote:
> Catching up :
>
> [EMAIL PROTECTED] wrote:
> >> No. You license the code to the Apache Software Foundation giving
>
On Thu, 19 Jan 2006, Dain Sundstrom wrote:
> On Jan 18, 2006, at 10:20 PM, lichtner wrote:
>
> > This state is transactional, I take it?
>
> Nope. For OpenEJB, only stateful session beans (SFSB) would use this api.
I see. I plan to never use them, if I can help it.
>
On Thu, 19 Jan 2006, Jules Gosnell wrote:
> > We should avoid making those decesions before hand.
What decisions does the user need to make?
Users need to make a lot of decisions already. Are the decisions you
mention worth the time it will take for users to make them?
> as far as clustering s
This state is transactional, I take it?
On Wed, 18 Jan 2006 [EMAIL PROTECTED] wrote:
>
> On 18 Jan 2006, at 18:10, lichtner wrote:
> > It looks like a map-like interface. When you say this could manage
> > state
> > for OpenEJB, what kind of state do you have in mind?
&
It looks like a map-like interface. When you say this could manage state
for OpenEJB, what kind of state do you have in mind?
On Wed, 18 Jan 2006, James Strachan wrote:
> I got chance to have a mini-hackathon with some geronimo committers
> over the weekend to hack up a real simple client API to
So where is this document now? I am not very familiar with the web site
there seems to be more than one place.
On Wed, 18 Jan 2006, Hernan Cunico wrote:
> Hi Jules,
> many of the articles (if not all) started the same way and many of them are
> still a work in progress.
>
> It would be great if
I am actually looking for another job/contract right now (in the San Diego
area, or I can telecommute), so I thought I would mention it in case
anybody knows of any openings.
Guglielmo
On Wed, 18 Jan 2006, Jules Gosnell wrote:
> I haven't been able to convince myself to take the quorum approach
> because...
>
> shared-something approach:
> - the shared something is a Single Point of Failure (SPoF) - although
> you could use an HA something.
It's not really a spof. You just fai
es up to 4 - R = 2
> node crashes.)
>
> Also I didn't understand how u arrived at the 4-R value. I guess it's bcos I
> don't have much knowledge about totem.
> If there is a short answer and if it's not beyond the scope of the thread
> can u try one more time t
On Tue, 17 Jan 2006, Rajith Attapattu wrote:
> Can u guys talk more about locking mechanisms pros and cons wrt in memory
> replication and storaged backed replication.
I don't know what you have in mind here by 'storage-backed'.
> Also what if a node goes down while the lock is aquirred?? I ass
On Tue, 17 Jan 2006, Jules Gosnell wrote:
> just when you thought that this thread would die :-)
I think Jeff Genender wanted a discussion to be sparked, and it worked.
> So, I am wondering how might I use e.g. a shared disc or majority voting
> in this situation ? In order to decide which fra
On Tue, 17 Jan 2006, Jules Gosnell wrote:
> >I believe that if you put some spare capacity in your cluster you will get
> >good availability. For example, if your minimum R is 2 and the normal
> >operating value is 4, when a node fails you will not be frantically doing
> >state transfer.
> >
> >
On Mon, 16 Jan 2006, Jules Gosnell wrote:
> >2. When an HTTP request arrives, if the cluster which received does not
> >have R copies then it blocks (it waits until there are.) This should in
> >data centers because partitions are likely to be very short-lived (aka
> >virtual partitions, which a
On Mon, 16 Jan 2006, Rajith Attapattu wrote:
> This is a very educating thread, maybe Jules can incoporate some of the
> ideas into your document on clustering.
Let's hope the thread also eventually translates into working code :)
> >1. The user should configure a minimum-degree-of-replication
On the subject of paritions, I remembered this paper I read a few years
ago which shows that paritions, whether caused by hardware failures or by
heavy traffic, are a fact of life:
"Understanding Partitions and the 'No Partition' Assumption"
A. Ricciard et al.
http://citeseer.ist.psu.edu/32449.h
On Mon, 16 Jan 2006, Jules Gosnell wrote:
> REMOVE_NODE is when a node leaves cleanly, FAILED_NODE when a node dies ...
I figured. I imagine that if I had to add this distinction to totem I
would add a message were the node in question announces that it is
leaving, and then stops forwarding the
ting the jvm rather than switching context and copying data
from the memory to itself.
I hope somebody with a budget picks this up soon.
Guglielmo
On Sun, 15 Jan 2006, James Strachan wrote:
> On 14 Jan 2006, at 22:27, lichtner wrote:
> > On Fri, 13 Jan 2006, James Strachan wrote:
> >
I support your idea. Making branches for new feature development is
a common practice.
Were you thinking of doing it for every single change request, or only for
big ones?
On Sun, 15 Jan 2006, Greg Wilkins wrote:
>
> I would like to create a dev branch to start working on some
> 1.1 and 2.0 stu
On Fri, 13 Jan 2006, James Strachan wrote:
> > The infiniband transport would be native code, so you could use JNI.
> > However, it would definitely be worth it.
>
> Agreed! I'd *love* a Java API to Infiniband! Have wanted one for ages
> & google every once in a while to see if one shows up :)
>
To me the only important requirements in release numbers are that they
should tell the user:
1. Whether the release is backward compatible.
2. Whether it's a stable build vs. unstable.
I would rather not to have to learn the various meanings of digits 1-N. It
seems like it would make it more tr
On Fri, 13 Jan 2006, James Strachan wrote:
> > The infiniband transport would be native code, so you could use JNI.
> > However, it would definitely be worth it.
>
> Agreed! I'd *love* a Java API to Infiniband! Have wanted one for ages
> & google every once in a while to see if one shows up :)
>
On Sat, 14 Jan 2006, David Jencks wrote:
> What would the reaction be to something
> that only sort of works in an official release?
IMHO all features all features in a production release should be usable.
It's not a problem if the functionality is limited, as long as it works.
As Jules requested I am looking at the AC api. I report my observations
below:
ClusterEvent appears to represent membership-related events. These you
can generate from evs4j, as follows: write an adapter that implements
evs4j.Listener. In the onConfiguration(..) method you get notified of
new con
On Fri, 13 Jan 2006, Alan D. Cabrera wrote:
> > The infiniband transport would be native code, so you could use JNI.
> > However, it would definitely be worth it.
>
> Do you have any references to the where one could get a peek at the
> transport API?
http://infiniband.sourceforge.net/
> Interesting. Can you suggest a protocol we should use for
> pessimistic distributed locking? I expect the cluster size to be
> between 2-16 nodes with the sweet spot at 4 nodes. Each node will
> be processing about 500-1000 tps and each tps will require on average
> about 1-4 lock requests (
With regard to clustering, I also want to mention a remote option, which
is to use infiniband RDMA for inter-node communication.
With an infiniband link between two machines you can copy a buffer
directly from the memory of one to the memory of the other, without
switching context. This means the
> > If you cluster an entity bean on two nodes naively, you lose many of the
> > benefits of caching. This is because neither node, at the beginning of a
> > transaction, knows whether the other node has changed the beans contents
> > since it was last loaded into cache, so the cache must be assum
> You could go one step further and send, not an invalidation, but a
> replication message. This would contain the Entity's new value and head
> off any reloading from the DB at all
>
> All of this needs to be properly integrated with e.g. transactions,
> locking etc...
>
> Perhaps Totem might
I will take a closer look at it. My first impression was that
activecluster assumes a jms or jms-like api as a transport.
> [EMAIL PROTECTED] wrote:
>
>>>Given the inherent over head in total order protocols, I think we
>>>should work to limit the messages passed over the protocol, to only
>>>the
> Its been talked about but currently not implemented.I'm catching up on the
> conversation and haven't looked at the pointers yet so I have a bit of
> reading
> to do.
>
> Are you thinking about using Totem to replicate Entity cache information
> in a cluster?
Yes.
You can take your pick of conc
> [EMAIL PROTECTED] wrote:
>> Well, you guys let me know if I can help you in any way.
>
> Keep on talking ;-)
Okay. I will ask you a question then. What are you doing as far caching
entity beans?
Well, you guys let me know if I can help you in any way.
> I think there is a time and place for this and can be leveraged in other
> protocols. As a minimum it can be a pluggable protocol. Its a great
> start.
>
> [EMAIL PROTECTED] wrote:
>>> Given the inherent over head in total order protoco
> Given the inherent over head in total order protocols, I think we
> should work to limit the messages passed over the protocol, to only
> the absolute minimum to make our cluster work reliably.
> Specifically, I think this is only the distributed lock. For state
> replication we can use a much m
> No. You license the code to the Apache Software Foundation giving
> the foundation the rights to relicense under any license (so the
> foundation can upgrade the license as they did with ASL2). We do ask
> that you change the copyrights on the version of the code you give to
> the ASF to someth
I didn't see it - I'm not sure why.
> According to the website (http://www.bway.net/~lichtner/evs4j.html):
>
> "Extended Virtual Synchrony for Java (EVS4J), an Apache-
> Licensed, pure-Java implementation of the fastest known totally
> ordered reliable mult
Over the phone Jeff asked me to start a discussion about the totem
protocol, so here it is.
If anyone just wants to get it from the horse's mouth you can read this
paper:
"The Totem Single-Ring Ordering and Membership Protocol",
Y. Amir, L. E. Moser, P. M. Melliar-Smith, D. A. Agarwal, and P. Ci
> Yes...awesome. Bruce had chatted with me about this too...I am very
> interested.
Thanks.
> Guglielmo, I would be very interested in speaking with you further on
> this.
I am available to speak more about it. If you need my phone number, it's
six one nine, two five five, nine seven eight six.
64 matches
Mail list logo
