I am trying to continuously poll an NFC tag using an android phone (OnePlus 6T if it's relevant). When my tag is only powered by NFC, I get null values even though the debugger shows the payload being not null and supposedly correctly formatted (screenshot below).
Debugger output when getNdefMessage returns null
Debugger output when the returned value is not null
The code I am using to poll the tag, based on Continuously detect an NFC tag on Android and Is it possible to read an NFC tag from a card without using an intent?
protected void onResume() {
super.onResume();
if (nfcAdapter != null) {
if (!nfcAdapter.isEnabled()) {
Intent intent = new Intent(Settings.ACTION_WIRELESS_SETTINGS);
startActivity(intent);
}
Bundle options = new Bundle();
options.putInt(NfcAdapter.EXTRA_READER_PRESENCE_CHECK_DELAY, 250);
nfcAdapter.enableReaderMode(this, new NfcAdapter.ReaderCallback() {
#Override
public void onTagDiscovered(Tag tag) {
Log.d("Tag", "New tag detected, attempting connect");
readMessage(tag);
tagInRange = true;
}
},
NfcAdapter.FLAG_READER_NFC_A
| NfcAdapter.FLAG_READER_NO_PLATFORM_SOUNDS, options);
}
}
Read message function, msg variable is a private volatile NdefMessage:
private void readMessage(Tag tag) {
Log.d("Tag", "Starting thread");
new Thread(() -> {
try {
Thread.sleep(1800);
} catch (InterruptedException e) {
e.printStackTrace();
}
final Ndef ndef = Ndef.get(tag);
Log.d("Tag", "New tag detected, attempting connect");
while (tagInRange) {
try {
ndef.connect();
msg = ndef.getNdefMessage();
Log.d("Tag", "Running on UI thread");
if (msg == null) {
Log.d("Tag", String.valueOf(ndef));
continue;
}
runOnUiThread(() -> {
parseMessage(msg);
dataElapsedTime += 0.2;
});
} catch (IOException | FormatException e) {
e.printStackTrace();
tagInRange = false;
System.out.println("Tag Connection Lost");
}
finally {
try {
ndef.close();
Log.d("tag", "Tag connection closed successfully");
} catch (IOException e) {
e.printStackTrace();
}
}
}
}).start();
}
Does the getNdefMessage function use some sort of lazy loading? Or is this the result of multiple threads being spawned and some strange race condition occurring?
Update 2
Looking at the source of the ndef object the mNdefMsg you highlighted is the cached Ndef message that the System Reads before passing you the Tag object
As you seem have a custom behaving tag and may be this tag won't allow you to read the same data twice without going through a disconnect/connect mechanism.
Based on you debug data I would use ndef.getCachedNdefMessage() to read this data you are highlighting but this might not get you want you want.
Some Background, when the Android NFC service detects a Tag normally it tries to read and Ndef message from it as it might need to parse the Ndef message itself.
When you call ndef.getNdefMessage() it actually re-reads the data directly from the Tag and ignores what the System NFC service has previous read.
I would try enabling FLAG_READER_SKIP_NDEF_CHECK to stop the system reading the Ndef Message and using up you one chance to read the custom Tag .
So try add that flag e.g.
nfcAdapter.enableReaderMode(this, new NfcAdapter.ReaderCallback() {
#Override
public void onTagDiscovered(Tag tag) {
Log.d("Tag", "New tag detected, attempting connect");
readMessage(tag);
tagInRange = true;
}
},
NfcAdapter.FLAG_READER_NFC_A
| NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK
| NfcAdapter.FLAG_READER_NO_PLATFORM_SOUNDS, options);
Original
I think the problem is your ndef.close() is in the wrong place.
You should not close the tag unless you never want to communicate with it again.
At the moment on the first iteration of the while loop, it does the try block with the ndef.connect(); and the finally is always executed after the code in the preceding try block.
Really you should only ndef.close() outside the while block.
Adjusted code (You should also catch the TagLostException from getNdefMessage )
private void readMessage(Tag tag) {
Log.d("Tag", "Starting thread");
new Thread(() -> {
try {
Thread.sleep(1800);
} catch (InterruptedException e) {
e.printStackTrace();
}
final Ndef ndef = Ndef.get(tag);
Log.d("Tag", "New tag detected, attempting connect");
try {
ndef.connect();
} catch (IOException e) {
e.printStackTrace();
tagInRange = false;
System.out.println("Failed to Connect");
}
while (tagInRange) {
try {
msg = ndef.getNdefMessage();
Log.d("Tag", "Running on UI thread");
if (msg == null) {
Log.d("Tag", String.valueOf(ndef));
continue;
}
runOnUiThread(() -> {
parseMessage(msg);
dataElapsedTime += 0.2;
});
} catch (TagLostException | IOException | FormatException e) {
e.printStackTrace();
tagInRange = false;
System.out.println("Tag Connection Lost");
}
}
// End of while loop try close just on the safe side
try {
ndef.close();
Log.d("tag", "Tag connection closed successfully");
} catch (IOException e) {
e.printStackTrace();
}
}).start();
}
Note you might think the raw tag debug output still has an Ndef Message in it, but as you have not disabled FLAG_READER_SKIP_NDEF_CHECK then this is probably the cached data for ndef.getCachedNdefMessage()
If you look at the docs for ndef.getCachedNdefMessage you will see that it says that it causes no RF activity as this just returns the NDEF message that the System NFC read when it first detected the Tag and passed to you in the Tag Object.
Where as getNdefMessage cause I/O (RF) activity and reads the current Ndef message at time of calling (which might be different to the one the system read previously)
Update
I seem to remember you cannot call connect() multiple times and and the docs say "Only one TagTechnology object can be connected to a Tag at a time. " even though it is the same Tag tech it is probably not the same instance, so in the example I've moved connect out of the while loop.
This issue was finally resolved by understanding the following things:
The mNdefmessage variable in the ndef object corresponds to the cached message and would remain unchanged as long as the same tag instance is connected. I was reading the object wrong and presuming that that is the message I want. Thanks to Andrew for pointing this out!
The null I was receiving was not a result of where the connect/close were called and the android code needed minimal changes from what was initially posted. In the documentation for the function getNdefMessage(), it says, function may return null if tag is initialised stage. This turned out to be the real issue, which was only spotted when I set my tag (NHS3152) to blink an LED when starting up and noticed it was restarting several times after taking a set of readings from a connected resistor which shouldn't be happening (this also led to a lot of tag lost/null object exceptions).
Since the documentation on this is scanty, the reason the tag was restarting/reset turned out to be its inability to handle voltages over a certain threshold on its output pins when powered by the NFC field only and connected to a load. This led to the strange scenario of everything working just fine when the tag was being read while connected to a debugging board (LPCLink2) or being powered by the NFC but not connected to a load. This was finally addressed by changing the output voltage on the DAC pin.
I'm trying to send messages using the Discord JDA API, however whenever I send one, it sends it infinitely.
JDA Version: 4.2.1_255
What I've Tried:
Research the issue
Use GuildMessageReceivedEvent instead of MessageReceivedEvent
Pseudo-Code:
Guild server = e.getGuild();
Role role = server.getRolesByName("Java", false).get(0);
System.out.println(role);
for(Member members : server.getMembers()) {
if(members.getRoles().contains(role)) {
sendPrivateMessage(members.getUser(), "Hello <#!" + members.getId() + ">"); // Sends infinitely
}
}
sendPrivateMessage():
public void sendPrivateMessage(User user, String content) {
user.openPrivateChannel()
.flatMap(channel -> channel.sendMessage(content))
.queue();
}
You can try this
public void sendPrivateMessage(User user, String content) {
if (user.isBot()) return;
user.openPrivateChannel()
.flatMap(channel -> channel.sendMessage(content))
.queue();
}
if this code gets executed in the MessageReceivedEvent you may try adding
if(event.getAuthor().isBot()){
return;
}
so that it wont reply itself if you haven't already.
(If you want it to answer to other bots, you can also use the JDA, to get the selfUser and check if this event got executed by itself)
If thats not the case maybe you could tell us more about when it gets executed.
Sometime I see many application such as msn, windows media player etc that are single instance applications (when user executes while application is running a new application instance will not created).
In C#, I use Mutex class for this but I don't know how to do this in Java.
I use the following method in the main method. This is the simplest, most robust, and least intrusive method I have seen so I thought that I'd share it.
private static boolean lockInstance(final String lockFile) {
try {
final File file = new File(lockFile);
final RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
final FileLock fileLock = randomAccessFile.getChannel().tryLock();
if (fileLock != null) {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
try {
fileLock.release();
randomAccessFile.close();
file.delete();
} catch (Exception e) {
log.error("Unable to remove lock file: " + lockFile, e);
}
}
});
return true;
}
} catch (Exception e) {
log.error("Unable to create and/or lock file: " + lockFile, e);
}
return false;
}
If I believe this article, by :
having the first instance attempt to open a listening socket on the localhost interface. If it's able to open the socket, it is assumed that this is the first instance of the application to be launched. If not, the assumption is that an instance of this application is already running. The new instance must notify the existing instance that a launch was attempted, then exit. The existing instance takes over after receiving the notification and fires an event to the listener that handles the action.
Note: Ahe mentions in the comment that using InetAddress.getLocalHost() can be tricky:
it does not work as expected in DHCP-environment because address returned depends on whether the computer has network access.
Solution was to open connection with InetAddress.getByAddress(new byte[] {127, 0, 0, 1});
Probably related to bug 4435662.
I also found bug 4665037 which reports than Expected results of getLocalHost: return IP address of machine, vs. Actual results : return 127.0.0.1.
it is surprising to have getLocalHost return 127.0.0.1 on Linux but not on windows.
Or you may use ManagementFactory object. As explained here:
The getMonitoredVMs(int processPid) method receives as parameter the current application PID, and catch the application name that is called from command line, for example, the application was started from c:\java\app\test.jar path, then the value variable is "c:\\java\\app\\test.jar". This way, we will catch just application name on the line 17 of the code below.
After that, we search JVM for another process with the same name, if we found it and the application PID is different, it means that is the second application instance.
JNLP offers also a SingleInstanceListener
If the app. has a GUI, launch it with JWS and use the SingleInstanceService.
Update
The Java Plug-In (required for both applets and JWS apps) was deprecated by Oracle and removed from the JDK. Browser manufacturers had already removed it from their browsers.
So this answer is defunct. Only leaving it here to warn people looking at old documentation.
You can use JUnique library. It provides support for running single-instance java application and is open-source.
http://www.sauronsoftware.it/projects/junique/
The JUnique library can be used to prevent a user to run at the same
time more instances of the same Java application.
JUnique implements locks and communication channels shared between all
the JVM instances launched by the same user.
public static void main(String[] args) {
String appId = "myapplicationid";
boolean alreadyRunning;
try {
JUnique.acquireLock(appId, new MessageHandler() {
public String handle(String message) {
// A brand new argument received! Handle it!
return null;
}
});
alreadyRunning = false;
} catch (AlreadyLockedException e) {
alreadyRunning = true;
}
if (!alreadyRunning) {
// Start sequence here
} else {
for (int i = 0; i < args.length; i++) {
JUnique.sendMessage(appId, args[0]));
}
}
}
Under the hood, it creates file locks in %USER_DATA%/.junique folder and creates a server socket at random port for each unique appId that allows sending/receiving messages between java applications.
I have found a solution, a bit cartoonish explanation, but still works in most cases. It uses the plain old lock file creating stuff, but in a quite different view:
http://javalandscape.blogspot.com/2008/07/single-instance-from-your-application.html
I think it will be a help to those with a strict firewall setting.
Yes this is a really decent answer for eclipse RCP eclipse single instance application
below is my code
in application.java
if(!isFileshipAlreadyRunning()){
MessageDialog.openError(display.getActiveShell(), "Fileship already running", "Another instance of this application is already running. Exiting.");
return IApplication.EXIT_OK;
}
private static boolean isFileshipAlreadyRunning() {
// socket concept is shown at http://www.rbgrn.net/content/43-java-single-application-instance
// but this one is really great
try {
final File file = new File("FileshipReserved.txt");
final RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
final FileLock fileLock = randomAccessFile.getChannel().tryLock();
if (fileLock != null) {
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
try {
fileLock.release();
randomAccessFile.close();
file.delete();
} catch (Exception e) {
//log.error("Unable to remove lock file: " + lockFile, e);
}
}
});
return true;
}
} catch (Exception e) {
// log.error("Unable to create and/or lock file: " + lockFile, e);
}
return false;
}
We use file locking for this (grab an exclusive lock on a magic file in the user's app data directory), but we are primarily interested in preventing multiple instances from ever running.
If you are trying to have the second instance pass command line args, etc... to the first instance, then using a socket connection on localhost will be killing two birds with one stone. General algorithm:
On launch, try to open listener on port XXXX on localhost
if fail, open a writer to that port on localhost and send the command line args, then shutdown
otherwise, listen on port XXXXX on localhost. When receive command line args, process them as if the app was launched with that command line.
On Windows, you can use launch4j.
A more generic way of limiting the number of instance's on a single machine, or even an entire network, is to use a multicast socket.
Using a multicast socket, enables you to broadcast a message to any amount of instances of your application, some of which can be on physically remote machines across a corporate network.
In this way you can enable many types of configurations, to control things like
One or Many instances per machine
One or Many instances per network (eg controlling installs on a client site)
Java's multicast support is via java.net package with MulticastSocket & DatagramSocket being the main tools.
Note: MulticastSocket's do not guarantee delivery of data packets, so you should use a tool built on top of multicast sockets like JGroups. JGroups does guarantee delivery of all data. It is one single jar file, with a very simple API.
JGroups has been around a while, and has some impressive usages in industry, for example it underpins JBoss's clustering mechanism do broadcast data to all instance of a cluster.
To use JGroups, to limit the number of instances of an app (on a machine or a network, lets say: to the number of licences a customer has bought) is conceptually very simple :
Upon startup of your application, each instance tries to join a named group eg "My Great App Group". You will have configured this group to allow 0, 1 or N members
When the group member count is greater than what you have configured for it.. your app should refuse to start up.
You can open a Memory Mapped File and then see if that file is OPEN already. if it is already open, you can return from main.
Other ways is to use lock files(standard unix practice). One more way is to put something into the clipboard when main starts after checking if something is already in the clipboard.
Else, you can open a socket in a listen mode(ServerSocket). First try to connect to hte socket ; if you cannot connect, then open a serversocket. if you connect, then you know that another instance is already running.
So, pretty much any system resource can be used for knowing that an app is running.
BR,
~A
ManagementFactory class supported in J2SE 5.0 or later detail
but now i use J2SE 1.4 and I found this one http://audiprimadhanty.wordpress.com/2008/06/30/ensuring-one-instance-of-application-running-at-one-time/ but I never test. What do you think about it?
The Unique4j library can be used for running a single instance of a Java application and pass messages. You can see it at https://github.com/prat-man/unique4j. It supports Java 1.6+.
It uses a combination of file locks and dynamic port locks to detect and communicate between instances with the primary goal of allowing only one instance to run.
Following is a simple example of the same:
import tk.pratanumandal.unique4j.Unique4j;
import tk.pratanumandal.unique4j.exception.Unique4jException;
public class Unique4jDemo {
// unique application ID
public static String APP_ID = "tk.pratanumandal.unique4j-mlsdvo-20191511-#j.6";
public static void main(String[] args) throws Unique4jException, InterruptedException {
// create unique instance
Unique4j unique = new Unique4j(APP_ID) {
#Override
public void receiveMessage(String message) {
// display received message from subsequent instance
System.out.println(message);
}
#Override
public String sendMessage() {
// send message to first instance
return "Hello World!";
}
};
// try to obtain lock
boolean lockFlag = unique.acquireLock();
// sleep the main thread for 30 seconds to simulate long running tasks
Thread.sleep(30000);
// try to free the lock before exiting program
boolean lockFreeFlag = unique.freeLock();
}
}
Disclaimer: I created and maintain Unique4j library.
I wrote a dedicated library for that https://sanyarnd.github.io/applocker
It is based on file-channel locking, so it will not block a port number, or deadlock application in case of power outage (channel is released once process is terminated).
Library is lightweight itself and has a fluent API.
It was inspired by http://www.sauronsoftware.it/projects/junique/, but it's based on file channels instead. And there are other extra new features.
You could try using the Preferences API. It is platform independent.
I used sockets for that and depending if the application is on the client side or server side the behavior is a bit different:
client side : if an instance already exists(I cannot listen on a specific port) I will pass the application parameters and exit(you may want to perform some actions in the previous instance) if not I will start the application.
server side : if an instance already exists I will print a message and exit, if not I will start the application.
public class SingleInstance {
public static final String LOCK = System.getProperty("user.home") + File.separator + "test.lock";
public static final String PIPE = System.getProperty("user.home") + File.separator + "test.pipe";
private static JFrame frame = null;
public static void main(String[] args) {
try {
FileChannel lockChannel = new RandomAccessFile(LOCK, "rw").getChannel();
FileLock flk = null;
try {
flk = lockChannel.tryLock();
} catch(Throwable t) {
t.printStackTrace();
}
if (flk == null || !flk.isValid()) {
System.out.println("alread running, leaving a message to pipe and quitting...");
FileChannel pipeChannel = null;
try {
pipeChannel = new RandomAccessFile(PIPE, "rw").getChannel();
MappedByteBuffer bb = pipeChannel.map(FileChannel.MapMode.READ_WRITE, 0, 1);
bb.put(0, (byte)1);
bb.force();
} catch (Throwable t) {
t.printStackTrace();
} finally {
if (pipeChannel != null) {
try {
pipeChannel.close();
} catch (Throwable t) {
t.printStackTrace();
}
}
}
System.exit(0);
}
//We do not release the lock and close the channel here,
// which will be done after the application crashes or closes normally.
SwingUtilities.invokeLater(
new Runnable() {
public void run() {
createAndShowGUI();
}
}
);
FileChannel pipeChannel = null;
try {
pipeChannel = new RandomAccessFile(PIPE, "rw").getChannel();
MappedByteBuffer bb = pipeChannel.map(FileChannel.MapMode.READ_WRITE, 0, 1);
while (true) {
byte b = bb.get(0);
if (b > 0) {
bb.put(0, (byte)0);
bb.force();
SwingUtilities.invokeLater(
new Runnable() {
public void run() {
frame.setExtendedState(JFrame.NORMAL);
frame.setAlwaysOnTop(true);
frame.toFront();
frame.setAlwaysOnTop(false);
}
}
);
}
Thread.sleep(1000);
}
} catch (Throwable t) {
t.printStackTrace();
} finally {
if (pipeChannel != null) {
try {
pipeChannel.close();
} catch (Throwable t) {
t.printStackTrace();
}
}
}
} catch(Throwable t) {
t.printStackTrace();
}
}
public static void createAndShowGUI() {
frame = new JFrame();
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setSize(800, 650);
frame.getContentPane().add(new JLabel("MAIN WINDOW",
SwingConstants.CENTER), BorderLayout.CENTER);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
}
EDIT: Instead of using this WatchService approach, a simple 1 second timer thread could be used to check if the indicatorFile.exists(). Delete it, then bring the application toFront().
EDIT: I would like to know why this was downvoted. It's the best solution I have seen so far. E.g. the server socket approach fails if another application happens to already be listening to the port.
Just download Microsoft Windows Sysinternals TCPView (or use netstat), start it, sort by "State", look for the line block that says "LISTENING", pick one whose remote address says your computer's name, put that port into your new-Socket()-solution. In my implementation of it, I can produce failure every time. And it's logical, because it's the very foundation of the approach. Or what am I not getting regarding how to implement this?
Please inform me if and how I am wrong about this!
My view - which I am asking you to disprove if possible - is that developers are being advised to use an approach in production code that will fail in at least 1 of about 60000 cases. And if this view happens to be correct, then it can absolutely not be that a solution presented that does not have this problem is downvoted and criticized for its amount of code.
Disadvantages of the socket approach in comparison:
Fails if the wrong lottery ticket (port number) is chosen.
Fails in multi user environment: Only one user can run the application at the same time. (My approach would have to be slightly changed to create the file(s) in the user tree, but that's trivial.)
Fails if firewall rules are too strict.
Makes suspicious users (which I did meet in the wild) wonder what shenanigans you're up to when your text editor is claiming a server socket.
I just had a nice idea for how to solve the new-instance-to-existing-instance Java communication problem in a way that should work on every system. So, I whipped up this class in about two hours. Works like a charm :D
It's based on Robert's file lock approach (also on this page), which I have used ever since. To tell the already running instance that another instance tried to start (but didn't) ... a file is created and immediately deleted, and the first instance uses the WatchService to detect this folder content change. I can't believe that apparently this is a new idea, given how fundamental the problem is.
This can easily be changed to just create and not delete the file, and then information can be put into it that the proper instance can evaluate, e.g. the command line arguments - and the proper instance can then perform the deletion. Personally, I only needed to know when to restore my application's window and send it to front.
Example use:
public static void main(final String[] args) {
// ENSURE SINGLE INSTANCE
if (!SingleInstanceChecker.INSTANCE.isOnlyInstance(Main::otherInstanceTriedToLaunch, false)) {
System.exit(0);
}
// launch rest of application here
System.out.println("Application starts properly because it's the only instance.");
}
private static void otherInstanceTriedToLaunch() {
// Restore your application window and bring it to front.
// But make sure your situation is apt: This method could be called at *any* time.
System.err.println("Deiconified because other instance tried to start.");
}
Here's the class:
package yourpackagehere;
import javax.swing.*;
import java.io.File;
import java.io.IOException;
import java.io.RandomAccessFile;
import java.nio.channels.FileLock;
import java.nio.file.*;
/**
* SingleInstanceChecker v[(2), 2016-04-22 08:00 UTC] by dreamspace-president.com
* <p>
* (file lock single instance solution by Robert https://stackoverflow.com/a/2002948/3500521)
*/
public enum SingleInstanceChecker {
INSTANCE; // HAHA! The CONFUSION!
final public static int POLLINTERVAL = 1000;
final public static File LOCKFILE = new File("SINGLE_INSTANCE_LOCKFILE");
final public static File DETECTFILE = new File("EXTRA_INSTANCE_DETECTFILE");
private boolean hasBeenUsedAlready = false;
private WatchService watchService = null;
private RandomAccessFile randomAccessFileForLock = null;
private FileLock fileLock = null;
/**
* CAN ONLY BE CALLED ONCE.
* <p>
* Assumes that the program will close if FALSE is returned: The other-instance-tries-to-launch listener is not
* installed in that case.
* <p>
* Checks if another instance is already running (temp file lock / shutdownhook). Depending on the accessibility of
* the temp file the return value will be true or false. This approach even works even if the virtual machine
* process gets killed. On the next run, the program can even detect if it has shut down irregularly, because then
* the file will still exist. (Thanks to Robert https://stackoverflow.com/a/2002948/3500521 for that solution!)
* <p>
* Additionally, the method checks if another instance tries to start. In a crappy way, because as awesome as Java
* is, it lacks some fundamental features. Don't worry, it has only been 25 years, it'll sure come eventually.
*
* #param codeToRunIfOtherInstanceTriesToStart Can be null. If not null and another instance tries to start (which
* changes the detect-file), the code will be executed. Could be used to
* bring the current (=old=only) instance to front. If null, then the
* watcher will not be installed at all, nor will the trigger file be
* created. (Null means that you just don't want to make use of this
* half of the class' purpose, but then you would be better advised to
* just use the 24 line method by Robert.)
* <p>
* BE CAREFUL with the code: It will potentially be called until the
* very last moment of the program's existence, so if you e.g. have a
* shutdown procedure or a window that would be brought to front, check
* if the procedure has not been triggered yet or if the window still
* exists / hasn't been disposed of yet. Or edit this class to be more
* comfortable. This would e.g. allow you to remove some crappy
* comments. Attribution would be nice, though.
* #param executeOnAWTEventDispatchThread Convenience function. If false, the code will just be executed. If
* true, it will be detected if we're currently on that thread. If so,
* the code will just be executed. If not so, the code will be run via
* SwingUtilities.invokeLater().
* #return if this is the only instance
*/
public boolean isOnlyInstance(final Runnable codeToRunIfOtherInstanceTriesToStart, final boolean executeOnAWTEventDispatchThread) {
if (hasBeenUsedAlready) {
throw new IllegalStateException("This class/method can only be used once, which kinda makes sense if you think about it.");
}
hasBeenUsedAlready = true;
final boolean ret = canLockFileBeCreatedAndLocked();
if (codeToRunIfOtherInstanceTriesToStart != null) {
if (ret) {
// Only if this is the only instance, it makes sense to install a watcher for additional instances.
installOtherInstanceLaunchAttemptWatcher(codeToRunIfOtherInstanceTriesToStart, executeOnAWTEventDispatchThread);
} else {
// Only if this is NOT the only instance, it makes sense to create&delete the trigger file that will effect notification of the other instance.
//
// Regarding "codeToRunIfOtherInstanceTriesToStart != null":
// While creation/deletion of the file concerns THE OTHER instance of the program,
// making it dependent on the call made in THIS instance makes sense
// because the code executed is probably the same.
createAndDeleteOtherInstanceWatcherTriggerFile();
}
}
optionallyInstallShutdownHookThatCleansEverythingUp();
return ret;
}
private void createAndDeleteOtherInstanceWatcherTriggerFile() {
try {
final RandomAccessFile randomAccessFileForDetection = new RandomAccessFile(DETECTFILE, "rw");
randomAccessFileForDetection.close();
Files.deleteIfExists(DETECTFILE.toPath()); // File is created and then instantly deleted. Not a problem for the WatchService :)
} catch (Exception e) {
e.printStackTrace();
}
}
private boolean canLockFileBeCreatedAndLocked() {
try {
randomAccessFileForLock = new RandomAccessFile(LOCKFILE, "rw");
fileLock = randomAccessFileForLock.getChannel().tryLock();
return fileLock != null;
} catch (Exception e) {
return false;
}
}
private void installOtherInstanceLaunchAttemptWatcher(final Runnable codeToRunIfOtherInstanceTriesToStart, final boolean executeOnAWTEventDispatchThread) {
// PREPARE WATCHSERVICE AND STUFF
try {
watchService = FileSystems.getDefault().newWatchService();
} catch (IOException e) {
e.printStackTrace();
return;
}
final File appFolder = new File("").getAbsoluteFile(); // points to current folder
final Path appFolderWatchable = appFolder.toPath();
// REGISTER CURRENT FOLDER FOR WATCHING FOR FILE DELETIONS
try {
appFolderWatchable.register(watchService, StandardWatchEventKinds.ENTRY_DELETE);
} catch (IOException e) {
e.printStackTrace();
return;
}
// INSTALL WATCHER THAT LOOKS IF OUR detectFile SHOWS UP IN THE DIRECTORY CHANGES. IF THERE'S A CHANGE, ANOTHER INSTANCE TRIED TO START, SO NOTIFY THE CURRENT ONE OF THAT.
final Thread t = new Thread(() -> watchForDirectoryChangesOnExtraThread(codeToRunIfOtherInstanceTriesToStart, executeOnAWTEventDispatchThread));
t.setDaemon(true);
t.setName("directory content change watcher");
t.start();
}
private void optionallyInstallShutdownHookThatCleansEverythingUp() {
if (fileLock == null && randomAccessFileForLock == null && watchService == null) {
return;
}
final Thread shutdownHookThread = new Thread(() -> {
try {
if (fileLock != null) {
fileLock.release();
}
if (randomAccessFileForLock != null) {
randomAccessFileForLock.close();
}
Files.deleteIfExists(LOCKFILE.toPath());
} catch (Exception ignore) {
}
if (watchService != null) {
try {
watchService.close();
} catch (IOException e) {
e.printStackTrace();
}
}
});
Runtime.getRuntime().addShutdownHook(shutdownHookThread);
}
private void watchForDirectoryChangesOnExtraThread(final Runnable codeToRunIfOtherInstanceTriesToStart, final boolean executeOnAWTEventDispatchThread) {
while (true) { // To eternity and beyond! Until the universe shuts down. (Should be a volatile boolean, but this class only has absolutely required features.)
try {
Thread.sleep(POLLINTERVAL);
} catch (InterruptedException e) {
e.printStackTrace();
}
final WatchKey wk;
try {
wk = watchService.poll();
} catch (ClosedWatchServiceException e) {
// This situation would be normal if the watcher has been closed, but our application never does that.
e.printStackTrace();
return;
}
if (wk == null || !wk.isValid()) {
continue;
}
for (WatchEvent<?> we : wk.pollEvents()) {
final WatchEvent.Kind<?> kind = we.kind();
if (kind == StandardWatchEventKinds.OVERFLOW) {
System.err.println("OVERFLOW of directory change events!");
continue;
}
final WatchEvent<Path> watchEvent = (WatchEvent<Path>) we;
final File file = watchEvent.context().toFile();
if (file.equals(DETECTFILE)) {
if (!executeOnAWTEventDispatchThread || SwingUtilities.isEventDispatchThread()) {
codeToRunIfOtherInstanceTriesToStart.run();
} else {
SwingUtilities.invokeLater(codeToRunIfOtherInstanceTriesToStart);
}
break;
} else {
System.err.println("THIS IS THE FILE THAT WAS DELETED: " + file);
}
}
wk.reset();
}
}
}
I've got a pretty straightforward Java webapp that has been showing some very strange behavior on development systems. The problem starts with the registration handler, which is implented as follows:
//XXX: this shouldn't really be 'synchronized', but I've declared it as such
// for the sake of debugging this issue
public synchronized ModelAndView submitRegister(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String email = request.getParameter("email");
String pass = request.getParameter("pass");
String conf = request.getParameter("conf");
String name = request.getParameter("name");
EntityManager em = DatabaseUtil.getEntityManager(request);
//[make sure required fields are present and valid, etc.]
User user = getUserForEmail(email, em);
if (user != null) {
//[user already exists, go to error page]
}
//create the new user
em.getTransaction().begin();
try {
user = new User();
//[set fields, etc.]
em.persist(user);
//[generate e-mail message contents]
boolean validEmail = EmailUtility.sendEmail(admin, recip, subject, message, null, recip);
if (validEmail) {
em.getTransaction().commit();
//[go to 'registration successful' page]
}
em.getTransaction().rollback();
//[go to error page]
}
catch (Exception e) {
em.getTransaction().rollback();
//[go to error page]
}
}
The problem occurs on the EmailUtility.sendEmail() call. The code for this method is pretty straightforward:
public static boolean sendEmail(String fromAddress, String to, String subject, String message, String fromHeaderValue, String toHeaderValue) {
try {
Session session = getMailSession(to);
Message mailMessage = new MimeMessage(session);
mailMessage.setFrom(new InternetAddress(fromAddress));
if (fromHeaderValue != null) {
mailMessage.setHeader("From", fromHeaderValue);
}
if (toHeaderValue != null) {
mailMessage.setHeader("To", toHeaderValue);
}
mailMessage.setHeader("Date", new Date().toString());
mailMessage.setRecipients(RecipientType.TO, InternetAddress.parse(to, false));
mailMessage.setSubject(subject);
mailMessage.setContent(message, "text/html;charset=UTF-8");
Transport.send(mailMessage);
return true;
} catch (Throwable e) {
LOG.error("Failed to send e-mail!", e);
return false;
}
}
What happens is that when the code reaches the call for EmailUtility.sendEmail(), instead of calling that method execution recurses through submitRegister(). That's easily one of the most bizarre things I've ever seen.
For awhile I didn't even believe that was what's actually happening; but at this point I've confirmed it by synchronizing the method involved and adding print statements on every line of both methods. submitRegister() recurses, and sendEmail() is never called. I've got no idea how this is even possible.
Frustratingly, the exact same code runs just as it should on the production server. It's only on development systems that this problem appears.
Any suggestions regarding what might be causing this problem and what I can do to fix it are welcome.
You are right, This is not possible :)
I would suggest you strip away all other code, put in a lot of logging, if you don't like debugging and see what happens. Start with something like:
public synchronized ModelAndView submitRegister(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
LOG.debug("submitRegister: " + this.toString);
EmailUtility.sendEmail("a#x.y", "b#x.y", "subject", "message", "from", "to");
}
public static boolean sendEmail(String fromAddress, String to, String subject, String message, String fromHeaderValue, String toHeaderValue) {
LOG.debug("sendEmail: " + this.toString());
}
The toString will show you what classes are involved.
My guess would be that:
your first call fails, so sendEmail will never be invoked
submitRegister is triggered more than once by someone else, not by the EmailUtility.sendEmail statement.
If you get the stripped version to work, start putting back your code, one peace at a time to see where it all goes bad :)
Okay, I tracked this down to a few different issues working together:
On development systems, the classpath was missing javax.mail.Address. This caused the EmailUtility class to fail to initialize, and would throw a NoClassDefFoundError on the sendEmail() call, before any code from that method could execute.
The code in submitRegister() had a catch Exception block, but NoClassDefFoundError extends Error, not Exception. So it bypassed the catch Exception block entirely.
The Spring controller where the Error was actually caught had some of the most questionable "error-handling" code I've ever come across:
try {
Method serviceMethod = this.getControllerClass().getMethod(method, HttpServletRequest.class, HttpServletResponse.class);
if (this.doesMethodHaveAnnotation(serviceMethod, SynchronizedPerAccount.class)) {
synchronized(this.getAccountLock(request)) {
super.doService(request, response);
}
}
else {
//don't need to execute synchronously
super.doService(request, response);
}
}
catch (Throwable ignored) {
super.doService(request, response);
}
So the NoClassDefFoundError was propagating back up to the Spring controller, which was catching it and attempting to re-invoke the doService() method, which caused submitRegister() to be invoked again. It wasn't recursion (though there was no way to tell that by just looking at the debug output), it was the Spring controller calling it twice for the same request. It never got called more than twice for a given request, because there's no try/catch around the second doService() call.
Long story short, I patched up these issues and problem solved.