We Keep Coding

Two Threads Executing Same Method

I am developing an API request and I'm using multi threading.In the output I'm getting the same request twice generated by two threads.As I debugged two thread are calling the same method again.So need help so that this issue is resolved
This is my pseudo code
public void run() {
logger.debug("Thread " + currentThread().getName() + " Running");
String message = "";
Connection connection = null;
InputStream fileinput = null;
Properties properties = new Properties();
try {
File file = new File("/home/sridhar.anirudh/eclipse-workspace/API/Change.properties");
fileinput = new FileInputStream(file);
properties.load(fileinput);
soapEndpointUrl = properties.getProperty("endpoint_url");
soapAction = properties.getProperty("soap_action");
} catch (Exception e) {
e.printStackTrace();
}
try {
connection = Database.getInstance().getConnection();
} catch (SQLException e1) {
logger.error("Failed To Get Connection " + e1.getMessage());
return;
}
if (CATEGORY.equalsIgnoreCase("fraudrestriction")) {
String soapResponse = callSoapWebServiceFraudRestriction(soapEndpointUrl, soapAction);
String response_status = "";
if (soapResponse.contains("<tns:Description>SUCCESS</tns:Description>") &&
soapResponse.contains("<tns:Code>ERR_000</tns:Code>")) {
response_status = "SUCCESS";

If you kick off two copies of the thread, they will both run, creating the effect you see.
You can create multiple worker threads, but you need to allocate the work between those workers such that each performs a subset of the total workload.
Since you're (seemingly) parsing and processing a file, and making a network service request in response to that file's contents, it's not clear how you intend to divide up the work. That's the key; to use multiple threads to improve throughput, you the programmer must devise a means of partitioning the work between those threads.
As an analogy, if you have one (human) worker working on a job, simply hiring a second worker won't get the job completed any faster unless the work is divided between those workers. That division is your problem. There's nothing magical about threads that can do this for you.

ZeroMQ PUB/SUB topology on the same machine

Is it possible for a publisher to publish to multiple clients on the same machine using ZeroMQ? I'd like a set of clients, each of which can make standard Request/Response calls using SocketType.REQ and SocketType.REP, but which can also receive notifications using SocketType.SUB and SocketType.PUB.
I've tried to implement this topology, taken from here, although my version only has one publisher.
Here is my publisher:
public class ZMQServerSmall
{
public static void main(String[] args)
{
try (ZContext context = new ZContext())
{
ZMQ.Socket rep = context.createSocket(SocketType.REP);
rep.bind("tcp://*:5555");
ZMQ.Socket pub = context.createSocket(SocketType.PUB);
pub.bind("tcp://*:7777");
while (!Thread.currentThread().isInterrupted())
{
String req = rep.recvStr(0);
rep.send(req + " response");
pub.sendMore("Message header");
pub.send("Message body");;
}
}
}
}
Here is my proxy (I included a Listener to try to see what's going on):
public class ZMQForwarderSmall
{
public static void main(String[] args)
{
try
(
ZContext context = new ZContext();
)
{
ZMQ.Socket frontend = context.createSocket(SocketType.XSUB);
frontend.connect("tcp://*:7777");
ZMQ.Socket backend = context.createSocket(SocketType.XPUB);
backend.bind("tcp://*:6666");
IAttachedRunnable runnable = new Listener();
Socket listener = ZThread.fork(context, runnable);
ZMQ.proxy(frontend, backend, listener);
}
catch (Exception e)
{
System.err.println(e.getMessage());
}
}
private static class Listener implements IAttachedRunnable
{
#Override
public void run(Object[] args, ZContext ctx, Socket pipe)
{
while (true)
{
ZFrame frame = ZFrame.recvFrame(pipe);
if (frame == null)
break; // Interrupted
System.out.println(frame.toString());
frame.destroy();
}
}
}
}
Here is my Subscriber:
public class ZMQClientSmall
{
public static void main(String[] args) throws IOException
{
String input;
try
(
ZContext context = new ZContext();
BufferedReader stdIn = new BufferedReader(new InputStreamReader(System.in))
)
{
ZMQ.Socket reqSocket = context.createSocket(SocketType.REQ);
reqSocket.connect("tcp://localhost:5555");
ZMQ.Socket subSocket = context.createSocket(SocketType.SUB);
subSocket.connect("tcp://localhost:6666");
subSocket.subscribe("".getBytes(ZMQ.CHARSET));
while ((input = stdIn.readLine()) != null)
{
reqSocket.send(input.getBytes(ZMQ.CHARSET), 0);
String response = reqSocket.recvStr(0);
String address = subSocket.recvStr(ZMQ.DONTWAIT);
String contents = subSocket.recvStr(ZMQ.DONTWAIT);
System.out.println("Notification received: " + address + " : " + contents);
}
}
}
}
Here is the test. I open four terminals; 1 publisher, 1 proxy, and 2 clients. When I make a request in either of the two client terminals, I expect to see a notification in both, but instead I only see the notification in the terminal that made the request. I know that both clients are using the same address (localhost:6666), but I'd hoped that the proxy would solve that problem.
Can anyone see anything obviously wrong here?

Q : Is it possible for a publisher to publish to multiple clients on the same machine using ZeroMQ?
Oh sure, it is. No doubts about that.
Check the code. The responsibility of the order-of-execution is there. In distributed-systems this always so.
Once the [Client]-No1 instance gets a plausible .readLine()-ed input it will jump-in:
while ((input = stdIn.readLine()) != null)
{
reqSocket.send(input.getBytes(ZMQ.CHARSET), 0);
String response = reqSocket.recvStr(0);
String address = subSocket.recvStr(ZMQ.DONTWAIT);
String contents = subSocket.recvStr(ZMQ.DONTWAIT);
System.out.println( "Notification received: "
+ address + " : "
+ contents
);
}
Next it .send()-s over REQ and blocks (awaiting REP response)
Given the [Client]-No2 instance also gets a plausible manual .readLine()-ed input it will jump-in the same while(){...}, yet it will not proceed any farther than into again blocking wait for REP-response. That will not get .recv()-ed any time but after the -No1 got served from the REP-side, so while the -No1 might have gotten out of the blocking-.recv(), not so the -No2 ( which will still hang inside the its blocking-.recv() for any next REP-side response ( which may come but need not ), while the No1 has already proceeded to the PUB/SUB-.recv(), which it will receive ( but never the No2 ), next rushing into the next blocking-input-feed from .readLine() Et Cetera, Et Cetera, Et Cetera, ..., Ad Infinitum
So, these SEQ-of-In-Loop (REQ)-parts followed by (SUB)-parts in whatever number N > 1 of [Client]-instances, have effectively generated an EXCLUSIVE Tick-Tock-Tick-Tock clock-machine, mutually blocking an exclusive delivery of the PUB-ed in an N-interleaved order ( not speaking about the manual, .readLine()-driven, blocking step )
The ZMQServerSmall is not aware about anything wrong, as it .send()-s in-order to any .recvStr()-ed counterparty over REQ/REP and PUB-s to all counterparties ( that do not read autonomously, but only after 've been manually .readLine() unblocked and only then ( after REQ/REP episodic ( potentially infinitely blocked ) steps ) may .recv() its next ( so far not read message-part ( yet, there I do not see any code that works with explicitly handling the presence / absence of the multipart-flags on the SUB-side .recv() operations )
while (!Thread.currentThread().isInterrupted())
{
String req = rep.recvStr(0);
rep.send(req + " response");
pub.sendMore("Message header");
pub.send("Message body");;
}
The ZMQServerSmall in the meantime sends ( N - 1 )-times more messages down the PUB-broadcast lane, so the Tick-Tock-Tick-Tock MUTEX REQ/SUB-loop-blocking "pendulum" is not 2-State, but N-State on the receiving sides ( all receive the same flow of PUB-ed messages,yet interleaved by the N-steps of the REQ/REP MUTEX-stepping )

java infinite loop calling datainputstream receives out of memory exception

I have the following infinite loop which listens for incoming messages:
public static void listenForMessages(){
while (true) {
dsocket.receive(receivepacket);
byte[] rcvMsg = receivepacket.getData();
MessageCreator tmc = new MessageCreator();
TrafficMessage message = tmc.constructMessageFromBinary(rcvMsg);
System.out.println("message: "+message);
}
}
This calls a method that reads the byte array into a string and populates a message object.
public Message constructMessageFromBinary(byte[] rcvMsg)
throws IOException {
ByteArrayInputStream bais = new ByteArrayInputStream(rcvMsg);
DataInputStream dis = new DataInputStream(bais);
StringBuffer inputLine = new StringBuffer();
String tmp;
while ((tmp = dis.readLine()) != null) {
inputLine.append(tmp);
}
dis.close();
Message message = new Message();
message.setDescriptions(tmp);
return message;
}
This simple process slowly leaks memory over a few hours and I receive an out of memory exception.
Is there anything wrong with this logic?

The problem was that I left a database connection open. I wanted to leave it open to pass data with out having to worry about stopping and starting connections. I now open and close connections each time and all is good.

The best bet here would be to move all possible object instantiations outside the loops. For example, in the first code snippet, every iteration creates a
MessageCreator tmc.
On your second snippet, each call to the method creates a
StringBuffer inputLine.
This instantiation process may be eating away your memory slowly.

IndexOutOfBoundException when reading a file

I am working on a TFTP server application. I managed to process a successful file transfer from server to client however the other way around is bugged.
Client instead of transmitting the entire file simply terminated whit compiler returning no errors. Debugger shows IOBE exception on the marked code referring that the array is out of range.
The whole transfer process goes like so:
Client transmits a file name and requested operation WRQ - Write Request
Server received the packet and determines the operation if WRQ is gives the new file appropriate name.
Server now starts executing receiveData() until it gets a packet < 512 indicationg EOT
Client keeps transferring data it read from the file.
Key code:
Client:
private void sendWRQ() throws Exception
{
String rrq = "WRQ-" + data;
outgoingData = rrq.getBytes();
DatagramPacket output = new DatagramPacket(outgoingData, outgoingData.length, serverAddress, serverPort);
clientSocket.send(output);
//Thread.sleep(50);
sendData();
}
byte outgoingData = new byte[512];
private void sendData() throws Exception
{
DatagramPacket dataTransfer = new DatagramPacket(outgoingData, outgoingData.length, serverAddress, serverPort);
InputStream fis = new FileInputStream(new File(data));
int x;
while((x = fis.read(outgoingData,0,512)) != -1) // << Debugged gives IOBE
{
dataTransfer.setLength(x);
clientSocket.send(dataTransfer);
Thread.sleep(5);
}
fis.close();
}
Server:
private void listen() throws Exception
{
DatagramPacket incTransfer = new DatagramPacket(incomingData, incomingData.length);
serverSocket.receive(incTransfer);
clientAddress = incTransfer.getAddress();
clientPort = incTransfer.getPort();
String output = new String(incTransfer.getData());
if(output.substring(0, 3).equals("RRQ"))
{
File test = new File(output.substring(4));
responseData = output.substring(4);
if(test.exists())
{
sendResponse("Y");
} else {
sendResponse("N");
}
} else if (output.substring(0, 3).equals("WRQ"))
{
File test = new File(output.substring(4));
if(test.exists())
{
Calendar cal = Calendar.getInstance();
SimpleDateFormat prefix = new SimpleDateFormat(date_format);
String date = prefix.format(cal.getTime()).toString();
responseData = date + output.substring(4);
receiveData();
} else {
responseData = output.substring(4);
receiveData();
}
}
}
private void receiveData() throws Exception
{
DatagramPacket receiveData = new DatagramPacket(incomingData, incomingData.length);
OutputStream fos = new FileOutputStream(new File(responseData));
while(true)
{
serverSocket.receive(receiveData);
if(receiveData.getLength() == 512)
{
fos.write(receiveData.getData());
} else {
fos.write(receiveData.getData(), receiveData.getOffset(), receiveData.getLength());
break;
}
}
fos.close();
}

The only way that can happen is if the offset or length parameters violate the constraints specified for InputStream.read(byte[], int, int); in this case probably the buffer isn't 512 bytes long. There's no need to specify the 2nd nd third parameters in this case, just omit them, then it becomes read(buffer, 0, buffer.length) internally, which can't be wrong.

Okay, the way this is coded, the 'outgoingData' field is:
1) Initialized to a length of 512
2) Then, in sendWRQ(), 'outgoingData' is re-initialized to whatever rrq.getBytes() sends back.
3) Then, in sendData(), 'outgoingData' is used as the intermediate buffer to read data from file and put it in the dataTransfer object.
However, since 'outgoingData' is re-initialized in step #2, the assumption in step #3 that 'outgoingData' is still 512 bytes in length is false.
So while EJP was correct in saying that using read(outgoingData, 0, outgoingData.length()) will work, there are some architecture issues that if you address, you'll clean up a lot of potential errors.
For instance:
WIth the code provided, there is seemingly no reason to have outgoingData declared at the class level and shared among two functions. Depending on the rest of the app, this could end up being a Threading issue.
Perhaps byte[] buffer = rrq.getBytes(); in sendWRQ() and byte[] buffer = new byte[1024]; in sendData().
Also, the 'data' parameter is at the class level.... for what reason? Might be better able to be controlled if its a passed in parameter.
Lastly, I've had good luck using the do{} while() loop in network situations. Ensures that the send() gets at least one chance to send the data AND it keeps the code a bit more readable.

trouble with StringTokenizer

I'm getting the following error message and I can't seem to figure out the problem. Would really appreciate any help. The error message reads as:-
BaseStaInstance.java:68: cannot find symbol
symbol : constructor StringTokenizer(java.lang.Object,java.lang.String)
location: class java.util.StringTokenizer
st = new StringTokenizer(buf,",");
^
Here, BaseStaInstance is my main public class.
The class that implements this StringTokenizer is as follows:-
class ServerConnect extends Thread {
Socket skt;
int iProcessId, iInProcessId;
int iOwnTimeStamp, iInTimeStamp;
ServerConnect scnt = null;
ObjectOutputStream myOutput;
ObjectInputStream myInput;
ServerConnect(){}
ServerConnect(Socket connection, int iProcessNo) {
this.skt = connection;
this.iProcessId = iProcessNo;
}
public void run() {
try {
//initialize the object "scnt" using the parameterized constructor
ServerConnect scnt = new ServerConnect(skt, iProcessId);
myInput = new ObjectInputStream(skt.getInputStream());
while(true) {
try{
iOwnTimeStamp = Global.iTimeStamp;
Object buf = myInput.readObject();
//if we got input, print it out and write a message back to the remote client...
if(buf != null){
scnt.replyChoice(buf);
}
}catch(ClassNotFoundException e) {
e.printStackTrace();
}
}
} catch(IOException e) {
e.printStackTrace();
}
}
void replyChoice(Object buf){
try{
String sDeferReply = "";
myOutput = new ObjectOutputStream(skt.getOutputStream());
//the place where the basestation reads the request from the other basestation
System.out.println("Server read:[ "+buf+" ]");
//extract out the process id and the timestamp from the incoming request
buf = buf.toString();
***StringTokenizer st = new StringTokenizer(buf,",");***
//skip the word request
st.nextToken();
iInProcessId = Integer.parseInt(st.nextToken());
iInTimeStamp = Integer.parseInt(st.nextToken());
//check request is made
//there is a possibility of entering the else loop only on the very first iteration
//the control flows into the if loop even if one request has been made
if(iOwnTimeStamp != 0){
//if the incoming request has a larger timestamp (logical clock value, process id) than the current process, we defer the reply
if(iOwnTimeStamp < iInTimeStamp || iProcessId < iInProcessId){
sDeferReply="iInTimeStamp"+","+"iInProcessId";
Global.v.addElement(new String(sDeferReply));
}
//incoming request has a smaller timestamp than the basestation request itself
else{
myOutput.writeObject("Reply");
myOutput.flush();
}
}
//if the current process is in the critical section then we defer replies
else if(Global.iCriticalSection==1){
sDeferReply="iInTimeStamp"+","+"iInProcessId";
Global.v.addElement(new String(sDeferReply));
}
//start of execution of the thread, there is a possibility that the basestation hasn't issued a request
else{
myOutput.writeObject("Reply");
myOutput.flush();
}
}catch(IOException e){
e.printStackTrace();
}
}
}
The part that implements the StringTokenizer function has *** surrounding it.
Thanks in advance to anyone who might be able to help me out.

Try
StringTokenizer st = new StringTokenizer((String) buf,",");
The reason why you're getting that error is because buf, while referring to a String at that point, is still of type Object.
As an additional tip, you really should make the effort to try to understand the error message given by the compiler. Look at the following:
cannot find symbol constructor StringTokenizer(java.lang.Object,java.lang.String)
location: class java.util.StringTokenizer st = new StringTokenizer(buf,",");
Compiler error messages don't always make sense, but this is as good as it gets. It tells you that:
It found the right type, java.util.StringTokenizer, so it's not an import or name obscuring problem, etc.
It's telling you that a specific method with the given signature can not be found. Indeed, a quick check with the API confirms that StringTokenizer does NOT have a constructor that takes a (java.lang.Object, java.lang.String).
It's telling you exactly the line of code in your program that tries to invoke this non-existent method. And indeed, the type of your first argument is a java.lang.Object, and the type of your second argument is a java.lang.String!!!
That was how I was able to quickly pinpoint the problem in the source code and suggest a quick fix.
Being able to process error messages given by the compiler is an essential skill that you must develop, so I hope this proves to be an educational experience for you.