Re: C++ client using boost
Awesome! Many thanks for the links; taking a look now James On 1/13/06, David Fahlander [EMAIL PROTECTED] wrote: According the design decision for the C++ client, I would recommend using the boost libraries for smart pointers and threads. See www.boost.org http://www.boost.org/ . Boost has become a well-know modern C++ base framework made with conformance to the C++ Standard Template Library. Most of the boost libraries use the boost license which is compatible with the BSD license. The purpose of boost libraries is to extend the standard C++ library with modern concepts such as thread programming, garbage collecting etc. There is also a socket implementation built on boost (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSock et). /David -- James --- http://radio.weblogs.com/0112098/
[Fwd: svn commit: r365799 - in /geronimo/trunk/configs: daytrader-jetty/project.xml daytrader-tomcat/project.xml]
Matt,
FYI.. this daytrader change has been merged to the 1.0 branch. Where
are you moving daytrader from (trunk or 1.0 branch)?
John
Original Message
Subject: svn commit: r365799 - in /geronimo/trunk/configs:
daytrader-jetty/project.xml daytrader-tomcat/project.xml
Date: Wed, 04 Jan 2006 02:07:04 -
From: [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: scm@geronimo.apache.org
Author: djencks
Date: Tue Jan 3 18:07:02 2006
New Revision: 365799
URL: http://svn.apache.org/viewcvs?rev=365799view=rev
Log:
fix missing dependencies noted by Henry Hwang
Modified:
geronimo/trunk/configs/daytrader-jetty/project.xml
geronimo/trunk/configs/daytrader-tomcat/project.xml
Modified: geronimo/trunk/configs/daytrader-jetty/project.xml
URL:
http://svn.apache.org/viewcvs/geronimo/trunk/configs/daytrader-jetty/project.xml?rev=365799r1=365798r2=365799view=diff
==
--- geronimo/trunk/configs/daytrader-jetty/project.xml (original)
+++ geronimo/trunk/configs/daytrader-jetty/project.xml Tue Jan 3 18:07:02 2006
@@ -73,7 +73,21 @@
groupIdgeronimo/groupId
artifactIddaytrader-ear/artifactId
version${pom.currentVersion}/version
-typeear/type
+typeear/type
+/dependency
+
+dependency
+groupIdactivemq/groupId
+artifactIdactivemq-ra/artifactId
+version${activemq_version}/version
+ typerar/type
+/dependency
+
+dependency
+groupIdtranql/groupId
+artifactIdtranql-connector-derby-embed-xa/artifactId
+version${tranql_vendors_version}/version
+typerar/type
/dependency
Modified: geronimo/trunk/configs/daytrader-tomcat/project.xml
URL:
http://svn.apache.org/viewcvs/geronimo/trunk/configs/daytrader-tomcat/project.xml?rev=365799r1=365798r2=365799view=diff
==
--- geronimo/trunk/configs/daytrader-tomcat/project.xml (original)
+++ geronimo/trunk/configs/daytrader-tomcat/project.xml Tue Jan 3 18:07:02 2006
@@ -75,7 +75,21 @@
groupIdgeronimo/groupId
artifactIddaytrader-ear/artifactId
version${pom.currentVersion}/version
-typeear/type
+typeear/type
+/dependency
+
+dependency
+groupIdactivemq/groupId
+artifactIdactivemq-ra/artifactId
+version${activemq_version}/version
+ typerar/type
+/dependency
+
+dependency
+groupIdtranql/groupId
+artifactIdtranql-connector-derby-embed-xa/artifactId
+version${tranql_vendors_version}/version
+typerar/type
/dependency
[jira] Created: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assigned to: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
OK, I am back. David Jencks wrote: I agree with Jeff that this change is unsatisfactory but I'm not as sure as he is that backing it out is necessary, perhaps we can move forward to an acceptable solution instead. I have to ask - on what grounds is it unsatisfactory ? If backing out is unecessary, how do you propose moving forwards, now that this has been done ? I also am not so sure that this magnitude of change needs prior discussion on the list. I've frequently made larger changes without discussion of my specific code. I've also broken lots of stuff at various times. Jeff has still to demostrate that something has been broken. Having two competing configuration mechanisms instead of three does not constitute 'breakage', but iteration towards one single mechanism. It may be that I have broken something. If this is the case, I would apologise and endevour to fix it immediately. One thing I insist on is that it be possible to run geronimo with no clustering support whatsoever, including no clustering classes anywhere in the geronimo system. I believe this means that each clustering system has to be installed as a configuration. Doing this right now as the first step will I think help focus the rest of the componentization. This involves splitting the Jetty and TC configs into local and clustered and associated refactoring. Ultimately this is where I would like to be aswell, but I think it unlikely to happen in time for 1.0.1. All I am trying to do is to get a Geronimo/Jetty/Tomcat/WADI solution, that has as little impact as possible, in place before 1.0.1. I don't understand the requirements very well, I hope for some answers: - do we need to support running more than one clustering system with a particular web container instance (e.g. JettyContainerImpl gbean instance)? I'm hoping no If we pursue the direction that has been discussed, then per-app and per-container configs will be possible. Per-container config will allow the container to specify a single default clustering solution, but apps would be free to override this with their own specific solution. IIUC we are installing clustering as a session manager. Perhaps I don't understand the code but it looks to me as if the jetty code at least is creating a new instance for each web app. I can't believe this is an acceptable strategy for all clustering implementations. For instance, I would think if you have a bunch of web apps doing cross-context dispatch you would want them all to share a session manager. I think we want the possibility of installing a single container wide session manager or per-app session managers. I believe that I also mentioned this in one of the discussion threads., but this requirement did not make it onto my mental roadmap for 1.0.1. Is it really plausible to rely on the distributable tag in the spec dd to turn on clustering? Presence of the distributable/ tag in the web.xml indicates the apps requirement to the container to be clustered. I would think a further tag in our plan should be needed. If the app did not override (via some future extension) the container's choice of clustering solution, then the container's default solution would be implemented. Here's what I propose: We define a SessionManagerFactory interface, and for each clustering technology provide an implementation as a gbean.You can get a local and a distributed session manager from this interface. The runtime configuration for the clustering includes this gbean. Each web app context gets a reference to this gbean and gets the appropriate session manager when it starts. The web app context knows if it is supposed to be local or distributed so it can ask for the right session manager. We have a deploy time configuration for each clustering technology also. This at least supplies the gbean reference to the runtime gbean, and can also install a runtime gbean in the configuration under construction. In this way the clustering technology can decide on whether one session manager is shared, a factory that always returns unconfigured new instances is needed, or if each web app needs a specially configured session manager. If this isn't clear, I'll be happy to try to clarify. No, it is quite clear - it is pretty close to a long-term suggestion which I made in conclusion to my 'geronimo-web.xml' thread: ...Perhaps a SessionManagerFactoryGBean could be used on a per-server basis to create individual SessionManagers (for each app) that can then share further server-wide resources ? I was simply trying to come up with a short-term solution to tide us over 1.0.1 before we sat down and went for the whole enchillada. Jules thanks david jencks On Jan 12, 2006, at 7:54 AM, Jeff Genender wrote: I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff Genender wrote: First off...lets get over this...DJ has a great thread open. I really don't want to continue this discussion as its wasting all of our time. Comments in line...and this is it for responding to this nonsense...time to move on...ok? Jeff, you cannot, on the one hand, accuse people of not discussing things with you and, on the other, dismiss their comments as nonsense. Jules Greg Wilkins wrote: Jeff Genender wrote: I am sorry Jules, I am -1 on the change and I stand firm on that. Jeff, I don't understand your total -1, nor the fact that you actually backed out the change before anybody could reply to your email. Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, am I to believe the same would have occurred here? If you think I should have waited a few days, then perhaps I could have. But based on past history with you guys and handling -1s, I don't think it was unreasonable for me to think that you weren't going to remove it. Its now a full week (1/5-1/12) after the -1, and it has not been removed. How long is a reasonable time to wait for you to back out -1s? I sat in the room with Jules and Jan for three days while they worked on this. They certainly were discussing all the threads about this and they tried several times for a more minimal solution (name spaces etc.) but nothing else proved workable. That, in and of itself is the problem Greg. Lets bring this out on the lists, not in a room with Jules, Jan, and yourself. Jules said, Jan and Greg are staying with me for a few days, starting monday. We will go through the integration together and keep the list up to date with any issues that we find. He never brought the discussion as he stated, and then followed it up today (1/12) with: Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's trunk. Where was the list up to date on discussion of what you have found, relative to the requests we made previously on the lists about what we want to see in the integration? Am I missing something here? So they moved one aspect of the config out of the WEB-INF and as a result they were able to get a webapp deployed on a mixed cluster of geronimo-jetty and geronimo-tomcat - HOORAY! Great...lets chat about it...I am all for open discussion on this! Lets see what they came up with...and work with the ideas into something that is a good solution for the team and community! But I wouldn't say the change (one aspect) was that simple from an impact perspective, Greg. They deserve thanks for a good achievement and some peer review to help them improve it. The certainly don't deserve unilateral action to erase their work and send every body back to square -1. Peer review? And where did that occur? See the above comments about Jules working with you on this, then checking it all in. I saw no peer review. Remember, this is an Apache project (Geronimo)...you should be sharing info with the community. Nobody said it wasn't a valiant attempt, nor that the intentions weren't good. Based on the Axion issues, one of my -1s has nothing to do with intentions, it has to do with putting the database hard coded dependency in the container. That is a serious architectural flaw. I -1'd that on the Jetty side as well. If you needed to try things out...and get a review afterwards, why didn't you just cut a quick branch and show off your changes? Nobody would have -1d that. I agree with David that the session manager configuration should be moved again to a clustering GBean, but that does not mean that we should move it back to WEB-INF while we wait for a better solution. This was a minimal solution that can be put in place in time for 1.0.1. We don't have time to create a clustering module before then. Greg, I think the point here is we all need to discuss this before doing this. The Apache way, remember? If you all discussed this openly, perhaps the config could be built by now, yes? As for the axion dependancy, I do believe this is a container dependancy. Axion is being used to persist the session - which is a web container function, not a webapp function. We had discussed this and I thought you had agreed with me on this point - that we should not have to put WADI dependancies into WEB-INF/lib of the apps so they can be clustered. Greg, that is a complete fabrication of the truth. I am sorry Greg, I never agreed with Axion being in the container. I did agree with the ability to inject the clustering as a pluggable configuration at the container or context level. That is as far as I agreed. If we need a connector (READ: RAR) to be used for the database, then this is fine...its a pluggable component. But as a hard code,
Re: Javamail address parsing (again).
Dain Sundstrom wrote: On Jan 12, 2006, at 3:24 PM, Rick McGuire wrote: Dain Sundstrom wrote: On Jan 11, 2006, at 1:17 PM, Bruce Snyder wrote: Is it possible to look at the Sun implementation's source code to distinguish enforced vs. ignored rules? That would make the code not clean room. I propose we ask Sun for a formal definition of the parser for this class, and in a parallel track make an effort to try to match their bugs. The code from the second track doesn't have to be perfect, but just good enough. We simply let our users know that our goal with the implement.sun.javamail.bugs=true code is to emulate the sun bugs, and if they find something that produces different results for the same text, we consider it a bug. I'm becoming less and less convinced this is a good idea. So far, I've found many, many sun bugs in this code where they produce results that are in conflict with with RFC822. The API documentation refers relaxed parsing rules, which says to me there are addresses that would not be valid under RFC822, but javamail will accept them based on the type of parsing requested. I can accept that. However, the great majority of the problems I've found have been involved with internet addresses that RFC822 says ARE valid, but the javamail code does not handle them properly. And there are a few situations where it appears the authors just chose to punt and say yeah, whatever. It appears that the solution is to write hacked code that mostly, sorta, kinda does what it claims to do, or write a good parser, then triple the size of the code trying to get all of the Sun bugs to work properly. Working strictly from the RFC822 spec, I had a fairly nice parser written that gave very good RFC822 compliance, but things turned nightmarish when I discovered the sorts of Sun behaviors I had to insert back in. I think I've completely rewritten this code about 5 times now, and am getting pretty close to the Sun relaxed rules. Inserting some of the real bugs back in to the parsing might pose similar problems. It really appears that this code somewhat lost it's way somewhere. It's serving two purposes that are really at odds with each other. The first purpose, is to parse any internet address that might appear in a received message. For that purpose, the code needs to accept any valid internet address as defined by RFC822. The Sun code does not currently do that, and making the new version bug compatible would also not achieve that. The other purpose of the InternetAddress parser is to process email addresses entered into applications and perform some validation on the addresses. This is where the relaxed rules come in to play, and basically allows internet addresses that are not strictly RFC822 compatible to pass. Now for those, I'm relatively comfortable that this can be made compatible. It is very difficult though, when the requirement becomes one of being both more and less restrictive at the same time, with no good definition of the what rules are being used. Ok, how about we say, in sun bug mode we will parse all addresses that are valid RFC822 address or are sucessfull parsed by sun's javamail implementation? This means that valid RFC822 addresses that sun's implementation rejects will be accepted by ours. We would further would consider it a bug to reject addresses accepted by sun's implementation when in sun bug mode. That sounds like a more reasonable goal. -dain
Re: Replication using totem protocol
[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 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 more efficient tcp or udp based protocol. As I said, if your workload has low data sharing (e.g. session replication), you should not use totem. It's designed for systems where _each_ processor needs _most_ of the messages. Geronimo has a number of replication usecases (I'll be enumerating them in a document that I am putting together at the moment) Totem may well suit some of these. If we were to look seriously at using it, I think the first technical consideration would be API. Geronimo already has ActiveCluster (AC) in the incubator and WADI (An HttpSession and SFSB clustering solution is built on AC). AC is both an API to basic clustering fn-ality and a number of pluggable impls. My suggestion would be that we look at how we could map Totem to the AC API. Do Totem and AC (http://activecluster.codehaus.org/) look like a good match ? Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Re: Replication using totem protocol
inline at end... Dain Sundstrom wrote: On Jan 12, 2006, at 12:28 PM, [EMAIL PROTECTED] wrote: 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 multicast protocol. Yes, I wrote that. Once you have a total ordered messing protocol, implementing a distributed lock is trivial (I can go into detail if you want). Yes. You just send a totally-ordered message and wait for it to arrive. I suggest we ask Guglielmo if he would like to donate his implementation to this incubator project I don't know about donating it. Who would they want me to transfer the copyright to? 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 something like Copyright 2004 The Apache Software Foundation or its licensors, as applicable. and if he would like to work on a pessimistic distributed locking implementation. What do you think? I would definitely like to work on it, but I still work for a living, so that's something to think about. (I happen to be between jobs right now.) Nothing better to do between jobs than coding :) Also, what do you need to locks for? Locking web sessions and stateful session beans in the cluster when a node is working on it. Dain, I see where you are coming from and it looks interesting. Virtual synchrony might well be useful in terms of guaranteeing lock-ordering etc., although at first glance, I have reservations about the scalability of multicast - but I need to read up on Totem... I'll give Totem a mention it in the clustering doc that I am putting together. Jules -dain -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
Re: Replication using totem protocol
[EMAIL PROTECTED] wrote: [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? In terms or replication or some form of distributed invalidation, I'm not aware that this has been discussed yet. This is another one for the forthcoming doc - briefly : 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 assumed invalid. Thus, you find yourself going to the db much more frequently than you would like, and the number of trips increases linearly with the number of clients - i.e. you are no longer scalable. If you can arrange for the cache on one node to notify the cache on other nodes, whenever an entity is changed, then the other caches can optimise their actions, so that rather assuming that all beans are invalid, they can pinpoint the ones that actually are invalid and only reload those. 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 be useful here ? Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
[jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on
Re: Replication using totem protocol
further thoughts at bottom Jules Gosnell wrote: [EMAIL PROTECTED] wrote: [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? In terms or replication or some form of distributed invalidation, I'm not aware that this has been discussed yet. This is another one for the forthcoming doc - briefly : 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 assumed invalid. Thus, you find yourself going to the db much more frequently than you would like, and the number of trips increases linearly with the number of clients - i.e. you are no longer scalable. If you can arrange for the cache on one node to notify the cache on other nodes, whenever an entity is changed, then the other caches can optimise their actions, so that rather assuming that all beans are invalid, they can pinpoint the ones that actually are invalid and only reload those. 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 be useful here ? ActiveSpace (in incubator) may already have support for this sort of thing ? If you had a working clustered cache with a cache loader pointing at the entity... Jules Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
[Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
Its been brought to my attention that to better align versions with server releases, the eclipse-plugin should be re-versioned for its initial release to be 1.0.0, not 0.5.0. The idea here being that any major releases of the server, will have a matching corresponding eclipse feature version. Minor versions may still need to be independently versioned. Having a plugin that packages some of the Geronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 is confusing to many users. We have a small time frame to decide if we do want to change the version immediately, as Eclipse-WTP is about to release their first maintenance release 1.0.1, and we agree upon this, I will need to inform them of this change so they can react ASAP. Our next opportunity to do this will may not be for another 1-2 months. [ ] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter - sachin
Re: http://wiki.apache.org/geronimo/EclipseDeployment changes needed
Thanks John. I forgot about this. I'll add this to my ToDo list. - sachin On Jan 13, 2006, at 1:42 AM, John Sisson wrote: We might want to have a few versions of the pre-configured eclipse launch configs (e.g. currently in http://people.apache.org/ ~sppatel/eclipselaunchconfigs.zip needs to be updated) for trunk, the 1.0 branch and for actual releases to simplify debugging for users. Even better would be to have the docs shipped with the release contain how to set up eclipse (since the wiki page will keep changing over time). Some things that I have noted that need to be changed * Source lookup path is missing a number of projects and has a number of non-existent projects on it * Classpath refers to geronimo\target\geronimo-1.0-SNAPSHOT\bin\ * Screenshots have geronimo-assembly in them (e.g. when configuring classpath). They should now have geronimo-tomcat-j2ee or geronimo- jetty-j2ee in them. * Specify --long as a program argument John
[jira] Commented: (GERONIMO-1371) ActiveMQ SQL Exception logged during shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-1371?page=comments#action_12362635 ] John Sisson commented on GERONIMO-1371: --- The SQL Exception seems to be caused by the Derby System being shutdown. System Thread [RMI TCP Connection(8)-192.168.0.21] (Suspended (breakpoint at line 737 in java.lang.System)) java.lang.System.gc() line: 737 org.apache.geronimo.derby.DerbySystemGBean.doStop() line: 77 org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(boolean) line: 1079 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop() line: 395 org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop() line: 200 org.apache.geronimo.gbean.runtime.GBeanInstance.stop() line: 545 org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(javax.management.ObjectName) line: 213 org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop() line: 192 org.apache.geronimo.gbean.runtime.GBeanInstance.stop() line: 545 org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(javax.management.ObjectName) line: 213 org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop() line: 192 org.apache.geronimo.gbean.runtime.GBeanInstance.stop() line: 545 org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(javax.management.ObjectName) line: 213 org.apache.geronimo.kernel.config.ConfigurationManagerImpl$ShutdownHook.run() line: 287 org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks() line: 406 org.apache.geronimo.kernel.basic.BasicKernel.shutdown() line: 383 org.apache.geronimo.kernel.KernelGBean.shutdown() line: 157 org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(int, java.lang.Object, java.lang.Object[]) line: not available SNIP Thread [Checkpoint Worker] (Suspended (breakpoint at line 79 in org.apache.geronimo.connector.outbound.GeronimoConnectionEventListener)) org.apache.geronimo.connector.outbound.GeronimoConnectionEventListener.connectionErrorOccurred(javax.resource.spi.ConnectionEvent) line: 79 org.tranql.connector.jdbc.ManagedXAConnection(org.tranql.connector.AbstractManagedConnection).unfilteredConnectionError(java.lang.Exception) line: 119 org.tranql.connector.jdbc.ManagedXAConnection.access$000(org.tranql.connector.jdbc.ManagedXAConnection, java.lang.Exception) line: 44 org.tranql.connector.jdbc.ManagedXAConnection$1.connectionErrorOccurred(javax.sql.ConnectionEvent) line: 65 org.apache.derby.jdbc.EmbedXAConnection(org.apache.derby.jdbc.EmbedPooledConnection).notifyError(java.sql.SQLException) line: not available org.apache.derby.jdbc.EmbedXAConnection(org.apache.derby.jdbc.EmbedPooledConnection).notifyException(java.sql.SQLException) line: not available org.apache.derby.iapi.jdbc.BrokeredConnection30(org.apache.derby.iapi.jdbc.BrokeredConnection).notifyException(java.sql.SQLException) line: not available org.apache.derby.iapi.jdbc.BrokeredConnection30(org.apache.derby.iapi.jdbc.BrokeredConnection).setAutoCommit(boolean) line: not available org.tranql.connector.jdbc.ManagedXAConnection.localTransactionStart(boolean) line: 89 org.tranql.connector.AbstractManagedConnection$LocalTransactionImpl.begin() line: 188 org.tranql.connector.jdbc.ConnectionHandle.setAutoCommit(boolean) line: 161 org.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransaction() line: 126 org.activemq.store.jdbc.JDBCPersistenceAdapterGBean.beginTransaction() line: 76 org.activemq.store.jdbc.JDBCPersistenceAdapterGBean$$FastClassByCGLIB$$8be8a0a0.invoke(int, java.lang.Object, java.lang.Object[]) line: not available net.sf.cglib.reflect.FastMethod.invoke(java.lang.Object, java.lang.Object[]) line: 53 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(java.lang.Object, java.lang.Object[]) line: 38 org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(java.lang.Object, java.lang.Object[]) line: 118 org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(int, java.lang.Object[]) line: 800 org.apache.geronimo.gbean.runtime.RawInvoker.invoke(int, java.lang.Object[]) line: 57 org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(javax.management.ObjectName, java.lang.Object[]) line: 36 org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(java.lang.Object, java.lang.reflect.Method, java.lang.Object[], net.sf.cglib.proxy.MethodProxy) line: 96 org.activemq.store.PersistenceAdapter$$EnhancerByCGLIB$$6ea4ad31.beginTransaction() line: not available org.activemq.store.journal.JournalPersistenceAdapter.beginTransaction() line: 158 org.activemq.util.TransactionTemplate.run(org.activemq.util.Callback) line: 38
Re: Replication using totem protocol
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 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 more efficient tcp or udp based protocol. As I said, if your workload has low data sharing (e.g. session replication), you should not use totem. It's designed for systems where _each_ processor needs _most_ of the messages. Geronimo has a number of replication usecases (I'll be enumerating them in a document that I am putting together at the moment) Totem may well suit some of these. If we were to look seriously at using it, I think the first technical consideration would be API. Geronimo already has ActiveCluster (AC) in the incubator and WADI (An HttpSession and SFSB clustering solution is built on AC). AC is both an API to basic clustering fn-ality and a number of pluggable impls. My suggestion would be that we look at how we could map Totem to the AC API. Do Totem and AC (http://activecluster.codehaus.org/) look like a good match ? Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
[jira] Commented: (GERONIMO-1349) Missing Ports in Startup Port List
[ http://issues.apache.org/jira/browse/GERONIMO-1349?page=comments#action_12362639 ] Aaron Mulder commented on GERONIMO-1349: Are we saying that the JMX connector is listening on an arbitrary port? That would be really bad, as it sounds like it would mean you can't configure a firewall to allow remote management! Missing Ports in Startup Port List -- Key: GERONIMO-1349 URL: http://issues.apache.org/jira/browse/GERONIMO-1349 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0-M5, 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Fix For: 1.1, 1.0.1 The port list for Geronimo is: Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 0.0.0.0 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 61616 0.0.0.0 ActiveMQ Message Broker Connector The port list from netstat is: tcp0 0 :::1099 :::*LISTEN 8447/java tcp0 0 :::1389 :::*LISTEN 8447/java tcp0 0 :::1527 :::*LISTEN 8447/java tcp0 0 :::4201 :::*LISTEN 8447/java tcp0 0 :::4242 :::*LISTEN 8447/java tcp0 0 127.0.0.1:8019 :::*LISTEN 8447/java tcp0 0 :::8080 :::*LISTEN 8447/java tcp0 0 :::8443 :::*LISTEN 8447/java tcp0 0 :::16321:::*LISTEN 8447/java tcp0 0 :::61616:::*LISTEN 8447/java The differences are: 1389 -- Directory variable -- 16321 (16333 on next run) -- what is this?? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun
[jira] Commented: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=comments#action_12362640 ] Aaron Mulder commented on GERONIMO-1422: I saw this issue on my Mac Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
Huh??? Aaron has a Mac??? ;-) Aaron Mulder wrote: I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
/me blows coffee all over his keyboard Jeff Genender wrote, On 1/13/2006 5:52 AM: Huh??? Aaron has a Mac??? ;-) Aaron Mulder wrote: I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun
[jira] Created: (GERONIMO-1467) DB pool portlet error when web session saved
DB pool portlet error when web session saved Key: GERONIMO-1467 URL: http://issues.apache.org/jira/browse/GERONIMO-1467 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted sessions: j ava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
Duh -- I've had a G5 for ages. I still use a ThinkPad as a laptop, but I've pretty much switched from Linux to Mac on the desktop. Unfortunately, both the initial ThinkPad T60 and the initial MacBook Pro have their little drawbacks... I'm hoping February will bring some developments... :) Aaron On 1/13/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: /me blows coffee all over his keyboard Jeff Genender wrote, On 1/13/2006 5:52 AM: Huh??? Aaron has a Mac??? ;-) Aaron Mulder wrote: I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL:
Re: Replication using totem protocol
On 1/13/06, Jules Gosnell [EMAIL PROTECTED] wrote: Perhaps Totem might be useful here ?ActiveSpace (in incubator) may already have support for this sort of thing ?If you had a working clustered cache with a cache loader pointing at theentity... Yes, ActiveSpace currently has a distributed JCache using optimistic transactions which relies on total ordering; it could well be a good use case for using totem. I'd be interested in a performance comparison with Totem v ActiveMQ (indeed it'd be trivial to integrate Totem into ActiveMQ as a transport; we already have multicast, UDP, TCP, SSL, HTTP et al). FWIW when I get chance I've been meaning to refactor the ActiveSpace code to make use of Spring Remoting / Lingo (probably moving it into the Lingo project) so it'd be much easier to decouple the remoting code easily. -- James---http://radio.weblogs.com/0112098/
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
As a frequent user of enterprise application development tooling I can attest to the fact that discrepancies between the version numbers in the tool/plugin and the application server it is compatible with or embeds can lead to confusion and lost productivity. So I would definitely vote in favor of keeping the version numbers aligned as closely as possible. [x] Re-version the initial release to 1.0.0 Best wishes, Paul On 1/13/06, Sachin Patel [EMAIL PROTECTED] wrote: Its been brought to my attention that to better align versions withserver releases, the eclipse-plugin should be re-versioned for itsinitial release to be 1.0.0, not 0.5.0.The idea here being that anymajor releases of the server, will have a matching corresponding eclipse feature version.Minor versions may still need to beindependently versioned.Having a plugin that packages some of theGeronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 isconfusing to many users. We have a small time frame to decide if we do want to change theversion immediately, as Eclipse-WTP is about to release their firstmaintenance release 1.0.1, and we agree upon this, I will need toinform them of this change so they can react ASAP.Our next opportunity to do this will may not be for another 1-2 months.[ ] Re-version the initial release to 1.0.0[ ] Leave it at 0.5.0[ ] Doesn't matter- sachin
Re: Replication using totem protocol
On 1/13/06, Jules Gosnell [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote:[EMAIL PROTECTED] wrote:Okay. I will ask you a question then. What are you doing as far caching entity beans?In terms or replication or some form of distributed invalidation, I'mnot aware that this has been discussed yet.This is another one for the forthcoming doc - briefly : If you cluster an entity bean on two nodes naively, you lose many of thebenefits of caching. This is because neither node, at the beginning of atransaction, knows whether the other node has changed the beans contents since it was last loaded into cache, so the cache must be assumedinvalid. Thus, you find yourself going to the db much more frequentlythan you would like, and the number of trips increases linearly with the number of clients - i.e. you are no longer scalable.It depends on your transaction isolation level; i.e. do you want to do a dirty read or not. You should be able to enable dirty reads to get scalability performance. The only way to really and truly know if the cache is up to date is to use a pessimistic read lock; but thats what databases are great for - so you might as well use the DB and not the cache in those circumstances. i.e. you always use caches for dirty readsIf you can arrange for the cache on one node to notify the cache on other nodes, whenever an entity is changed, then the other caches canoptimise their actions, so that rather assuming that all beans areinvalid, they can pinpoint the ones that actually are invalid and only reload those.You could go one step further and send, not an invalidation, but areplication message. This would contain the Entity's new value and headoff any reloading from the DB at all The two main strategies here are* invalidation; as each entity changes it sends an invalidation message - which is really simple doesn't need total ordering, just something lightweight fast. (Actually pure multicast is fine for invalidation stuff since messages are tiny reliability is not that big a deal, particularly if coupled with a cache timeout/reload policy). * broadcasting the new data to interested parties (say everyone else in the cluster). This typically requires either (i) a global publisher (maybe listening to the DB transaction log) or (ii) total ordering if each entity bean server sends its changes. The former is good for very high update rates or very sparse caches, the latter is good when everyone interested in the cluster needs to cache mostly the same stuff the cache size is sufficient that most nodes have all the same data in their cache. The former is more lightweight and simpler a good first step :) James-- James---http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-1467) DB pool portlet error when web session saved
[ http://issues.apache.org/jira/browse/GERONIMO-1467?page=all ] Aaron Mulder updated GERONIMO-1467: --- Description: 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted sessions: j ava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) Also later in the e-mail thread: java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderEdit(DatabasePoolPortlet.java:686) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:619) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) was: 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted sessions: j ava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) DB pool portlet error when web session saved Key: GERONIMO-1467 URL: http://issues.apache.org/jira/browse/GERONIMO-1467 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted sessions: j ava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) Also later in the e-mail thread: java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderEdit(DatabasePoolPortlet.java:686) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:619) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff, Can you please calm down? I'm trying to discuss your concerns, but you appear to be taking offence that I'm doing so? These are not my changes - I'm just an interested observer on this one trying to interpret the arguments that have been put forward! Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, Your concern was address. Jan removed the dependency and put the jar back into the webapp. But that was for a per webapp clustering solution. It has generally been discussed an agreed to move towards a per container clustering configuration. As for Axion being used to persist the session and is a container dependency, I disagree...lets look at where axion is being used in WADI: As far as I understand it, axion is used to persist the session. There has been plenty of discussion about this and if it is appropriate or not. At the very least WADI should probably be changed to use derby which is now used by geronimo. But as of today, axion is a dependency of WADI and we want WADI to be a container rather than a webapp service. If what you say is true - that it is not a dependency, then just remove the dependency 9rather than everything) and it should work! I think you will find that wadi does not work without it. The hard code of the wadi manager... It is not hard coded. It is just a reasonable default value and it is loosely coupled as it is just a class name.The commit removed a real hard dependency on WADIGBean so the change is less coupled to wadi! the Axion dependency, Discussed to death. You initial -1 was address when we went back to a per-app config. It is a container dependency and so it has been moved. Now you may argue that WADI could use persistence services in a better way - but that is an issue for WADI not geronimo. lack of pluggable configuration, The configuration is pluggable. Only the default is hard coded. lack of ability to set Clustering options (properties) at the clustering component level. Yes we all agree that a clustering GBean is needed for configuration. It will be the place to have lots of clustering options configured. If you think you can get this done by 1.0.1 - then great! you can then take the session managers config out of the container plans. I think we have been through this. Lets stop this nonsense and move forward on an open discussion with David Jencks' thread. I think if we can concentrate on the positive aspects, we can get this properly going. I don't understand. David commented in this thread? The issues and suggestions he raised are being discussed? Lets move on guys...we all should be moving forward here and stop dwelling on this. I'm sorry Jeff, but just because you have -1'd a commit does not mean that the discussion is over and that these changes will never go in. Unless it is understood why you did your -1, then how is anybody going to proceed. Alternately, you could post some proposals or code of your own as to how to fix the change or how to achieve the results some other way? And finally again - I just don't understand your tone and why you are so worked up - its just configuration for -sake?
JMS Clustering in Geronimo v1
I'm wondering what claims *Geronimo v1* can make concerning JMS clustering. I do see that ActiveMQ makes quite a few claims around clustering though am wondering exactly which capabilities are leveraged/relevant to Geronimo v1? Clustering/failover of message brokers? If so, where is this setup and where is the failover decision making done? Queue Consumer Clusters? Message Failover? Other? Do the messaging applications require any awareness of the clustered environment or is it transparent? Has anyone tested any of these scenarios using Geronimo v1? :) Thanks -Dave-
[jira] Commented: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=comments#action_12362648 ] Kevan Miller commented on GERONIMO-1422: I've also seen these messages on my Mac (but server still stopped). This reconnect problem looks pretty basic. It seems that the server has shutdown, but the client is trying to reconnect. Geonimo is trying to shutdown the client, but an ActiveMQ bug is preventing this. reconnect() is synchronized and is using Thread.sleep() to wait for some interval before retrying to reconnect (that's a pretty bad idea). This is preventing any other synchronized methods on the ActiveMQAsfEndpointWorker from running. Note that there is a Geronimo shutdown thread which is waiting to call ActiveMQAsfEndpointWorker.close() in the stack traces which John collected. Using Thread.wait() and appropriate state coordination between reconnect() and close() would seem to clear up this problem. I can generate a patch, if need be... Once the reconnect() lockout problem is fixed, I think we'll notice another problem... The geronimo.log posted to http://issues.apache.org/jira/browse/GERONIMO-1372 shows evidence of infinite loop in ActiveMQ shutdown processing. The log entry from the 1372 log is excerpted below: 17:30:34,325 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write to the stream any more it has already been closed javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write to the stream any more it has already been closed at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:483) at org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) at org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) at org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) at org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) at org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) at org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) at org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) at org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) at org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) at org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) at org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) at org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) at org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) at org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) at org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) at org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) at org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) at org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) at org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) at org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) at org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) at org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) at org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) at org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) ... (you get the picture) at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) at org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) at
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Jeff, I really can't understand your -1, let alone the backing out of the changes, nor all of the hullabaloo. It is quite straightforward: in 1.0 WADI did not work in Tomcat nor Jetty. Unfortunate and disappointing, but true. Period. We have made minimal changes to make it work in the 1.0.1 bug-fix release, and started to move us toward a container-based configuration solution (which all of us agree on) instead of a per-webapp configuration solution (which all of us agree is not desirable). So we are actually all in agreement! There is much more work to be done on the architecture as we all know, but that is something for a 1.1 release, not another rushed solution for the 1.0.1 bugfix release (and rushing is what caused us both to miss the 1.0 deadline). I really feel you have attacked me inappropriately and quite wrongly over this Axion jar issue. You said: Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and it was never tended too, am I to believe the same would have occurred here? If you think I should have waited a few days, then perhaps I could have. But based on past history with you guys and handling -1s, I don't think it was unreasonable for me to think that you weren't going to remove it. Its now a full week (1/5-1/12) after the -1, and it has not been removed. How long is a reasonable time to wait for you to back out -1s? If you check the SVN log you will find this: r366693 | janb | 2006-01-07 09:19:14 +0100 (Sat, 07 Jan 2006) | 2 lines removing axion and special activemq wadi versions and therefore jgenenders' codehaus repository from repo list I did this shortly after I replied to your email of 6th January. Here is what I said to you: Jeff, Thanks for that, I will remove the unnecessary ones. I wasn't sure whether the activemq WADI version was needed or not, so thanks for clarifying that. I will fix up Geronimo tomorrow. cheers Jan And I did exactly just that - removed Axion (and the WADI-3.2 of activemq). So can we just leave the accusations aside, put the code back in place, and get on with working together to ensure the code works and addresses all immediate concerns, or otherwise we will miss the 1.0.1 deadline too. sincerely, Jan I sat in the room with Jules and Jan for three days while they worked on this. They certainly were discussing all the threads about this and they tried several times for a more minimal solution (name spaces etc.) but nothing else proved workable. That, in and of itself is the problem Greg. Lets bring this out on the lists, not in a room with Jules, Jan, and yourself. Jules said, Jan and Greg are staying with me for a few days, starting monday. We will go through the integration together and keep the list up to date with any issues that we find. He never brought the discussion as he stated, and then followed it up today (1/12) with: Jan and I have just refactored the Geronimo Jetty and Tomcat integrations to take the same approach to the installation of a 3rd party session manager, to ease the integration of WADI. This is now checked in on Geronimo's trunk. Where was the list up to date on discussion of what you have found, relative to the requests we made previously on the lists about what we want to see in the integration? Am I missing something here? So they moved one aspect of the config out of the WEB-INF and as a result they were able to get a webapp deployed on a mixed cluster of geronimo-jetty and geronimo-tomcat - HOORAY! Great...lets chat about it...I am all for open discussion on this! Lets see what they came up with...and work with the ideas into something that is a good solution for the team and community! But I wouldn't say the change (one aspect) was that simple from an impact perspective, Greg. They deserve thanks for a good achievement and some peer review to help them improve it. The certainly don't deserve unilateral action to erase their work and send every body back to square -1. Peer review? And where did that occur? See the above comments about Jules working with you on this, then checking it all in. I saw no peer review. Remember, this is an Apache project (Geronimo)...you should be sharing info with the community. Nobody said it wasn't a valiant attempt, nor that the intentions weren't good. Based on the Axion issues, one of my -1s has nothing to do with intentions, it has to do with putting the database hard coded dependency in the container. That is a serious architectural flaw. I -1'd that on the Jetty side as well. If you needed to try things out...and get a review afterwards, why didn't you just cut a quick branch and show off your changes? Nobody would have -1d that. I agree with David that the session manager configuration should be moved again to a clustering GBean, but that does not mean that we should move it back to WEB-INF while we wait for a better solution. This was a minimal solution that can be put in place
[jira] Resolved: (GERONIMO-1442) Confluence JBoss-Geronimo guide gives invalid deployment plan
[ http://issues.apache.org/jira/browse/GERONIMO-1442?page=all ] Hernan Cunico resolved GERONIMO-1442: - Fix Version: 1.0 (was: 1.0.1) Resolution: Fixed JBoss to Geronimo - JDBC Migration documentation has been updated. http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=937 The remaining migration articles are being reviewed. Confluence JBoss-Geronimo guide gives invalid deployment plan -- Key: GERONIMO-1442 URL: http://issues.apache.org/jira/browse/GERONIMO-1442 Project: Geronimo Type: Bug Components: documentation Versions: 1.0 Reporter: Aaron Mulder Assignee: Hernan Cunico Fix For: 1.0 Note that the plan in the bug report below is from the Confluence documentation and is not valid for Geronimo 1.0. The documentation needs to be corrected. Hi All I try to configure resource with tutorial list http://opensource2.atlassian.com/confluence/oss/pages/viewpage.action?pageId=937 When I deploy the connection pool I got errors below - D:\geronimo-1.0java -jar bin/deployer.jar --user system --password manager deploy D:\geronimo-1.0\repository\mysql\jars\mysql-geronimo-plan.xml D:\geronimo-1.0\repository\tranql\rars\tranql-connector-1.1.rar Error: Unable to distribute tranql-connector-1.1.rar: Unable to load first parent of configuration org/apache/geronimo/Mysql No configuration with id: org/apache/geronimo/Server -- below is geronimo console msg -- 00:04:31,237 WARN [ConnectorPlanRectifier] Your connector plan has obsolete elements or attributes in it. Please remove version attributes, global-jndi-name elements, and credential-interface elements -- below is my mysql-geronimo-plan.xml -- ?xml version=1.0? connector xmlns=http://geronimo.apache.org/xml/ns/j2ee/connector; version=1.5 configId=org/apache/geronimo/Mysql parentId=org/apache/geronimo/Server dependency urimysql/jars/mysql-connector-java-3.1.7-bin.jar/uri /dependency resourceadapter outbound-resourceadapter connection-definition connectionfactory-interface javax.sql.DataSource /connectionfactory-interface connectiondefinition-instance nameMySQLDataSource/name config-property-setting name=UserName test /config-property-setting config-property-setting name=Password test /config-property-setting config-property-setting name=Driver com.mysql.jdbc.Driver /config-property-setting config-property-setting name=ConnectionURL jdbc:mysql://localhost:3306/appfuse /config-property-setting config-property-setting name=CommitBeforeAutocommit false /config-property-setting config-property-setting name=ExceptionSorterClass org.tranql.connector.NoExceptionsAreFatalSorter /config-property-setting connectionmanager local-transaction/ single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds 5000 /blocking-timeout-milliseconds idle-timeout-minutes 30 /idle-timeout-minutes match-one/ /single-pool /connectionmanager global-jndi-name jdbc/MySQLDataSource /global-jndi-name /connectiondefinition-instance /connection-definition /outbound-resourceadapter /resourceadapter /connector - -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1467) DB pool portlet error when web session saved
[ http://issues.apache.org/jira/browse/GERONIMO-1467?page=comments#action_12362655 ] Paul McMahan commented on GERONIMO-1467: Aaron, I see the same NullPointerException (but not the serialization exception) if I place a jar into my geronimo repository that doesn't follow the name-version.jar naming convention. For example, I saw the error when I created GERONIMO/repository/test/jars/foo.jar.Renaming to GERONIMO/repository/test/jars/foo-1.0.jar made the problem go away. DB pool portlet error when web session saved Key: GERONIMO-1467 URL: http://issues.apache.org/jira/browse/GERONIMO-1467 Project: Geronimo Type: Bug Components: console Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1, 1.0.1 09:51:16,405 ERROR [ManagerBase] IOException while loading persisted sessions: j ava.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException : org.apache.geronimo.console.databasemanager.wizard.ImportStatus$PoolProgress at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1278) Also later in the e-mail thread: java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderEdit(DatabasePoolPortlet.java:686) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:619) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1468) FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry
FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry --- Key: GERONIMO-1468 URL: http://issues.apache.org/jira/browse/GERONIMO-1468 Project: Geronimo Type: Bug Reporter: Kristian Koehler Hi if the local repository under geronimo_home/repository contains files with malformed filenames the method listURIs returns a wrong array which crashes the AdminConsole with a NPE. This happens when in several places (e.g. Common Libraries, Database Pools). The attached patch fixes this issue. Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1468) FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry
[ http://issues.apache.org/jira/browse/GERONIMO-1468?page=all ] Kristian Koehler updated GERONIMO-1468: --- Attachment: FileSystemRepository.patch FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry --- Key: GERONIMO-1468 URL: http://issues.apache.org/jira/browse/GERONIMO-1468 Project: Geronimo Type: Bug Reporter: Kristian Koehler Attachments: FileSystemRepository.patch Hi if the local repository under geronimo_home/repository contains files with malformed filenames the method listURIs returns a wrong array which crashes the AdminConsole with a NPE. This happens when in several places (e.g. Common Libraries, Database Pools). The attached patch fixes this issue. Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1468) FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry
[ http://issues.apache.org/jira/browse/GERONIMO-1468?page=all ] Aaron Mulder updated GERONIMO-1468: --- Component: console core Fix Version: 1.0.1 1.1 Version: 1.0 FileSystemRepository#listUris() produces wrong URI array when the repository contains a malformed entry --- Key: GERONIMO-1468 URL: http://issues.apache.org/jira/browse/GERONIMO-1468 Project: Geronimo Type: Bug Components: console, core Versions: 1.0 Reporter: Kristian Koehler Fix For: 1.0.1, 1.1 Attachments: FileSystemRepository.patch Hi if the local repository under geronimo_home/repository contains files with malformed filenames the method listURIs returns a wrong array which crashes the AdminConsole with a NPE. This happens when in several places (e.g. Common Libraries, Database Pools). The attached patch fixes this issue. Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
Aaron, this may not be the same issue, but I came across something that might help whilst working on the WADI integrations... I figured that AMQ's shutdown hook was seeing the ctl-c and shutting down AMQ before Geronimo had actually had a chance to do so. AMQ's shutdown hook can be suppressed via adding '-Dactivemq.broker.disable-clean-shutdown=true' to your JAVA_OPTS before starting Geronimo. This fixed one of the issues that WADI threw up and might resolve your issue, or I may be barking up completely the wrong tree... Jules Aaron Mulder wrote: I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug
Re: JMS Clustering in Geronimo v1
I see one short criticalcommingon Geronimo at the moment is we haven't defined what can and what we have todo in terms of clustering. I am glad you started the thread on JMS clustering, so some of the questions will be addressed There is no documentation out there what has been done or needs to be done. Insteadof complainingI am planning to fill the gap with the help ofHernan, but would need help and input. We did disscuss some issues with HA-JNDI, there is lot of disscussions on Web clustering, but other than that there is no direction or disscussion. This will confuse a lot of the end-users. Clustering is pretty darn important in any production-level deployment and if we don't give a clear idea to the community about where we stand or atleast the fact that we have recognized where we need to work or some sort of RoadMap the endusers will be very confused about the whole issue. Regards, Rajith On 1/13/06, Dave Colasurdo [EMAIL PROTECTED] wrote: I'm wondering what claims *Geronimo v1* can make concerning JMSclustering.I do see that ActiveMQ makes quite a few claims around clustering though am wondering exactly which capabilities areleveraged/relevant to Geronimo v1?Clustering/failover of message brokers?If so, where is this setup and where is the failover decision making done? Queue Consumer Clusters?Message Failover?Other?Do the messaging applications require any awareness of the clusteredenvironment or is it transparent?Has anyone tested any of these scenarios using Geronimo v1?:) Thanks-Dave-
Re: JMS Clustering in Geronimo v1
My understanding is that ActiveMQ has full-featured clustering functionality. I am sure that James will elaborate. Jules Rajith Attapattu wrote: I see one short critical comming on Geronimo at the moment is we haven't defined what can and what we have to do in terms of clustering. I am glad you started the thread on JMS clustering, so some of the questions will be addressed There is no documentation out there what has been done or needs to be done. Instead of complaining I am planning to fill the gap with the help of Hernan, but would need help and input. We did disscuss some issues with HA-JNDI, there is lot of disscussions on Web clustering, but other than that there is no direction or disscussion. This will confuse a lot of the end-users. Clustering is pretty darn important in any production-level deployment and if we don't give a clear idea to the community about where we stand or atleast the fact that we have recognized where we need to work or some sort of RoadMap the endusers will be very confused about the whole issue. Regards, Rajith On 1/13/06, *Dave Colasurdo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm wondering what claims *Geronimo v1* can make concerning JMS clustering. I do see that ActiveMQ makes quite a few claims around clustering though am wondering exactly which capabilities are leveraged/relevant to Geronimo v1? Clustering/failover of message brokers? If so, where is this setup and where is the failover decision making done? Queue Consumer Clusters? Message Failover? Other? Do the messaging applications require any awareness of the clustered environment or is it transparent? Has anyone tested any of these scenarios using Geronimo v1? :) Thanks -Dave- -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
[jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
[ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] Paul McMahan updated GERONIMO-1422: --- Attachment: shutdown_rhel3.txt After following the recreate steps and pressing Ctrl-C I got a big honkin stack trace but the server shut down. Platform is redhat enterprise linux v3. See attachment shutdown_rhel3.txt Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds Key: GERONIMO-1422 URL: http://issues.apache.org/jira/browse/GERONIMO-1422 Project: Geronimo Type: Bug Components: ActiveMQ Versions: 1.0 Environment: Solaris 10 x86 under VMWare player 1.01 Java 1.4.2_10 tomcat build of geronimo Reporter: John Sisson Fix For: 1.0.1 Attachments: geronimo_shutdown_stdout.txt, shutdown.txt, shutdown_rhel3.txt Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose(TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket(AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
[X] Re-version the initial release to 1.0.0 Alignment of major releases will avoid confusion and the need for a compatibility matrix. Also, hopefully will eliminate an onslaught of questions as to which levels are compatible.. -Dave- Sachin Patel wrote: Its been brought to my attention that to better align versions with server releases, the eclipse-plugin should be re-versioned for its initial release to be 1.0.0, not 0.5.0. The idea here being that any major releases of the server, will have a matching corresponding eclipse feature version. Minor versions may still need to be independently versioned. Having a plugin that packages some of the Geronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 is confusing to many users. We have a small time frame to decide if we do want to change the version immediately, as Eclipse-WTP is about to release their first maintenance release 1.0.1, and we agree upon this, I will need to inform them of this change so they can react ASAP. Our next opportunity to do this will may not be for another 1-2 months. [ ] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter - sachin
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
On Jan 13, 2006, at 10:41 AM, Jules Gosnell wrote: Aaron, this may not be the same issue, but I came across something that might help whilst working on the WADI integrations... I figured that AMQ's shutdown hook was seeing the ctl-c and shutting down AMQ before Geronimo had actually had a chance to do so. AMQ's shutdown hook can be suppressed via adding '- Dactivemq.broker.disable-clean-shutdown=true' to your JAVA_OPTS before starting Geronimo. This fixed one of the issues that WADI threw up and might resolve your issue, or I may be barking up completely the wrong tree... Jules, That would make sense. Alternately, I'm not sure how internal Geronimo shutdown processing is ordered. So, it's also seems possible that Geronimo is shutting down the server, prior to the client. Although this work-around might fix our problem, I think ActiveMQ shutdown processing needs to be fixed... --kevan
A special case for Translating security-constraint Elements to WebResourcePermission
Hi all,I am working on integration Jetspeed 2 with Geronimo(Tomcat container). I have the following configuration in my j2 main web.xml.- security-constraint - web-resource-collection web-resource-nameLogin /web-resource-name url-pattern/login/redirector /url-pattern /web-resource-collection - auth-constraint role-name*/ role-name /auth-constraint/security-constraint But there is no role define in this web.xml.Should it have a WebResourcePermission(/login/redirector, GET,POST,PUT,DELETE,HEAD,OPTIONS,TRACE) to be added to unchecked policy statements? I think this special case is equals to A WebResourcePermission must be added to the unchecked policy statements for each distinct url-pattern occurring in the security-constraint elements that do not contain an auth-constraint. I did read jacc spec SRV. 3.1.3.1 and servlet 2.4 spec SRV.12.8 and found nothing about this case(correct me if I am wrong). When I run this configuration on Tomcat 5.5.12, everything is ok, Tomcat treat * as allRole even there is no role defined in web.xml and hasResourcePermission() always return true. But when I run this with Geronimo SVN head, it always return false. Any help would be appreciated!- Jian Liao
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
2006/1/13, Sachin Patel [EMAIL PROTECTED]: [X] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter Jacek
[jira] Commented: (GERONIMO-1194) Installer should only install packs(features) selected at install time
[
http://issues.apache.org/jira/browse/GERONIMO-1194?page=comments#action_12362670
]
erik daughtrey commented on GERONIMO-1194:
--
Installer Dev Notes
* Built with IzPack ( http://izforge/izpack ), currently based on 3.8.0
* Added images based on work done by EPiC
* Extends IzPack UserInputPanel type: ValidatePackSelections
- modules/installer-support component
IzPack requires that any extensions be in the
standalone-compiler jar at the time of the
installer. The maven.xml of this project copies
the (izpack)standalone-compiler-3.8.0.jar from
the maven repo and injects the output of the
compile into a copy of the jar and stores it
in the local repo as
(geronimo)standalone-compiler-custom-3.8.0.jar.
The step which builds the installer
(plugins/geronimo-izpack-plugin) has a
dependency on this new jar. The assembly step
assemblies/j2ee-installer has a dependency on
the plugin.
- added intra-panel port validation
Up to 7 port port conflicts are reported
on the Configuation Checkpoint panel.
The limit is imposed by real estate limiateions.
- added fixes for IzPack auto-install xml processing
(need to check 3.8.1 for possible fixes)
The problem was that the default processing
provided by IzPack caused the embedded xml for
each panel to be duplicated each time the panel
is exited. This was easy to fix for
ValidatePackSelections, but required a work-around
for the pack selection screen since we don't want
to change that portion of IzPack. To fix the
pack selection xml the code detects exit from
the last panel and gets hold of the ImgPacksPanel
xml and a reference to the ImgPacksPanel panel
itself via the global InstallData. The code
deletes all the dependent (duplicated) xml
and calls the ImgPacksPanel to generate new xml.
- extended use of JCheckBox (VCheckBox)
Added dependency checking for config.xml elements,
i.e. can't select Jetty web container if
J2EE features is selected. Note that pack (feature)
selections already work this way, but this adds
the capability to correctly enable/disable config.xml
runtime features based on what's installed.
- Fixed IzPack *feature* of adding/removing
checkboxes from panel based on whether the pack
is selected.
Add/remove caused the checkboxes to walk off the screen
when the related pack is selected/deselected/selected.
The change simply makes unselected pack related fields
invisible and vice-versa.
- Added support for a configuration complete panel
to display list of port conflicts to repair or success.
The forward button is disabled when conflicts exist. The
operator is expected to fix any port conflicts before
continuing.
* Added plugin for izpack to build the installer
- plugins/geronimo-izpack-plugin builds the installer.
Assemblies/j2ee-installer uses the
plugins/geronimo-assembly-plugin to create the
install image which IzPack embeds into the installer
jar.
* IzPack variables
- Throughout the install, IzPack variables are
updated which may be used by IzPack to replace
values in parsable files (geronimio-izpack.xml).
Config.xml and configure.xml include variables
to be replaced by IzPack after the install image
is created. Extension code creates variables
for each pack, e.g. ${J2EE.Features}, which are
set according to whether the pack is selected
or not.
- izpack-user-input.xml creates variables like the
pack variables, but named like
${J2EE.Features.enable}. These variables are
set/reset by the VCheckBoxes based on whether
each feature is to be enabled at runtime
(config.xml).
- The pack variables are used in the project.xml of
assemblies/j2ee-installer (see config-store
handling below) to map configuration archives
to packs.
* Config-store handling
- Built module (modules/installer-processing) in
org.apache.geronimo.installer.processing called
ConfigInstaller which builds the config store after
the install image is laid down by the installer.
ConfigInstaller.java reads
${INSTALL_PATH}/var/config/configure.xml
to determine which configuration archive (CAR) files
should be installed into the configuration.
- Configure.xml is created by
plugins/geronimo-assembly-plugin/plugin.jelly from
pack
[jira] Commented: (GERONIMO-1455) System Modules portlet - Start of CAR does not start its GBeans
[ http://issues.apache.org/jira/browse/GERONIMO-1455?page=comments#action_12362676 ] David Jencks commented on GERONIMO-1455: It sounds like the console is calling the wrong method. To start the gbeans in a config, you need to call configurationManager.loadGBeans, then configurationManager.startGBeans. System Modules portlet - Start of CAR does not start its GBeans --- Key: GERONIMO-1455 URL: http://issues.apache.org/jira/browse/GERONIMO-1455 Project: Geronimo Type: Bug Components: console Versions: 1.0 Environment: AG 1.0 on WinXP with Sun 1.4.2_08 Reporter: Donald Woods Priority: Critical Fix For: 1.0.1 Start AG 1.0 with Log4j logging set to Debug. Login in to Console. Open System Modules portlet. Select Start for geronimo/j2ee-corba/1.0/car. It shows it as started in the Console and the state as Running in the logfile, but there is no output from CSSBean, SunORB or OpenEJB since the Server and UnprotectedServer GBeans were not actually started. Shutdown server. Start Server. The geronimo/j2ee-corba/1.0/car is started and port 1050 is now active. In the geronimo.log, there are now CSSBean, SunORB and OpenEJB log statements, since the Server and UnprotectedServer GBeans were loaded and started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-1422) Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
We should be able to put this in the SystemProperties gbean rather than on the command line thanks david jencks On Jan 13, 2006, at 7:41 AM, Jules Gosnell wrote: Aaron, this may not be the same issue, but I came across something that might help whilst working on the WADI integrations... I figured that AMQ's shutdown hook was seeing the ctl-c and shutting down AMQ before Geronimo had actually had a chance to do so. AMQ's shutdown hook can be suppressed via adding '- Dactivemq.broker.disable-clean-shutdown=true' to your JAVA_OPTS before starting Geronimo. This fixed one of the issues that WADI threw up and might resolve your issue, or I may be barking up completely the wrong tree... Jules Aaron Mulder wrote: I had the problem on my Mac. Aaron On 1/13/06, John Sisson (JIRA) dev@geronimo.apache.org wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1422?page=all ] John Sisson updated GERONIMO-1422: -- Description: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. 10:46:56,356 WARN [BrokerContainerImpl] Got duplicate deregisterConnection for client: ID:unknown-34799-1136504488185-10:0 10:46:56,358 WARN [TransportChannelSupport] Caught exception dispatching message and no ExceptionListener registered: javax.jms.JMSException: Error reading socket: java.io.EOFException javax.jms.JMSException: Error reading socket: java.io.EOFException at org.activemq.util.JMSExceptionHelper.newJMSException (JMSExceptionHelper.java:49) at org.activemq.transport.tcp.TcpTransportChannel.doClose (TcpTransportChannel.java:509) at org.activemq.transport.tcp.TcpTransportChannel.run (TcpTransportChannel.java:330) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:333) at org.activemq.io.AbstractWireFormat.readPacket (AbstractWireFormat.java:230) at org.activemq.transport.tcp.TcpTransportChannel.run (TcpTransportChannel.java:313) ... 1 more 10:47:27,401 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,402 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS broker failed: Initialization of TcpTransportChannel failed. URI was: tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused 10:47:27,403 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect to the JMS broker in 30 seconds I will have attached a capture of stdout also including a thread dump to this issue. was: Can anyone reproduce this problem on other platforms? If I start the tomcat build of the release candidate and then shut it down once the startup has completed it shuts down almost cleanly: Server shutdown begun 11:25:47,951 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8443 11:25:48,986 INFO [Http11Protocol] Stopping Coyote HTTP/1.1 on http-0.0.0.0-8080 11:25:49,001 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[Geronimo].[localhost].[/] has not been started Server shutdown completed I have shutdown issues If I do the following: * start the tomcat build of release candidate using geronimo.sh run --long * connect to the daytrader web app * populate the daytrader database via the daytrader configuration page * log into daytrader and view account, portfolio etc. * press ctrl-C in the window that geronimo was started in to shut it down. * You will see ActiveMQAsfEndpointWorker messages every 30 seconds. I will attach a capture of stdout also including a thread dump to this issue. Geronimo shutdown does not complete due to ActiveMQ attempting to reconnect endpoints to broker every 30 seconds
Re: Missing Dependency Exception
The repository uses a different format than a straight path. First, you should put a version number in the file name: samples/jars/samples-1.0.jar Then the repository URI should look like group/artifact/version/type, which in this case would be: samples/samples/1.0/jar Thanks, Aaron On 1/13/06, Nelson A. Perez [EMAIL PROTECTED] wrote: Hi All, I am trying to deploy a sample application but I get the following error message: Unable to distribute echo-server.xml: org.apache.geronimo.kernel.repository.MissingDependencyException: uri sample/jars/samples.jar not found in repository uri sample/jars/samples.jar not found in repository But the repository seems to be fine and the samples.jar file is there. What should I do to get around this error ? Thanks in advance, NP. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Replication using totem protocol
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 assumed invalid. Thus, you find yourself going to the db much more frequently than you would like, and the number of trips increases linearly with the number of clients - i.e. you are no longer scalable. It depends on your transaction isolation level; i.e. do you want to do a dirty read or not. You should be able to enable dirty reads to get scalability performance. I like dirty reads from a theoretical standpoint because if you can do dirty reads it means you have a high-class message bus. However, I don't expect people to ask for dirty reads unless you mean that they are going to roll back automatically. Example: inventory. Non-transactional applications however could use dirty data and still find it useful even if they don't roll back. The only way to really and truly know if the cache is up to date is to use a pessimistic read lock; but thats what databases are great for - so you might as well use the DB and not the cache in those circumstances. i.e. you always use caches for dirty reads Major databases currently do not use read locks. Oracle and SQL Server use mv2pl (multiversion two phase locking.) MySQL on the InnoDB storage engine also. PostgresSQL. (Interestingly, the first I article I know on this is Bernstein and Goodman, 1978 (!)). Sybase I don't know. I think it may have fallen a bit behind. When a tx starts you assign a cluster-wide unique id to it. That's its 'position' in time (known in Oracle as the scn, system change number). When the tx writes a data item it creates a new version, tagged with this scn. When a transaction wants to read the data, it reads the last version before _its_ scn. So when you read you definitely don't need a lock. When you write you can either use a lock (mv2pl) or proceed until you find a conflict, in which case you roll back. The latter should be used in workloads that have very little contention. Or you can use in general also but you need to have automatic retries, as with mdbs, and you should really not send any data to the dbms until you know for sure to cut down on the time required to roll back. * invalidation; as each entity changes it sends an invalidation message - which is really simple doesn't need total ordering, just something lightweight fast. (Actually pure multicast is fine for invalidation stuff since messages are tiny reliability is not that big a deal, particularly if coupled with a cache timeout/reload policy). * broadcasting the new data to interested parties (say everyone else in the cluster). This typically requires either (i) a global publisher (maybe listening to the DB transaction log) or (ii) total ordering if each entity bean server sends its changes. That's the one. The former is good for very high update rates or very sparse caches, the latter is good when everyone interested in the cluster needs to cache mostly the same stuff the cache size is sufficient that most nodes have all the same data in their cache. The former is more lightweight and simpler a good first step :) You can split up the data also. You can keep 4 replicas of each data item instead of N, and just migrate it around. But for semi-constant data like reference data, e.g. stock symbols or client data you can keep copies everywhere. Guglielmo
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
+1 to what ever Sachin wants to call it. -dain On Jan 13, 2006, at 4:43 AM, Sachin Patel wrote: Its been brought to my attention that to better align versions with server releases, the eclipse-plugin should be re-versioned for its initial release to be 1.0.0, not 0.5.0. The idea here being that any major releases of the server, will have a matching corresponding eclipse feature version. Minor versions may still need to be independently versioned. Having a plugin that packages some of the Geronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 is confusing to many users. We have a small time frame to decide if we do want to change the version immediately, as Eclipse-WTP is about to release their first maintenance release 1.0.1, and we agree upon this, I will need to inform them of this change so they can react ASAP. Our next opportunity to do this will may not be for another 1-2 months. [ ] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter - sachin
Infiniband
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 kernel scheduler is not involved at all, and there are no copies. I think the bandwidth can be up to 30Gbps right now. Pathscale makes an IB adapter which plugs into the new HTX hypertransport slot, which is to say it bypasses the pci bus (!). They report an 8-byte message latency of 1.32 microseconds. I think IB costs about $500 per node. But the cost is going down steadily because the people who use IB typically buy thousands of network cards at a time (for supercomputers.) The infiniband transport would be native code, so you could use JNI. However, it would definitely be worth it. Guglielmo
Re: Replication using totem protocol
On Jan 12, 2006, at 3:43 PM, [EMAIL PROTECTED] wrote: 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 something like Copyright 2004 The Apache Software Foundation or its licensors, as applicable. That _is_ transferring the copyright. As I told Jeff on the phone, I would definitely considering this if it turns that evs4j will really be used, but I would rather not grant someone an unlimited license at the present time. Jeff said we are going to have a discussion, so we'll know more soon enough. Nothing better to do between jobs than coding :) You should see the next program I am writing ;) Also, what do you need to locks for? Locking web sessions and stateful session beans in the cluster when a node is working on it. I see. I don't think I would pass the token around all the nodes just for session replication. It's a low-sharing workload, meaning you could have 50 servers but you only want 3 copies of a session, say. But you could write a high-available lock manager using totem, say, with three copies of the system, and write a low-latency tcp-based protocol to grab the lock. The time to get the lock would be the tcp round-trip plus the time it takes for totem to send itself a 'safe' message, which on average takes 1.5 token rotations (as opposed to 0.5). And you would load-balance among the three copies. That would probably get a latency of about 5 ms total to get a lock (just a gut feeling) and also scalability. And you can always add more copies. 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 (most likely just one request for the web session). Nodes should be able to join and leave the cluster easily. -dain
[jira] Created: (GERONIMODEVTOOLS-46) ClassNotFound when running
ClassNotFound when running --- Key: GERONIMODEVTOOLS-46 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-46 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: - WTP 1.0 - Geronimo 1.0 server - Geronimo 01/11 plugins Launch Eclipse with JDK1.5.0_04, new workspace: - install Geronimo server runtime using jdk142_09 - create f1 with f1EAR - add Geronimo facet to f1EAR manually - create Geronimo server, start server - create hello.html on f1, run on server Error: Publishing failed Starting of configuration failed. See .log for details. java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:969) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 8 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:279) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:235) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:200) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:188) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) The problem do not occur if I run Eclipse with JDK 1.4.2_09. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-46) ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-46?page=all ] Kathy Chan updated GERONIMODEVTOOLS-46: --- Summary: ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5 (was: ClassNotFound when running) ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5 -- Key: GERONIMODEVTOOLS-46 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-46 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: - WTP 1.0 - Geronimo 1.0 server - Geronimo 01/11 plugins Launch Eclipse with JDK1.5.0_04, new workspace: - install Geronimo server runtime using jdk142_09 - create f1 with f1EAR - add Geronimo facet to f1EAR manually - create Geronimo server, start server - create hello.html on f1, run on server Error: Publishing failed Starting of configuration failed. See .log for details. java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:969) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 8 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:279) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:235) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:200) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:188) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) The problem do not occur if I run Eclipse with JDK 1.4.2_09. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
Re: Infiniband
[EMAIL PROTECTED] wrote, On 1/13/2006 11:51 AM: 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 kernel scheduler is not involved at all, and there are no copies. I think the bandwidth can be up to 30Gbps right now. Pathscale makes an IB adapter which plugs into the new HTX hypertransport slot, which is to say it bypasses the pci bus (!). They report an 8-byte message latency of 1.32 microseconds. I think IB costs about $500 per node. But the cost is going down steadily because the people who use IB typically buy thousands of network cards at a time (for supercomputers.) 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? Regards, Alan
Re: Replication using totem protocol
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 (most likely just one request for the web session). Nodes should be able to join and leave the cluster easily. If you must be a pessimist, then get shared locks for reads, exclusive locks for writes, two locks conflicting if at least one of them is an exclusive lock. Hold the locks acquired until after commit (strict 2pl). To get a lock you send a totem message and wait for it to arrive. A few ms. The latency for 4 nodes should be very respectable. For 16 nodes it might still be acceptable. I would measure the throughput/latency curve in your lab and based on that you can decide at what point you need something more sophisticated (which for me would be an independent replicated lock manager which can be reached through short tcp messages and some basic load balancing.) This paper actually shows some simulations of various concurrency control protocols, so you can make an educated decision: http://citeseer.ist.psu.edu/299097.html Guglielmo
Re: Infiniband
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/
[jira] Commented: (GERONIMODEVTOOLS-46) ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-46?page=comments#action_12362687 ] Daniel S. Haischt commented on GERONIMODEVTOOLS-46: --- This is a duplicate of GERONIMODEVTOOLS-44 aka GERONIMO-1454. ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5 -- Key: GERONIMODEVTOOLS-46 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-46 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: - WTP 1.0 - Geronimo 1.0 server - Geronimo 01/11 plugins Launch Eclipse with JDK1.5.0_04, new workspace: - install Geronimo server runtime using jdk142_09 - create f1 with f1EAR - add Geronimo facet to f1EAR manually - create Geronimo server, start server - create hello.html on f1, run on server Error: Publishing failed Starting of configuration failed. See .log for details. java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:969) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 8 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:279) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:235) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:200) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:188) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) The problem do not occur if I run Eclipse with JDK 1.4.2_09. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more
[jira] Updated: (GERONIMO-1469) ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5
[ http://issues.apache.org/jira/browse/GERONIMO-1469?page=all ] Sachin Patel updated GERONIMO-1469: --- Component: deployment ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5 -- Key: GERONIMO-1469 URL: http://issues.apache.org/jira/browse/GERONIMO-1469 Project: Geronimo Type: Bug Components: deployment Environment: Windows XP Reporter: Kathy Chan Driver: - WTP 1.0 - Geronimo 1.0 server - Geronimo 01/11 plugins Launch Eclipse with JDK1.5.0_04, new workspace: - install Geronimo server runtime using jdk142_09 - create f1 with f1EAR - add Geronimo facet to f1EAR manually - create Geronimo server, start server - create hello.html on f1, run on server Error: Publishing failed Starting of configuration failed. See .log for details. java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:969) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 8 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:279) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:235) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:200) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:188) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) The problem do not occur if I run Eclipse with JDK 1.4.2_09. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1469) ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5
[ http://issues.apache.org/jira/browse/GERONIMO-1469?page=all ] Sachin Patel resolved GERONIMO-1469: Resolution: Duplicate Duplicate of 1454 ClassNotFound when publishing to Geronimo when Eclipse is launched with JDK1.5 -- Key: GERONIMO-1469 URL: http://issues.apache.org/jira/browse/GERONIMO-1469 Project: Geronimo Type: Bug Components: deployment Environment: Windows XP Reporter: Kathy Chan Driver: - WTP 1.0 - Geronimo 1.0 server - Geronimo 01/11 plugins Launch Eclipse with JDK1.5.0_04, new workspace: - install Geronimo server runtime using jdk142_09 - create f1 with f1EAR - add Geronimo facet to f1EAR manually - create Geronimo server, start server - create hello.html on f1, run on server Error: Publishing failed Starting of configuration failed. See .log for details. java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:217) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:969) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:215) ... 8 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:279) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:235) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:200) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:188) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) The problem do not occur if I run Eclipse with JDK 1.4.2_09. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Replication using totem protocol
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 configurations (new groups). You can generate ClusterEvent.ADD_NODE etc. by doing a diff of the old configuration and the new one. Evs4j does not support arbitrary algorithms for electing coordinators. In fact, in totem there is no coordinator. If a specific election is important for you, you can design one using totem's messages. If not, in evs4j node names are integers, so the coordinator can be the lowest integer. This is checked by evs4j.Configuration.getCoordinator(). I don't know the difference between REMOVE_NODE and FAILED_NODE. In totem there is no difference between the two. The only other class I think I need to comment on is Cluster. It resembles a jms session, even being coupled to actual jms interfaces. You can definitely implement producers and consumers and put them on top of evs4j. The method send(Destination, Message) would have to encode Message on top of fixed-length evs4j messages. No problem here. Personally, I would not have mixed half the jms api with an original api. I don't think it sends a good message as far as risk management goes. I think people are prepared to deal with a product that says 'we assume jms' or 'we are completely home-grown because we are so much better', but not a mix of the two. Anyway that's not for me to say. Whatever works. In conclusion, yes, I think you could build an implementation of AC on top of evs4j. BTW, how does AC defend against the problem of a split-brain cluster? Shared scsi disk? Majority voting? Curious. Guglielmo
[jira] Commented: (GERONIMO-1455) System Modules portlet - Start of CAR does not start its GBeans
[
http://issues.apache.org/jira/browse/GERONIMO-1455?page=comments#action_12362696
]
Joe Bohn commented on GERONIMO-1455:
I think the console is doing the right thing here based upon your comment
David.
Here is the code from the ConfigManagerPortlet
if (START_ACTION.equals(action)) {
List list = configurationManager.loadRecursive(configID);
for (Iterator it = list.iterator(); it.hasNext();) {
URI uri = (URI) it.next();
configurationManager.loadGBeans(uri);
configurationManager.start(uri);
}
messageStatus = Started applicationbr /br /;
} else .
There is also another comment indicating that the command line produces the
same result.
System Modules portlet - Start of CAR does not start its GBeans
---
Key: GERONIMO-1455
URL: http://issues.apache.org/jira/browse/GERONIMO-1455
Project: Geronimo
Type: Bug
Components: console
Versions: 1.0
Environment: AG 1.0 on WinXP with Sun 1.4.2_08
Reporter: Donald Woods
Priority: Critical
Fix For: 1.0.1
Start AG 1.0 with Log4j logging set to Debug.
Login in to Console.
Open System Modules portlet.
Select Start for geronimo/j2ee-corba/1.0/car. It shows it as started in the
Console and the state as Running in the logfile, but there is no output from
CSSBean, SunORB or OpenEJB since the Server and UnprotectedServer GBeans were
not actually started.
Shutdown server.
Start Server.
The geronimo/j2ee-corba/1.0/car is started and port 1050 is now active.
In the geronimo.log, there are now CSSBean, SunORB and OpenEJB log
statements, since the Server and UnprotectedServer GBeans were loaded and
started.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1470) Our context root settings should take precedence over those from application.xml
Our context root settings should take precedence over those from application.xml Key: GERONIMO-1470 URL: http://issues.apache.org/jira/browse/GERONIMO-1470 Project: Geronimo Type: Improvement Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 Someone on IRC pointed out that the context-root setting in application.xml is an assembly-time setting and should be overridden by the deploy-time setting in our web plans. At the moment the application.xml setting overrides the web plan setting. This is a trivial change, but I want to make sure there are no objections to it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build errors on trunk
I still can't build HEAD. I am using maven 1.0.2 on Ubuntu Linux with jdk 1.4.2 and svn revision 368935. I've done: + deleted geronimo from my local repo + deleted the plugins from my local repo + deleted configs/*/target + maven m:fresh-checkout + maven m:clean + maven new The build complains as follows: [echo] Running car:install for Welcome app Tomcat 12367 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car If I go into configs/openejb and build it, then restart the build, it will fail with the error I posted previously: Module geronimo/openejb/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. This will also happen on some of the other configs. It almost looks like maven has the wrong build order? Jan Aaron Mulder wrote: I was able to build HEAD successfully. I did: maven m:update maven -o m:clean m:clean-repo maven new I used Maven 1.1-beta2 and the last (online) step took 51m. Aaron On 1/12/06, Jan Bartel [EMAIL PROTECTED] wrote: Anita, I must admit that I've been trying to build most of it offline as it takes me about 8hrs to do a full build online (problem with using a laptop). I have bitten the bullet and am now about 2hrs thru a full build, so I will let you know what happens when I get up to the openejb portion of the build. thanks Jan anita kulshreshtha wrote: Jan, Did you delete openejb/core? Build openejb online without it. I could not get the core to build. thanks Anita --- Jan Bartel [EMAIL PROTECTED] wrote: Anita, Thanks for the suggestion, but it must be something else going on, as I already seem to have the org.apache.geronimo.specs.geronimo-corba_2.3_spec-1.0.jar in my local repo. I'm starting to feel like I may never have a working copy again! :-( cheers Jan anita kulshreshtha wrote: I have had the same luck! After 2 days I was able to build the server. This is related to G-1449. The missing geronimo-corba_2.3_spec-1.0.jar should be put in maven repo at org.apache.geronimo.specs manually. I hope this helps. Thanks Anita --- Jan Bartel [EMAIL PROTECTED] wrote: I've been trying to build geronimo trunk for 2 days and I'm going crazy! I've tried every combination of online and offline, m:clean, m:fresh-checkout, I've even deleted configs/*/target, and I still get this error every time I try and build the configs (this example is from the j2ee-server module, but it happens with others too): 8612 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. Anybody got any clues to help me? TIA Jan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Infiniband
On 13 Jan 2006, at 11:51, [EMAIL PROTECTED] wrote: 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 kernel scheduler is not involved at all, and there are no copies. I love infiniband RDMA! :) I think the bandwidth can be up to 30Gbps right now. Pathscale makes an IB adapter which plugs into the new HTX hypertransport slot, which is to say it bypasses the pci bus (!). They report an 8-byte message latency of 1.32 microseconds. I think IB costs about $500 per node. But the cost is going down steadily because the people who use IB typically buy thousands of network cards at a time (for supercomputers.) 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 :) It looks like MPI has support for Infiniband; would it be worth trying to wrap that in JNI? http://www-unix.mcs.anl.gov/mpi/ http://www-unix.mcs.anl.gov/mpi/mpich2/ James --- http://radio.weblogs.com/0112098/
Re: JMS Clustering in Geronimo v1
On 13 Jan 2006, at 06:39, Dave Colasurdo wrote: I'm wondering what claims *Geronimo v1* can make concerning JMS clustering. I do see that ActiveMQ makes quite a few claims around clustering though am wondering exactly which capabilities are leveraged/relevant to Geronimo v1? Clustering/failover of message brokers? If so, where is this setup and where is the failover decision making done? Queue Consumer Clusters? Message Failover? Other? Do the messaging applications require any awareness of the clustered environment or is it transparent? Has anyone tested any of these scenarios using Geronimo v1? :) ActiveMQ has all of those features; they are all done by the ActiveMQ broker. http://activemq.org/Clustering Unfortunately right now the integration of ActiveMQ into Geronimo is done via a few really basic GBeans which don't have the capability to configure all the clustering failover options in ActiveMQ broker. Today the simplest option is just to run the ActiveMQ broker outside of Geronimo and just use the JMS client / JMS Resource Adapter / RAR inside Geronimo. However as we integrate the latest 4.x of ActiveMQ into Geronimo we hope to address this to make things fully configurable from inside Geronimo James --- http://radio.weblogs.com/0112098/ ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Build errors on trunk
Hi Jan, Is it possible to checkout the trunk from scratch and try that? If it fails we'll know its not something residual in your build environment. Jan Bartel wrote: I still can't build HEAD. I am using maven 1.0.2 on Ubuntu Linux with jdk 1.4.2 and svn revision 368935. I've done: + deleted geronimo from my local repo + deleted the plugins from my local repo + deleted configs/*/target + maven m:fresh-checkout + maven m:clean + maven new The build complains as follows: [echo] Running car:install for Welcome app Tomcat 12367 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car If I go into configs/openejb and build it, then restart the build, it will fail with the error I posted previously: Module geronimo/openejb/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. This will also happen on some of the other configs. It almost looks like maven has the wrong build order? Jan Aaron Mulder wrote: I was able to build HEAD successfully. I did: maven m:update maven -o m:clean m:clean-repo maven new I used Maven 1.1-beta2 and the last (online) step took 51m. Aaron On 1/12/06, Jan Bartel [EMAIL PROTECTED] wrote: Anita, I must admit that I've been trying to build most of it offline as it takes me about 8hrs to do a full build online (problem with using a laptop). I have bitten the bullet and am now about 2hrs thru a full build, so I will let you know what happens when I get up to the openejb portion of the build. thanks Jan anita kulshreshtha wrote: Jan, Did you delete openejb/core? Build openejb online without it. I could not get the core to build. thanks Anita --- Jan Bartel [EMAIL PROTECTED] wrote: Anita, Thanks for the suggestion, but it must be something else going on, as I already seem to have the org.apache.geronimo.specs.geronimo-corba_2.3_spec-1.0.jar in my local repo. I'm starting to feel like I may never have a working copy again! :-( cheers Jan anita kulshreshtha wrote: I have had the same luck! After 2 days I was able to build the server. This is related to G-1449. The missing geronimo-corba_2.3_spec-1.0.jar should be put in maven repo at org.apache.geronimo.specs manually. I hope this helps. Thanks Anita --- Jan Bartel [EMAIL PROTECTED] wrote: I've been trying to build geronimo trunk for 2 days and I'm going crazy! I've tried every combination of online and offline, m:clean, m:fresh-checkout, I've even deleted configs/*/target, and I still get this error every time I try and build the configs (this example is from the j2ee-server module, but it happens with others too): 8612 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. Anybody got any clues to help me? TIA Jan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12362706 ] David Jencks commented on GERONIMO-1427: Previous work had some missing dependencies so maven could decide to build some j2ee configs before the openejb and axis builder configs were present. Sendingconfigs/activemq/project.xml Sendingconfigs/console-jetty/project.xml Sendingconfigs/console-tomcat/project.xml Sendingconfigs/daytrader-jetty/project.xml Sendingconfigs/daytrader-tomcat/project.xml Sendingconfigs/jmxdebug-jetty/project.xml Sendingconfigs/jmxdebug-tomcat/project.xml Sendingconfigs/jsp-examples-jetty/project.xml Sendingconfigs/jsp-examples-tomcat/project.xml Sendingconfigs/ldap-demo-jetty/project.xml Sendingconfigs/ldap-demo-tomcat/project.xml Sendingconfigs/remote-deploy-jetty/project.xml Sendingconfigs/remote-deploy-tomcat/project.xml Sendingconfigs/servlets-examples-jetty/project.xml Sendingconfigs/servlets-examples-tomcat/project.xml Sendingconfigs/uddi-jetty/project.xml Sendingconfigs/uddi-tomcat/project.xml Sendingconfigs/welcome-jetty/project.xml Sendingconfigs/welcome-tomcat/project.xml Transmitting file data ... Committed revision 368952. Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction --- Key: GERONIMO-1427 URL: http://issues.apache.org/jira/browse/GERONIMO-1427 Project: Geronimo Type: New Feature Components: general Versions: 1.1 Reporter: Bruce Snyder Attachments: separate-openejb-2.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
+1 I agree with keeping the versions in sync will reduce confusion. Sachin Patel wrote: Its been brought to my attention that to better align versions with server releases, the eclipse-plugin should be re-versioned for its initial release to be 1.0.0, not 0.5.0. The idea here being that any major releases of the server, will have a matching corresponding eclipse feature version. Minor versions may still need to be independently versioned. Having a plugin that packages some of the Geronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 is confusing to many users. We have a small time frame to decide if we do want to change the version immediately, as Eclipse-WTP is about to release their first maintenance release 1.0.1, and we agree upon this, I will need to inform them of this change so they can react ASAP. Our next opportunity to do this will may not be for another 1-2 months. [ ] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter - sachin
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
[X] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter Regards, Alan
Re: Build errors on trunk
There were definitely some missing dependencies that explain the possibility of the first problem you encountered. I'm still confused by the second one. I've fixed the dependency problems I know about. Can you update and try again? You should be able to just do: rm -rf ~/.maven/repository/geronimo/cars maven -o new4 since everything before this step already worked: removing the cars assures that you will find out if the cars are in fact built in the order they are needed. thanks david jencks On Jan 13, 2006, at 4:54 PM, Jan Bartel wrote: I still can't build HEAD. I am using maven 1.0.2 on Ubuntu Linux with jdk 1.4.2 and svn revision 368935. I've done: + deleted geronimo from my local repo + deleted the plugins from my local repo + deleted configs/*/target + maven m:fresh-checkout + maven m:clean + maven new The build complains as follows: [echo] Running car:install for Welcome app Tomcat 12367 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration with id: geronimo/openejb-deployer/1.1-SNAPSHOT/car If I go into configs/openejb and build it, then restart the build, it will fail with the error I posted previously: Module geronimo/openejb/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. This will also happen on some of the other configs. It almost looks like maven has the wrong build order? Jan Aaron Mulder wrote: I was able to build HEAD successfully. I did: maven m:update maven -o m:clean m:clean-repo maven new I used Maven 1.1-beta2 and the last (online) step took 51m. Aaron On 1/12/06, Jan Bartel janb- [EMAIL PROTECTED] wrote: Anita, I must admit that I've been trying to build most of it offline as it takes me about 8hrs to do a full build online (problem with using a laptop). I have bitten the bullet and am now about 2hrs thru a full build, so I will let you know what happens when I get up to the openejb portion of the build. thanks Jan anita kulshreshtha wrote: Jan, Did you delete openejb/core? Build openejb online without it. I could not get the core to build. thanks Anita --- Jan Bartel janb-Hmr7moDsS2RBDgjK7y7TUQ- [EMAIL PROTECTED] wrote: Anita, Thanks for the suggestion, but it must be something else going on, as I already seem to have the org.apache.geronimo.specs.geronimo-corba_2.3_spec-1.0.jar in my local repo. I'm starting to feel like I may never have a working copy again! :-( cheers Jan anita kulshreshtha wrote: I have had the same luck! After 2 days I was able to build the server. This is related to G-1449. The missing geronimo-corba_2.3_spec-1.0.jar should be put in maven repo at org.apache.geronimo.specs manually. I hope this helps. Thanks Anita --- Jan Bartel janb-Hmr7moDsS2RBDgjK7y7TUQ-XMD5yJDbdMReXY1tMh2IBg- [EMAIL PROTECTED] wrote: I've been trying to build geronimo trunk for 2 days and I'm going crazy! I've tried every combination of online and offline, m:clean, m:fresh-checkout, I've even deleted configs/*/target, and I still get this error every time I try and build the configs (this example is from the j2ee-server module, but it happens with others too): 8612 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module geronimo/j2ee-system/1.1-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. Anybody got any clues to help me? TIA Jan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Vote]: Re-version eclipse plugin from 0.5.0 to 1.0.0
+1 to 1.0.0 thanks david jencks On Jan 13, 2006, at 4:43 AM, Sachin Patel wrote: Its been brought to my attention that to better align versions with server releases, the eclipse-plugin should be re-versioned for its initial release to be 1.0.0, not 0.5.0. The idea here being that any major releases of the server, will have a matching corresponding eclipse feature version. Minor versions may still need to be independently versioned. Having a plugin that packages some of the Geronimo 1.0.0 runtime jars into a plugin that is versioned 0.5.0 is confusing to many users. We have a small time frame to decide if we do want to change the version immediately, as Eclipse-WTP is about to release their first maintenance release 1.0.1, and we agree upon this, I will need to inform them of this change so they can react ASAP. Our next opportunity to do this will may not be for another 1-2 months. [ ] Re-version the initial release to 1.0.0 [ ] Leave it at 0.5.0 [ ] Doesn't matter - sachin
Should we let users override context-root for wars in an ear?
I was irc-ing today with someone who suggested it would be useful to make it possible for our plans to override the context-root in an ear's application.xml with a different value in our plan somewhere. One obvious choice is the context-root in a web plan. After thinking about this a bit I think it would be a nice convenience for our users, and I personally don't see how it would introduce confusion. My impression of the spec's discussion of application.xml is that it tends to describe it as a bunch of hints from the person doing the assembly role to the person doing the deployment role. Jeff Genender and I tried to do a little survey of what the other app servers do and think it is as follows: weblogic -- app.xml setting overrides any web plan context root. jboss - app.xml setting overrides jonas -- there appears to be no way to set the context root other than the application.xml: a standalone war uses its file name. orion - appears to allow the application plan to override application.xml websphere -- can't tell, the administrative tools certainly allow changing context root but it is not clear if that results in a change to application.xml or a plan trifork - can't tell See also http://issues.apache.org/jira/browse/GERONIMO-1470 thanks david jencks
Re: Should we let users override context-root for wars in an ear?
This is an interesting subject. The question is, do we do things consistently? My concern at the moment is to have the application.xml be the deciding factor for one reason. People can go into the config.store and look at it and determine, that the context-root is set to a value and assume that is the context. It also makes it consistent with 2 other application servers that may be our biggest flood of Geronimo converts (Weblogic and JBoss). As is stands we have no way to obtain the plan...so it can be confusing as to what the context-root is. Granted, this is a situation with the geronimo-web.xml as well, but in a normal web.xml, there is no way to set this...so its kind of different. The only true way to see it from the config.store is the application.xml. For this reason I would say it should be the overall deciding factor...at least for now. However, I think if we can retrieve readable plans from the config.store (or console or whatever), then it may be fine to say its the plan. I guess what I am looking for is a way to get the context and know its consistent. Maybe a future idea...perhaps the ability to look in the console or a command line tool that can tell you the context, and why (plan, application.xml, geronimo-web.xml, config-id, war name). Just my .05. Jeff David Jencks wrote: I was irc-ing today with someone who suggested it would be useful to make it possible for our plans to override the context-root in an ear's application.xml with a different value in our plan somewhere. One obvious choice is the context-root in a web plan. After thinking about this a bit I think it would be a nice convenience for our users, and I personally don't see how it would introduce confusion. My impression of the spec's discussion of application.xml is that it tends to describe it as a bunch of hints from the person doing the assembly role to the person doing the deployment role. Jeff Genender and I tried to do a little survey of what the other app servers do and think it is as follows: weblogic -- app.xml setting overrides any web plan context root. jboss - app.xml setting overrides jonas -- there appears to be no way to set the context root other than the application.xml: a standalone war uses its file name. orion - appears to allow the application plan to override application.xml websphere -- can't tell, the administrative tools certainly allow changing context root but it is not clear if that results in a change to application.xml or a plan trifork - can't tell See also http://issues.apache.org/jira/browse/GERONIMO-1470 thanks david jencks
[jira] Closed: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=all ] Matt Hogstrom closed GERONIMO-1466: --- Resolution: Fixed Hogstrom:~/dev/geronimo/branches/1.0 hogstrom$ svn commit -m Geronimo-1466 1.0.1 Branch Update Adding 1.0/applications/console-standard/src/java/org/apache/geronimo/console/GeronimoVersion.java Sending 1.0/applications/console-standard/src/java/org/apache/geronimo/console/databasemanager/wizard/DatabasePoolPortlet.java Sending 1.0/applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/AbstractJMSManager.java Sending 1.0/applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/JMSConnectionFactoryManagerPortlet.java Sending 1.0/applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/handlers/CreateDestinationHandler.java Sending1.0/assemblies/j2ee-jetty-server/project.xml Sending1.0/assemblies/j2ee-tomcat-server/project.xml Sending1.0/configs/daytrader-jetty/project.properties Sending1.0/configs/daytrader-jetty/project.xml Sending1.0/configs/daytrader-jetty/src/plan/plan.xml Sending1.0/configs/daytrader-tomcat/project.properties Sending1.0/configs/daytrader-tomcat/project.xml Sending1.0/configs/daytrader-tomcat/src/plan/plan.xml Sending1.0/etc/project.properties Sending1.0/maven.xml Sending1.0/plugins/geronimo-assembly-plugin/project.properties Sending1.0/plugins/geronimo-assembly-plugin/project.xml Sending1.0/plugins/geronimo-dependency-plugin/project.properties Sending1.0/plugins/geronimo-dependency-plugin/project.xml Sending1.0/plugins/geronimo-deployment-plugin/plugin.properties Sending1.0/plugins/geronimo-deployment-plugin/project.properties Sending1.0/plugins/geronimo-deployment-plugin/project.xml Sending1.0/plugins/geronimo-izpack-plugin/project.properties Sending1.0/plugins/geronimo-izpack-plugin/project.xml Sending1.0/plugins/geronimo-packaging-plugin/plugin.properties Sending1.0/plugins/geronimo-packaging-plugin/project.properties Sending1.0/plugins/geronimo-packaging-plugin/project.xml Transmitting file data ... Committed revision 368994. Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Branch 1.0.1 Open for Business?
All, I have updated the 1.0 branch with 1.0.1-SNAPSHOT as well as removed dayTrader from the main build. At this point it builds on my system :) Please take a minute to update and see if I missed anything. I'll go over the JIRA's (about 30 of them) this weekend. Remember the goal is stability and limited new function as we'd like to get this out in the next 2 - 3 weeks. The only major new function is the installer and I think Erik said he'd get a patch out there for the 1.0 branch. Greg, Jetty has been upgraded to 5.1.10 so please check and make sure we've addressed the security bug you discovered in 1.0. Thanks! Matt
Geronimo w/ WebSphere MQ 5.3 XA
Has anyone had any luck getting Geronimo to work with WebSphere MQ 5.3 w/XA? --jason
