[jira] Created: (AMQ-968) Store and Forward reconnect failures
Store and Forward reconnect failures Key: AMQ-968 URL: https://issues.apache.org/activemq/browse/AMQ-968 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Environment: All Reporter: Andy Piper Attachments: jmstest.zip For the AMQ reconnection issue, I think it is caused by client can not stop the broker correctly after server broker is stopped. Attached zip is the test case, it is an IDEA prj, to compile or run it the incubator-activemq-4.0.jar (download from http://people.apache.org/repository/incubator-activemq/jars/incubator-activemq-4.0.jar ) should be involved. In the prj, I added two run configurations: Client, Sever to try all kinds of connection scenarios below: 1. Start client, then start server 2. Start server, then start client 3. Restart client 4. Restart server 5. Stop server, then stop client, after that restart server again, then restart client All scenarios will be successful if using the run configurations in IDEA, but if we run the server and client in DOS command line, we will find the #5 is failed. Here is the reason, if the server broker is stopped, the client can not be stopped using CTL + C, and the interrupt signal is always only captured by the client broker rather than its JVM. In this time, if we restart the server, no any messages can be received again. But the messages in client can not be lost, after killing the client and restarting it, the messages can be still sent to server. So to the scenario in Domain Log, the managed server must be killed by kill-9 shell and can not be stopped by shutdown.bat (sh) script. Uunfortunately, the scenario #4 is still failed in Domain Log though the codes are same with above test case's (it IS successful in the test case). I can not get the reason after I struggled for it the whole day :(. I am not sure if the AMQ network connector is impacted in Tomcat runtime env. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
The weblogic thin-client works this way - clustering is built into the client using portable interceptors and the JDK ORB. andy At 04:37 AM 5/5/2006, Filip Hanik - Dev Lists wrote: Jules Gosnell wrote: David Blevins wrote: On May 4, 2006, at 12:57 AM, Jules Gosnell wrote: Sort of. Both your explanations involve smartening the java clients on the other end of WS or CORBA to play nice. ?? smart java stubs for RMI over OpenEJB-protocol (what is it called?) or IIOP. for WS, the load-balancer will do it. The goal of those protocols is to interop in a language agnostic fashion. WS are all stateless for EJB, so there is nothing to cluster anyway. stateless calls are still clustered - the load-balancing and failover considerations still exist - you just do not require session affinity (stickiness). If you are talking about server-side requirements, then I agree. But for IIOP, would we simply not offer clustering to people using CORBA to interop with clients in other languages or on other platforms? to tell the truth, these cases have escaped my radar - My CORBA knowledge is pretty thin and I have only really considered it in a java/java environment - I am sure that Kresten would be much better positioned to answer this question... I will CC this to him, in case he would like to pick it up... corba is not far from RMI, and the corba implementation that you use, create their own stubs, and those stubs can do the same stuff as smart RMI stubs. I'm sure that corba could even do dynamic proxies in some sort of sense, they werent able to when I used it a long time ago, but if the technology has kept up, then yes, you should be able to build in significant logic in the clients. Filip ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Was: Clustering: Monitoring... - Now: Clustering: OpenEJB...
At 10:39 PM 5/4/2006, David Blevins wrote: stateless for EJB, so there is nothing to cluster anyway. But for IIOP, would we simply not offer clustering to people using CORBA to interop with clients in other languages or on other platforms? Some ORBs support multiple profiles for clustering (Borland is one) the IOR format is standard but the client still has to know what to do. WLS has its own clustered IOR format which we have published to some ISVs. andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Any character encoding experts out there?
Well 129 == -63 if you coerce it to a byte. I assume that's the cause
of your problem, although I'm struggling to see where this is occuring.
andy
At 03:55 PM 2/23/2006, you wrote:
I'm currently trying to sort out a problem with my implementation of
the MimeUtility class in the javamail specs. For the
encodeWord()/decodeWord() methods, my encoding encodes to the same
value as the Sun implementation, but the decoding is driving me
nuts. I'm able to successfully decode this into what should be the
correct byte[] array, but when used to instantiate the String value,
I'm getting a bogus character value.
Playing around with this, I've discovered that the problem seems to
be occurring with the String constructor, and can be demonstrated
without using the javamail code at all. Here is a little snippet
that shows the problem:
String longString = Yada, yada\u0081;
try {
byte[] bytes = longString.getBytes(Cp1252); //
get the bytes using CP1252
String newString = new String(bytes, 0, bytes.length,
Cp1252); // create a new string item using the same code page.
// last char of original is int 129, last char of
rebuilt string is int 63.System.out.println(
original string = + longString + rebuilt string = + newString);
System.out.println( original string = +
(int)longString.charAt(longString.length() - 1) + rebuilt string
= + (int)newString.charAt(longString.length() - 1));
} catch (Exception e) {
}
63 is the last value in the byte array after the getBytes() call,
and the Sun impl of MimeUtility.encodeWord() returns the string
=?Cp1252?Q?Yada,_yada=3F?= (0x3F == 63), so the correct value is
getting extracted. I'm at a loss to figure out why the round trip
coded above is corrupting the data. What am I missing here?
Rick
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
Re: Any character encoding experts out there?
At 05:25 PM 2/23/2006, Andy Piper wrote: Well 129 == -63 if you coerce it to a byte. I assume that's the cause of your problem, although I'm struggling to see where this is occuring. Ignore me, I evidently can't count :) andy ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: CORBA and GSSUP fix -- please review
At 05:14 PM 2/10/2006, Aaron Mulder wrote: Sorry, you're crediting me with a lot more CORBA knowledge than I deserve. :) In particular, I'm not sure what the right IIOP URL or corbaname URL should be. Let me give you a more specific scenario: Let's say I have a session bean running in Geronimo, so the Geronimo side of the picture looks like this: CORBA naming service: localhost:1050 (or corbaloc::localhost:1050/NameService), with SSL enabled EJB name in naming service: MySessionBean EJB TSS listening for SSL on localhost:1055 So assuming G supports corbaname (which it should) the url for this would look like so: corbaname:iiop:[EMAIL PROTECTED]:1050#MySessionBean Now I have a web app deployed in WebLogic with an ejb-ref in web.xml pointing to the correct home and remote interface for this session bean, but with no EJB link. So I'm assuming I need to put something in weblogic.xml in order to resolve this ejb-ref to point to the CORBA EJB above. What does that configuration block look like? I'm not sure I fully understand, but there is nothing special about CORBA internally. A weblogic.xml entry might look like this: reference-descriptor ejb-reference-description ejb-ref-name j2ee/interop/demo/tester /ejb-ref-name jndi-name ejb/j2ee/interop/demo/tester /jndi-name /ejb-reference-description /reference-descriptor The JNDI name could be a corbaname URL if the EJB is remote. Also, if security is enabled for that session bean in Geronimo, so I want to pass my username and password that I used for the WebLogic web app across to the Geronimo EJB using GSSUP, and Geronimo requires that the GSSUP token contain the domain name (or target name) of geronimo-properties-realm along with the username and password, how would I set that up in weblogic.xml? I'm not sure we allow you to control this :). Security settings can be set per ejb in the descriptor, but I don't think the target is included. Finally, let's say the EJB is running in WebLogic and the web app running in Geronimo: - What naming service corbaloc would I use on the Geronimo side to point to WebLogic's naming service? Would it be corbaloc::localhost:7001/NameService? Yes, but better to use corbaname above. - What is the name of the EJB inside the WebLogic naming service? e.g. is it one of the ejb-name or the jndi-name for that EJB, or is there some other setting for it? Its just the jndi-name. - Is it OK to specify that SSL should be used to contact the naming service and/or the EJB? Does anything need to be done on the WebLogic side to enable that? (Other than I guess any URLs would go over the SSL listen port not the regular WebLogic listen port.) I would recommend you start without security first :) The simplest way to force the use of SSL is to switch off the main listen port. You can also fiddle with the EJB security descriptors, although this is not documented. - If the EJB is secured on the WebLogic side and I want to pass my Geronimo login username and password to WebLogic via GSSUP, does WebLogic expect any particular target name or domain name to come with the username/password in the GSSUP authentication token? No. I think we will strip the target name or use it as the security realm name. andy
Re: CORBA and GSSUP fix -- please review
I don't believe it's actually required to provide the username in the client identity field if you have a password. You can simply provide an auth token containing both username and password and set the identity token to ITTAbsent. We (WLS) only fallback on ITTPrincipleName if there is no password available, in which case you have to have established a trust relationship and perform identity assertion. If you use the principle name token then the decoder should be able to understand the attached scope if any - removing it on the encoding side does not seem right to me. andy At 09:57 AM 2/10/2006, Jeppe Sommer (Trifork) wrote: According to the CORBA 3.0.3 spec (and I believe the original CSIv2 spec says the same): Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | [EMAIL PROTECTED] | @name_scope The '@' character shall be used to delimit name_value from name_scope. All nondelimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. This suggests that the right way to fix this is to make the decoder tolerant to both name and [EMAIL PROTECTED] I don't known how the third variant - just @domain - is to be interpreted though. I'm also uncertain how an empty domain part is to be interpreted. To be on the safe side, I would suggest always encoding the full form ([EMAIL PROTECTED]) and live with the redundancy. Cheers, /Jeppe Aaron Mulder wrote: So it turns out our GSSUP token encoder set the username to [EMAIL PROTECTED] and the GSSUP token decoder did not lop off the @domain part, so Geronimo could not talk to itself using GSSUP. I changed the token encoder to just pass the username straight through -- there is a separate field in the token that holds the domain, after all, so mangling the username did not seem to make much sense. Just want to make a note of this in case someone thinks it should be changed the other way (that is, the GSSUP token encoder should send [EMAIL PROTECTED] and the GSSUP token decoder should lop off and ignore the @domain part, or compare the @domain to the domain that is sent in the other field). Thanks, Aaron P.S. Actually the GSSUP token encoder set the username to [EMAIL PROTECTED] due to an additional bug in the dynamic GSSUP configuration, so I gather no one's actually used this code before. :)
Re: CORBA and GSSUP fix -- please review
At 03:51 PM 2/10/2006, Aaron Mulder wrote: Andy, is there some good documentation on exposing an EJB via CORBA in WebLogic, or configuring an EJB reference to connect to a remote CORBA EJB? I might as well try a WebLogic-to-Geronimo test to help resolve this. Its enabled by default. In theory just point at the right IIOP URL and you are golden. Unfortunately vendors' opinions differ on what each server should actually do in ejb-ejb calls. We have a long internal doc for configuring WAS for WLS-WAS interop since its particularly tricky with security switched on. As to configuring an EJB ref, any conforming implementation should support a ref with a corbaname URL inside. andy
Re: CORBA and GSSUP fix -- please review
At 03:51 PM 2/10/2006, Aaron Mulder wrote: Just to be clear, I'm talking about GSSUP authentication (where the client sends a token containing a username and password and an encoded domain name) not one of the principal name strategies (e.g. ITT*). Jeppe, I'm not clear whether the GSS Name Form you're describing applies to the username in a username/password/domain token or the principal name in a principal name token. It would seem weird to set the username to [EMAIL PROTECTED] when the same token already contains a domain name, in effect. The format of the name passed in the username field depends on the authentication domain. If the mechanism identifier of the target domain is GSSUP, then the format of the username shall be a Scoped-Username (with name_value) as defined in Scoped- Username GSS Name Form on page 26-15 So it applies, although stripping the domain seems legal to me. andy
Re: License issues with commonj
At 06:59 AM 2/2/2006, Geir Magnusson Jr wrote: I've also discussed this issue regarding the lack of any recognizable license for their code w/ BEA and IBM, and they have made it very clear that they will provide one if needed. So the question is, type or wait for license? I say type I believe that it was never our intention that the java API should be encumbered in a way that raises these issues and certainly not our intention that people would have to type in the code from the javadoc in order to circumvent the issues. My understanding was that we have already resolved this internally (and hence why we are offering help in implementing the APIs), but I will double check. Thanks andy
Re: [vote] XBean donation
+1 andy At 08:08 PM 1/27/2006, you wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http:// cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/xbean/ xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain
Re: CORBA incubation proposal
I'd quite like to be involved in this. I wrote the WebLogic ORB. andy At 01:31 PM 1/19/2006, Matt Hogstrom wrote: Alan, I do have a question about the initial committer list. Since I'm relatively new to Apache my understanding was that commit was based on previous work. Many of the names on the list are new to me so I have not had an opportunity to work with them. Are all the suggested names currently committers at Apache? If not, is this standard practice for granting commit and does this mean they are granted commit to the entrire Geronimo dev tree? Thanks for the follow up. Matt Rick McGuire wrote: Alan D. Cabrera wrote: Here is the incubation proposal http://wiki.apache.org/incubator/CorbaProposal I'm interested in assisting with this. I was wrote the adapter code that allowed IBM's WAS CE product to work with the IBM JDK ORB. This required developing a pretty good understanding of how Geronimo hooks into the ORB, as well as finding places where hidden assumptions about ORB behavior created additional tie-ins to a single implementation. Does anyone have any comments before we vote on it? Should this also get sent to the incubator list or do we wait until after the vote? Alex Karasulu and I were talking about it and we both think that it might be a good idea to shoot for making this a TLP. Thoughts? Regards, Alan
Re: jRockit and Geronimo - Dain, can you add Andy ?
Many thanks andy At 06:06 PM 11/16/2005, you wrote: Done. -dain
Re: Trifork CORBA
At 08:07 PM 10/27/2005, Matt Hogstrom wrote: I think for those platforms you mention below the IBM is the only JDK to choose from. Although, on Windows and Linux its a pretty good choice too :) Of course I would beg to differ ;) Have you fired G up on JRockit yet? I'd be curious to compare performance data. I know it works. I don't have any hard numbers that I can share. andy
Re: Trifork CORBA
At 09:39 AM 10/28/2005, Kresten Krab Thorup wrote: The Trifork RMI/IIOP has a quite decent implementation of all of the javax.rmi.CORBA stuff that we can bring right in with little modification, so I was thinking that we should use that. However, if you know that those ValueHandlers are good, we can definitively make things less complicated by using them. I'm merely advocating walking before running ;). The only real reason for not using these pieces is performance, and even then the performance of the underlying streams is far more important. We don't even use our own ValueHandler for FVD serialization, just because its complicated, slow and not worth reinventing the wheel for. If you get run over by a bus, its going to be non-trivial for someone to figure out issues with a home-grown ValueHandler... andy
Re: Trifork CORBA
At 01:51 PM 10/27/2005, Kresten Krab Thorup wrote: One issue is that RMI needs to be able to write the value of a final instance field (to de-serialize an object) and this is something that cannot be done with reflection. So for this we are using com.sun.Unsafe (which is the internal Sun API to implement reflection). This is also there in the IBM VMs, but JRockit has another API to accomplish the same thing. The other thing is being able to call constructors in the particular way needed when de-serializing instances of classes that have no public no-arg constructor. For this, we generally need to call into VM-specific private static methods also. The latest JRockit implements the appropriate parts of Unsafe - I know because I made them put it in so that I could implement the WebLogic ValueHandler on top of it. But why not just use the VM's ValueHandler? The Sun and IBM one's are both pretty reasonable now. andy
Re: Trifork CORBA
Somehow my spam filter removed your original e-mail At 07:09 PM 10/26/2005, Rick McGuire wrote: Actually, then don't. The IBM JVM certainly doesn't, and I don't believe JRocket does either. And it is JRockit uses the Sun ORB. The IBM VM is the notable exception I referred to. That's why I asked why it was critical. Seems its only critical if you want to run on AIX or OS/390, but then I guess some do ... andy
Re: Trifork CORBA
At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a necessary evil. It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is get it working, get it portable. Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. andy
RE: Clustering - JGroups issues and others
At 02:40 AM 10/19/2005, [EMAIL PROTECTED] wrote: It is the problem of homogenius environment. Blade servers are naturally organized in chassis called enclosures (HP's term) or bladecenters (IBM's one). All those chassis are interconnected with each other using one or more external switches. Due to the fact that larger solutions tend to use multiple VLANs, the failure of each of them can be independent from the others. So it can occur, that the group of nodes will loose connectivity to all the rest of the cluster for some time (HA implied), but will see each other and also other backend services like database etc. This is the split-brain problem. If the split is even you basically can't solve the singleton issue without backdoor communication channels. If the split is not even you can reach consensus on who owns the data, but it basically means that the other part of your cluster has to fence itself and is unusable. andy
RE: Clustering - JGroups issues and others
At 05:26 AM 10/19/2005, [EMAIL PROTECTED] wrote: is not the only interface in the cluster. From our perspective all clustered facilities should base on the same mechanism in the solution, as otherwise the behaviour of the system is hardly predictable. So, if we base some application/service distribution model based on assumption that sub-partitioning is possible, we may end up with interesting (from technical perspective) problems regarding multiple services instead of a single one reporting controversal values. Unfortunately if you go this route then you will end up requiring strong consistency everywhere which basically doesn't scale. You _have_ to leverage the knowledge you have about access patterns and consistency requirements if you want a practical system that scales. andy
Re: Java serizalization compatibility issues
At 02:43 AM 9/23/2005, Jeremy Boynes wrote: Sachin's problem is not related to configuration persistence but to the serialization of classes between plugin and server when using JMX remoting over RMI. The upshot of it all is unless we are going to ditch all use of serialization and replace it with XML then we need to exercise the necessary discipline and version the classes involved. IMO most people underestimate the degree of compatibility that can be achieved with serialization - but then I have written RMI stacks for a living and am naturally biased :) Given that RMI-based JMX is in Java SE 5 now it seems a little strange to entirely ditch this approach. Simply fixing the svuid for all serialized classes will make things considerably better since without this svuid's change for the most minor (and inconsequential) reasons. This could be done mehcanilcally with appropriate use of sed and serialver ... $0.02 andy
Re: Thread Pool vs WorkManager
At 08:19 AM 8/16/2005, Aaron Mulder wrote: What's the difference between using a thread pool and using a work manager? I think OpenEJB uses thread pools, and it sounds like ServiceMix uses work managers. Can we standardize on work managers? At some level they are the same, but Work Manager is a more appropriate abstraction especially if you want to start scheduling stuff in strange or specific ways. For instance WebLogic Server has many WorkManagers (and you can create your own) but they all map to a single thread pool since threads are a costly resource. There are per-WorkManager properties that affect scheduling priorities etc, etc. WebSphere on OS/390 [I think?] allows you to schedule work remotely so a thread pool does not really compute in this context. andy
Re: Clustering (long)
Hi Jules At 05:37 AM 7/27/2005, Jules Gosnell wrote: I agree on the SPoF thing - but I think you misunderstand my Coordinator arch. I do not have a single static Coordinator node, but a dynamic Coordinator role, into which a node may be elected. Thus every node is a potential Coordinator. If the elected Coordinator dies, another is immediately elected. The election strategy is pluggable, although it will probably end up being hardwired to oldest-cluster-member. The reason behind this is that relaying out your cluster is much simpler if it is done in a single vm. I originally tried to do it in multiple vms, each taking responsibility for pieces of the cluster, but if the vms views are not completely in sync, things get very hairy, and completely in sync is an expensive thing to achieve - and would introduce a cluster-wide single point of contention. So I do it in a single vm, as fast as I can, with fail over, in case that vm evaporates. Does that sound better than the scenario that you had in mind ? This is exactly the hard computer science problem that you shouldn't be trying to solve if at all possible. Its hard because network partitions or hung processes (think GC) make it very easy for your colleagues to think you are dead when you do not share that view. The result is two processes who think they are the coordinator and anarchy can ensue (commonly called split-brain syndrome). I can point you at papers if you want, but I really suggest that you aim for an implementation that is independent of a central coordinator. Note that a central coordinator is necessary if you want to implement a strongly-consistent in-memory database, but this is not usually a requirement for session replication say. http://research.microsoft.com/Lampson/58-Consensus/Abstract.html gives a good introduction to some of these things. I also presented at JavaOne on related issues, you should be able to download the presentation from dev2dev.bea.com at some point (not there yet - I just checked). The Coordinator is not there to support session replication, but rather the management of the distributed map (map of which a few buckets live on each node) which is used by WADI to discover very efficiently whether a session exists and where it is located. This map must be rearranged, in the most efficient way possible, each time a node joins or leaves the cluster. Understood. Once you have a fault-tolerant singleton coordinator you can solve lots of interesting problems, its just hard and often not worth the effort or the expense (typical implementations involve HA HW or an HA DB or at least 3 server processes). Replication is NYI - but I'm running a few mental background threads that suggest that an extension to the index will mean that it associates the session's id not just to its current location, but also to the location of a number of replicants. I also have ideas on how a session might choose nodes into which it will place its replicants and how I can avoid the primary session copy ever being colocated with a replicant (potential SPoF - if you only have one replicant), etc... Right definitely something you want to avoid. Yes, I can see that happening - I have an improvement (NYI) to WADI's evacuation strategy (how sessions are evacuated when a node wishes to leave). Each session will be evacuated to the node which owns the bucket into which its id hashes. This is because colocation of the session with the bucket allows many messages concered with its future destruction and relocation to be optimised away. Future requests falling elsewhere but needing this session should, in the most efficient case, be relocated to this same node, other wise the session may be relocated, but at a cost... How do you relocate the request? Many HW load-balancers do not support this (or else it requires using proprietary APIs), so you probably have to count on moving sessions in the normal failover case. I would be very grateful in any thoughts or feedback that you could give me. I hope to get much more information about WADI into the wiki over the next few weeks. That should help generate more discussion, although I would be more than happy for people to ask me questions here on Geronimo-dev because this will give me an idea of what documentation I should write and how existing documentation may be lacking or misleading. I guess my general comment would be that you might find it better to think specifically about the end-user problem you are trying to solve (say session replication) and work towards a solution based on that. Most short-cuts / optimizations that vendors make are specific to the problem domain and do not generally apply to all clustering problems. Hope this helps andy
Re: Webdav admin interface
We experimented with this with WLS, it worked pretty well. The nice thing about webdav is that you can mount it as a file system from windows and OSX. We also tried a similar experiment with ftp which also worked pretty well. However, you generally want to script admin commands and there are a lot of other java-based scripting options out there which can just use JMX directly. andy At 05:09 PM 7/20/2005, Lyndon Samson wrote: Just another wacky idea but... Webdav clients are becomming more common. Webdav is being used for admin like tasks ( http://metzner.org/projects/xincon/ ). I wonder if you could wrap webdav around Management GBeans/JMX/? and give access to Geronimos internals in a similar manner to the /proc interface in Linux. Would it add anything or just be a cool bit of code? :-) cheers lyndon -- Into RFID? www.rfidnewsupdate.com Simple, fast, news.
Re: Clustering (long)
Hi Jules It sounds like you've been working hard! I think you might find you run into reliability issues with a singleton coordinator. This is one of those well known Hard Problems and for session replication its not really necessary. In essence the coordinator is a single point of failure and making it reliable is provably non trivial. Cluster re-balancing is also a hairy issue in that its easy to run into cascading failures if you pro-actively move sessions when a server leaves the cluster. I'm happy to talk more about these issues off-line if you want. Thanks andy At 02:31 PM 6/30/2005, Jules Gosnell wrote: Guys, I thought that it was high time that I brought you up to date with my efforts in building a clustering layer for Geronimo. The project, wadi.codehaus.org, started as an effort to build a scalable clustered HttpSession implementation, but in doing this, I have built components that should be useful in clustering the state held in any tier of Geronimo e.g. OpenEJB SFSBs etc. WADI (Web Application Distribution Infrastructure) has two main elements - the vertical and the horizontal. Vertically, WADI comprises a stack of pluggable stores. Each store has a pluggable Evicter responsible for demoting aging Sessions downwards. Requests arriving at the container are fed into the top of the stack and progress downwards, until their corresponding Session is found and promoted to the top, where the request is correctly rendered in its presence. Typically the top-level store is in Memory. Aging Sessions are demoted downwards onto exclusively owned LocalDisc. The bottom-most store is a database shared between all nodes in the Cluster. The first node joining the Cluster promotes all Sessions from the database into exclusively-owned store - e.g. LocalDisc. The last node to leave the Cluster demotes all Sessions down back into the database. Horizontally, all nodes in a WADI Cluster are connected (p2p) via a Clustered Store component within this stack. This typically sits at the boundary between exclusive and shared Stores. As requests fall through the stack, looking for their corresponding Session they arrive at the Clustered store, where, if the Session is present anywhere in the Cluster, its location may be learnt. At this point, the Session may be migrated in, underneath the incoming request, or, if its current location is considered advantageous, the request may be proxied or redirected to its remote location. As a node leaves the Cluster, all its Sessions are evacuated to other nodes via this store, so that they may continue to be actively maintained. The space in which Session ids are allocated is divided into a fixed number of Buckets. This number should be large enough such that management of the Buckets may be divided between all nodes in the Cluster roughly evenly. As nodes leave and join the Cluster, a single node, the Coordinator, is responsible for re-Bucketing the Cluster - i.e. reorganising who manages which Buckets and ensuring the safe transfer of the minimum number of Buckets to implement the new layout. The Coordinator is elected via a Pluggable policy. If the Coordinator leaves or fails, a new one is elected. If a node leaves or joins, buckets emigrate from it or immigrate into it, under the control of the Coordinator, to/from the rest of the Cluster. A Session may be efficiently mapped to a Bucket by simply %-ing its ID's hashcode() by the number of Buckets in the Cluster. A Bucket is a map of SessionID:Location, kept up to date with the Location of every Session in the Cluster, of which the id falls into its space. i.e. as Sessions are created, destroyed or moved around the Cluster notifications are sent to the node managing the relevant Bucket, informing it of the change. In this way, if a node receives a request for a Session which it does not own locally, it may pass a message to it, in a maximum of typically two hops, by sending the message to the Bucket owner, who then does a local lookup of the Sessions actual location and forwards the message to it. If Session and Bucket can be colocated, this can reduced to a single hop. Thus, WADI provides a fixed and scalable substrate over the more fluid arrangement that Cluster membership comprises, on top of which further Clustered services may be built. The above functionality exists in WADI CVS and I am currently working on hardening it to the point that I would consider it production strength. I will then consider the addition of some form of state replication, so that, even with the catastrophic failure of a member node, no state is lost from the Cluster. I plan to begin integrating WADI with Geronimo as soon as a certified 1.0-based release starts to settle down. Certification is the most immediate goal and clustering is not really part of the spec, so I think it best to satisfy the first before starting on subsequent goals. Further down the road we need to consider the unification of session id spaces used
Re: ActiveIO
At 11:41 AM 7/12/2005, David Jencks wrote: If an application does a JAAS-based certificate login, then the private credentials thus stored in the current subject should be used to do the client-side of an client authentication on a successive remote corba SSL call. Thus making the client system identity identical to the logged in user. While I like the idea of allowing this as an option, my understanding is this is not csiv2 compliant: I think this is what the ITTX509CertChain is for. Please correct me if I'm wrong. One of the problems with CSIv2 is that no-one has defined what it means in relation to J2EE client security. The only mandated things are those described in the EJB 2.x spec and those are server-server only and give vendors a great deal of leeway. We have ongoing customer expectation issues with secure interop between WAS and WLS - both of which are CTS compliant - because of different interpretations of the spec. The use of X509 cert chains in SSL handshake and the SAS protocol are somewhat orthogonal issues. Its perfectly possible to establish trust at the SSL level using one set of certs and assert identity at the SAS level using another. The CSIv2 spec supports both and I don't think it is illegal to do either. The spec does say that the SAS protocol support is to potentially overcome limitations at the transport level. So I suspect you could do either and still be CTS compliant. I would say that using certs to establish identity in the SSL handshake has been used by appserver vendors for a very long time and is therefore likely to be supported by more appservers than at the SAS protocol level. WLS for instance supports inbound certs via ITTX509CertChain but does not currently provide a client mechanism instead relying on SSL. HTH andy
Re: Geronimo and JSR-237 WorkManager API for App Servers
An alternative here would be using commonJ. Although 237 will be the eventual J2EE standard for this it is only just getting started and will almost certainly depend on the JSR 166 APIs (which use generics) that are integrated into J2SE 5. 237 is unlikely to be substantially different to commonJ and commonJ is already supported in several major appservers (WAS and WLS surprise, surprise!). The only issue with this is the legal status of the API which BEA and IBM currently own the IPR for. I expect its possible to unencumber it, but I could be wrong. I will investigate if there is any interest. I do think that the work-style API is the correct one to standardize on internally, but I wouldn't hold your breath for 237 for this - better to define your own or use something already out there. andy At 05:04 PM 6/22/2005, Geir Magnusson Jr. wrote: On Jun 22, 2005, at 4:04 PM, Tyagi, Rahul wrote: Hello Team!! Recent version of leading app servers are supporting JSR-237 Work Manager for Application Server. I believe JSR-237 is simple and powerful API for writing robust parallel processing application for managed environment. Prior to that developers used to open non managed threads for accomplishing parallel processing in J2EE container, , Obviously which is not a recommended way!! I think JSR-237 is a major step in writing scalable parallel processing application within managed environment. I am curious whether we have plan to support JSR-237 in future releases of Geronimo, If community see benefit of adding JSR-237 to Geronimo I can volunteer to implement JSR-237 for Geronimo. Some of us have indicated a general interest in participating in the JSR, and doing an implementation here at the the ASF in the Geronimo project. So Have at it. Thanks for volunteering. As you've probably noticed, working with the rest of the community, especially David Jencks, will be important. Don't be shy about asking for ideas, help and discussion. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
