I have the following code for custom syslog server (using Syslog4J) which works on Windows.
final UDPNetSyslogServerConfig udpConfig = new UDPNetSyslogServerConfig();
udpConfig.setPort(Integer.parseInt(port));
udpConfig.setHost(host);
udpConfig.addEventHandler(new Handler());
udpConfig.setUseDaemonThread(false);
SyslogServerIF server = SyslogServer.createInstance(host + port, udpConfig);
server.run();
It listens for the incoming events and invokes handler (method) whenever the event is received.
If I run the same code on Mac, it just comes out. Even if I use a loop to wait for the events, the events are not captured.
while (!stop) {
SyslogUtility.sleep(1000);
}
Even the handler's initialize() method is not invoked on Mac.
What port are you trying to use on Mac?
Is it in conflict with an in-use port (default is 514)?
Check /etc/syslog.conf on MacOS to see what port it is using for the built in syslog. On Ubuntu, this can be found in /etc/rsyslog.conf.
Related
I have a standalone zookeeper server running.
client = CuratorFrameworkFactory.newClient(zkHostPorts, retryPolicy);
client.start();
assertThat(client.checkExists().forPath("/")).isNotNull(); // working
listener = new LeaderSelectorListenerAdapter() {
#Override
public void takeLeadership(CuratorFramework client) throws Exception {
System.out.println("This method is never called! :( ");
Thread.sleep(5000);
}
};
String path = "/somepath";
leaderSelector = new LeaderSelector(client, path, listener);
leaderSelector.autoRequeue();
leaderSelector.start();
I am connecting to the server successfully, defining a listener and starting leader election.
Note: There is only 1 client.
But my client app is never taking leadership. I am not able to figure out what I am doing wrong. Also this is a trivial single client scenario. Shouldn't the client already be a leader
EDIT:
It works if I use TestingServer from curator-test library instead of starting my Zookeeper server, like below -
TestingServer server = new TestingServer();
client = CuratorFrameworkFactory.newClient(server.getConnectString(), retryPolicy);
...
Does this mean there is something wrong with my zookeeper server.
This is my zoo.cfg -
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/tmp/zookeeper/ex1
clientPort=2181
Also, the server appears to be working fine as I am able to connect to it using cli and am able to create/delete zNodes.
I have an RMI server which publishes an object like so:
int port = ....;
String name = "...";
Remote server = UnicastRemoteObject.exportObject(someobject, port+1);
Registry registry = LocateRegistry.createRegistry(port);
registry.rebind(name, server);
log.info("created service name "+name+", on port "+(port+1)
+" in registry on port "+port);
When I stop the program and just rerun it, it logs that it has created everything, but then immediately exits, likely due to the rmi server thread exiting (the last non-daemon). I registered a defaultUncaughtExceptionHandler, but get nothing logged from it. Only after a minute or so I am able to restart the program without it immediately exiting.
If I would always use the same port, this would only half surprise me, because I know that ports may be blocked a little while after their last use. But the behavior is the same even if I use a different port (+100 or so) each time.
Any ideas why this happens and how to possible prevent it?
You need to store the result of createRegistry() into a static variable. Otherwise it is liable to be garbage-collected.
when I call a method from a RMI Ubuntu client on the OSX server passing an UnicastRemoteObject as parameter, things are super slow. So slow, that eventually, it gets executed but more likely, I get timeout exceptions after like 2-3 minutes. Both machines are in the same network. It's a freshly installed Ubuntu 12.04. I can telnet from the Ubuntu machine to the OSX one on the used RMI port, so at this point, it doesn't seem to be a problem. I can also call methods on the server without this UnicastRemoteObject parameter and everything works fine. From OSX to OSX is also fine...
This is, how the server gets started:
LocateRegistry.createRegistry(port);
nodeManager = new NodeManagerImpl(maxConfigurationsPerNode, true);
Registry registry = LocateRegistry.getRegistry(host, port);
registry.rebind("NodeManager", nodeManager);
And this is, how the client connects and calls the method:
Registry registry = LocateRegistry.getRegistry(host, port);
nodeManager = (NodeManager) registry.lookup("NodeManager");
handler = new NodeHandlerImpl();
id = nodeManager.register(handler, id);
NodeHandlerImpl is basically this:
public class NodeHandlerImpl extends UnicastRemoteObject implements NodeHandler {
public NodeHandlerImpl(boolean noSSL) throws RemoteException {
super(0, null, null);
}
....
}
The call to "register" is the one taking ages... NodeHandler extends Remote. When I remove the parameter handler, everything works fine again...
I'm a bit stuck here since a few hours, any clue would be great.
// Edit: Yep, Reverse DNS was the error.
With this hint, I found this site:
http://www.communardo.de/home/techblog/2008/09/17/rmi-kommunikation-zu-remote-hosts-mit-unguenstiger-dns-konfiguration/
So I changed my client connect code to the following and everything was fine:
System.setProperty("java.rmi.server.hostname", host);
Registry registry = LocateRegistry.getRegistry(host, port);
nodeManager = (NodeManager) registry.lookup("NodeManager");
handler = new NodeHandlerImpl();
id = nodeManager.register(handler, id);
This is most likely DNS misconfiguration. Java uses both DNS and reverse DNS. Make sure both are working correctly at both client and server hosts when looking up the other.
I'm trying to send Events to the Esper engine through sockets and ran into some problem.
i've configured the EsperIOSocketAdapter properties and when EsperIOSocketAdapter.start() method is invoked , it starts a new daemon thread which will listen for clients , but daemon thread exits as parent thread exits before a socket client actually tries to connect.
my code snippet is as follows:
ConfigurationSocketAdapter adapterConfig = new ConfigurationSocketAdapter();
SocketConfig socket = new SocketConfig();
socket.setDataType(DataType.CSV);
socket.setPort(6789);
adapterConfig.getSockets().put("CourseSocket", socket);
EsperIOSocketAdapter socketAdapter = new EsperIOSocketAdapter (adapterConfig, "CourseSocket");
socketAdapter.start();
Another doubt is in programs without using the SocketAdapter i used to send events through the code
EPRuntime.sendEvent(new TestEvent(event));
While using SocketAdapter, shoud i use sendEvent() or events will automatically pushed into the engine.
Your socket problem seems to be of a generic nature where the JVM is terminating because you do not have any non-daemon threads running. Make the parent thread (or the socket thread) a non-daemon thread and the JVM will not terminate. (Make sure you can actually stop the thread or your JVM will be stubborn about shutting down :) )
When you use the SocketAdapter, your "sending client" is remote to the physical EPRuntime, but you use the remote socket to send events over the socket, as outlined in the docs.
Using RMI to pass String object from WebAppA to WebAppB.WebAppB is the RMIServer whereas WebAppA is RMIClient.I have added ContextListener in WebAppB, so that the rmi service starts right away when the context is initialized in tomcat.And in the contextDestroyed method of tomcat I am trying to close/shut down rmi using the following statements:
unexportObject(remoteObj,true);
LocateRegistry.getRegistry(3232).unbind("MessagePath"); //MessagePath - name of the remote reference
But even after the execution of the aforeseen statements, rmi is listening for incoming requests at port 3232.I saw that by using "netsat -ano" in command prompt.Please do help me to close RMI Service.
getRegistry returns a stub only, so use the instance returned by createRegistry in unexportObject. However in my case this does not help either - the registry is not active anymore, but the sockets are still open and listening :-(
createRegistry won't work when you're trying to shutdown the registry.
Registry registry = LocateRegistry.createRegistry(3232);
This will throw a BindException when the registry is already running. So you cannot the create object to use it in
UnicastRemoteObject.unexportObject(registry, true);
However, even if you use
Registry registry = LocateRegistry.getRegistry(3232);
You just get the stub, which cannot be used as a parameter to unexport the object.
The reason its a cause of concern for me is because I only wish to start the registry if I could check it has not started yet. And I haven't found a way to do that!
I have found a way of shutting down the registry from any process (and for that matter shutting down any bound processes which are bound in the registry)
Any of the Interfaces which extends remote and which you eventually want to kill off should also extend the following Interface:
public interface PIDSupplierInterface extends Remote {
String getPID() throws RemoteException;
}
every server class you create with this as part of its interface must then implement getPID(). The thing you then have to do is return the process ID. Google "getpids" for Windows, or go here: www.jroller.com/santhosh/entry/get_current_java_process_id. For Linux as I understand it getting the PID is more straightforward. Then (in Windows) you want to go
String PID = myServer.getPID();
String[] a_command = { "taskkill", "/pid", PID };
Runtime.getRuntime().exec(a_command, envp, dir);
to kill off the PID of the registry itself, first, when starting the registry (programatically), simply go
PIDSupplierInterface stub = PIDSupplierInterface)UnicastRemoteObject.exportObject(
new PIDSupplierServer(), 0);
reg.bind( "regKiller", stub );
where PIDSupplierServer is a class which implements only PIDSupplierInterface.
Then, when you want to kill off the RMI registry from any Process just go
PIDSupplierInterface regProcess = (PIDSupplierInterface)reg.lookup( "regKiller" );
String regPID = regProcess.getPID();
String[] a_command = { "taskkill", "/pid", regPID };
Runtime.getRuntime().exec(a_command, envp, dir);
the reg has disappeared from your system. Or is your question more complicated for some reason? Any comments welcome.