AUTO: Walter Heestermans/TMME is out of the office. (returning 22/07/2013)
I am out of the office until 22/07/2013. I will respond to your message as soon as possible. For urgent issues, contact WebSphere Support group for Java-WebSphere related activities or unix.admin group for Unix-WebSphere-Jetty related activities Note: This is an automated response to your message "Re: Share info across different sessions & servers" sent on 6/07/2013 1:49:01. This is the only notification you will receive while this person is away. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Share info across different sessions & servers
hi Jose,
here is a working demo for exchanging messages between remote hosts using
tribes
import java.io.IOException;
import java.io.Serializable;
import java.net.InetAddress;
import java.net.NetworkInterface;
import java.net.SocketException;
import java.nio.charset.Charset;
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.Vector;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.catalina.tribes.ByteMessage;
import org.apache.catalina.tribes.Channel;
import org.apache.catalina.tribes.ChannelException;
import org.apache.catalina.tribes.Member;
import org.apache.catalina.tribes.MembershipListener;
import org.apache.catalina.tribes.ChannelListener;
import org.apache.catalina.tribes.group.GroupChannel;
import org.apache.catalina.tribes.membership.StaticMember;
/**
*
* @author vince
* demonstration of tribes messaging between remote hosts
* three jar files are required
(org.apache)
catalina.jar
catalina-tribes.jar
tomcat-embed-logging-juli.jar
compile and run with following arguments
java -jar jarfileName.jar ss
java -jar jarfileName.jar xx.xx.xx.xx
where jarfileName is whatever you call your jar file
ss is the literal argument "ss" for the machine designated as
"superserver" (sort of arbitrary)
for machines other than superserver:
xx.xx.xx.xx is the IPv4 address for the superserver machine
is relevant port number
Note that tribes normally uses port 4000. However if you run the
application at superserver first
you will then know which port number tribes is using (could be 4001, 4002
...)
Note also that if the superserver is part of a LAN, there will be a
router involved;
the remote applications will then need to point to the router IP address
and the router port that
is redirected to the machine/port running tribes (more of this below)
If non-superserver machines use a router, these also have to have
appropriate redirections set up.
Some log output refers to clustering functionality operating.
This does not seem to interfere with the messaging operations used.
I have not looked into any possible mechanisms to suppress clustering
threads.
A very important limitation to remote messaging (and a possible solution)
is discussed here.
http://tomcat.10.x6.nabble
.com/overcoming-a-message-size-limitation-in-tribes-parallel-messaging-with-NioSender-tt4995446.html
*/
public class TribesRemote {
static TribesRemote tribesRemote;
static Charset UTF8=Charset.forName("UTF-8");
static int membersOnLine=0;
ChannelListener msgListener;// = new MyMessageListener(this);
MembershipListener mbrListener;// = new MyMemberListener();
StaticMember superServerStaticMember;
boolean amSuperServer=false;
private long lastMessageReceived;
String remoteHostIPv4Address;
int remoteHostPort;
Channel myChannel;
public static void log(String s){
System.out.println("INFO: "+s);
}
public static void log(Exception ex){
System.out.println("ERROR "+ex.getMessage());
//Logger.getLogger(TribesRemote.class.getName()).log(Level.SEVERE, null,
ex);//uncomment here for detailed error msg
}
public static void main(String[]args) throws IOException, ChannelException{
TribesRemote.tribesRemote=new TribesRemote(args);
TribesRemote.tribesRemote.engage();
}
TribesRemote(String[] args) throws IOException, ChannelException{
log(this.addressesForThisMachine());
remoteHostIPv4Address="xx.xx.xx.xx"; //actual superserver address may be
placed here
remoteHostPort=4000; //actual superserver port may be placed here
if(args.length==0){
log("TribesRemote has been lauched with zero arguments");
}
else{
String argz="";
for(int i=0;i1){ // otherwise subservers can be started using two
arguments
remoteHostIPv4Address=args[0]; // IPv4 adddress in xx.xx.xx.xx format
where x is numeric
remoteHostPort=Integer.parseInt(args[1]); //the port number which tribes
starts on
}
if(args[0].equalsIgnoreCase("ss")){ ///NB superserver started with
singular argument "ss"
amSuperServer=true;
log("this is deginated superserver and will wait for members to introduce
themselves");
}
else{
superServerStaticMember=new
StaticMember(remoteHostIPv4Address,remoteHostPort,0);
}
}
//tribes always uses 4000 if available (otherwise
it uses 4001, 4002 etc)
//this application will output the actual tribes
address => std output
//but setting remoteHostPort to 4000 may not be
appropriate if you have a router
//if you have a router then the remote host needs
to know the IPv4 for the router and
//the redirection port number pointing to a tribes
socket for a LAN machine
//for example:
//the remote router has fixed IP address say
203.12.32.235
//the remote machine running tribes (on p4000) has
fixed LAN address say 192.168.1.63
//(in Linux you set
Expected Delay when Switching to New Version of Application Using Parallel Deployment (Tomcat 7.0.27)
For a simple web application, what is the expected delay when switching to new version of an application when using the parallel deployment process? I'm trying to do timings right now with a single Hello World JSP and sometimes there is a delay of up to 4 seconds when the new version of the application is deployed (running 5 users simultaneously using Jmeter with cookies turned off), but other times I don't see this behavior. Does anyone know if it is expected for there to be a slight hiccup in response times when the applications are deployed via parallel deployment? I understand that many applications will have initialization logic and that may cause a delay, but I'm wondering if I should expect tomcat to introduce a very small delay when switching from the old version to the new version and if so, how long should I expect that process to take. Please let me know if I haven't been clear. Thanks, Jeremy
Re: websockets questions
On Fri, Jul 5, 2013 at 3:40 AM, André Warnier wrote: > We're still one level remote of thinking of any implementation, and trying > to understand > 1) how exactly websockets works > Most websocket implementations (RI/glassfish, atmosphere, tomcat, etc...) are open source, so diving in the code is definitely an 'option' for understanding how websockets work. > 2) if that general "technology" is, today, sufficently mature and stable > for us to develop an application based on it, or we should wait another 6 > months, a year,.. > honestly, I think it is sufficiently mature, since websockets are becoming the trend (incorporated in RI/glassfish/JavaEE7, I've seen recent tomcat 7.0.35+ releases that had websocket changes, no need to mention how 'alive' atmosphere is...smile). i think it is more a question of feasibility for you and your team to join in on the trend/fun... > But we are a small outfit, and the fact that Google may be using it (with > a backup team of 50 developers to shore up their implementation) does not > really help us. > funny. google's backup team of 50 developers versus how many open source developers using/coding atmosphere, tomcat, glassfish-websockets (grizzly?). :) > > The reason why I put this question on the Tomcat users list is because it > is a list I'm subscribed to, because I know that it is a good-quality list > with little "noise", because I know that Mark and Rainer are - to various > degrees probably - involved in Tomcat support for websockets. +1 > for the moment the general information available on websockets seems > otherwise a bit "scarce". > > true, but websocket open source code is plentiful and available. :) > This being said, the information already gathered here on this list tends > to vindicate my posting on it. It has already cleared up a number of points > for us, and added a couple of questions which we did not think of asking. > Thanks. > > IMO (or maybe based on fact/history), not much chatter about websockets on tomcat user list, but if you find your way to atmosphere google groups mail list, there will be plenty of chatter over there. I will not encourage you to venture over to atmosphere google groups and ask questions such as this, since I'm sure the desire/goal over there is to post topics related to 'using atmosphere and any questions/issues while attempting to use atmosphere and atmosphere's trunk (latest version(s))'. i'm definitely someone that love to use latest versions of open source software. sometime ago, when I migrated from glassfish to tomcat/tomee (so I could do websockets, um, more effortlessly in my web app), I came across the fact that Jeanfrancois (Atmosphere developer/committer) had something to do with the websocket implementation in glassfish/RI, i think it is called grizzly, but I could be wrong. I'm not as versed with glassfish/RI as I used to be..when I was a glassfish 'user'. :) FYI, at the moment, i'm not writing low level websocket client/server code; i'm using PrimeFaces Push only/entirely, which is PrimeFaces + atmosphere. :) definitely not trying to encourage you to use a certain framework; one thing I like about Tomcat list is that there is a wide range of topics that I can listen to and/or chime-in on, when interested and when feasible. :) I love this user community (mail list).
Re: websockets questions
Howard W. Smith, Jr. wrote: On Thu, Jul 4, 2013 at 1:43 PM, Pierre Goupil wrote: Regarding browser support, a framework like Atmosphere handles pretty well having WebSockets when they are available and falling-back to another Comet implementation (such as long-polling or http-streaming) when they are not. agreed, but I think the goal/desire, here, is to not use Atmosphere. Correct. In truth, we're not sure that we want to use Tomcat either. We're still one level remote of thinking of any implementation, and trying to understand 1) how exactly websockets works 2) if that general "technology" is, today, sufficently mature and stable for us to develop an application based on it, or we should wait another 6 months, a year,.. We know that there are a series of "web application frameworks" which support websockets. Unfortunately, these are not frameworks which we are using right now, and we don't really want to change our tools in the middle of the river. We also know that there are a number of organisations which already use it in production. But we are a small outfit, and the fact that Google may be using it (with a backup team of 50 developers to shore up their implementation) does not really help us. The reason why I put this question on the Tomcat users list is because it is a list I'm subscribed to, because I know that it is a good-quality list with little "noise", because I know that Mark and Rainer are - to various degrees probably - involved in Tomcat support for websockets. So I figured that there was some solid knowledge of the protocol available here. I am also on the Apache httpd list, and I've done some searches on the WWW in general, and for the moment the general information available on websockets seems otherwise a bit "scarce". This being said, the information already gathered here on this list tends to vindicate my posting on it. It has already cleared up a number of points for us, and added a couple of questions which we did not think of asking. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
