byronnevins - Developer IT

GlassFish Clustering with DCOM on Windows

- by ByronNevins

DCOM - Distributed COM, a Microsoft protocol for communicating with Windows machines. Why use DCOM? In GlassFish 3.1 SSH is used as the standard way to run commands on remote nodes for clustering. It is very difficult for users to get SSH configured properly on Windows. SSH does not come with Windows so we have to depend on third party tools. And then the user is forced to install and configure these tools -- which can be tricky. DCOM is available on all supported platforms. It is built-in to Windows. The idea is to use DCOM to communicate with remote Windows nodes. This has the huge advantage that the user has to do minimal, if any, configuration on the Windows nodes. Implementation HighlightsTwo open Source Libraries have been added to GlassFish: Jcifs – a SAMBA implementation in Java J-interop – A Java implementation for making DCOM calls to remote Windows computers. Note that any supported platform can use DCOM to work with Windows nodes -- not just Windows.E.g. you can have a Linux DAS work with Windows remote instances.All existing SSH commands now have a corresponding DCOM command – except for setup-ssh which isn’t needed for DCOM. validate-dcom is an all new command. New DCOM Commands create-node-dcom delete-node-dcom install-node-dcom list-nodes-dcom ping-node-dcom uninstall-node-dcom update-node-dcom validate-dcom setup-local-dcom (This is only available via Update Center for GlassFish 3.1.2) These commands are in-place in the trunk (4.0). And in the branch (3.1.2) Windows Configuration Challenges There are an infinite number of possible configurations of Windows if you look at it as a combination of main release, service-pack, special drivers, software, configuration etc. Later versions of Windows err on the side of tightening security be default. This means that the Windows host may need to have configuration changes made.These configuration changes mostly need to be made by the user. setup-local-dcom will assist you in making required changes to the Windows Registry. See the reference blogs for details. The validate-dcom Command validate-dcom is a crucial command. It should be run before any other commands. If it does not run successfully then there is no point in running other commands.The validate-dcom command must be used from a DAS machine to test a different Windows machine. If validate-dcom runs successfully you can be confident that all the DCOM commands will work. Conversely, the opposite is also true: If validate-dcom fails, then no DCOM commands will work. What validate-dcom does Verify that the remote host is not the local machine. Resolves the remote host name Checks that the remote DCOM port is being listened on (135, 139) Checks that the remote host’s File Sharing is enabled (port 445) It copies a file (a script) to the remote host to verify that SAMBA is working and authorization is correct It runs a script that it copied on-the-fly to the remote host. Tips and Tricks The bread and butter commands that use DCOM are existing commands like create-instance, start-instance etc. All of the commands that have dcom in their name are for dealing with the actual nodes. The way the software works is to call asadmin.bat on the remote machine and run a command. This means that you can track these commands easily on the remote machine with the usual tools. E.g. using AS_LOGFILE, looking at log files, etc. It’s easy to attach a debugger to the remote asadmin process, “just in time”, if necessary. How to debug the remote commands:Edit the asadmin.bat file that is in the glassfish/bin folder. Use glassfish/lib/nadmin.bat in GlassFish 4.0+Add these options to the java call:-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1234 Now if you run, say start-instance on DAS, you can attach your debugger, at your leisure, to the remote machines port 1234. It will be running start-local-instance and patiently waiting for you to attach.

Read the article

Tip #13 java.io.File Surprises

- by ByronNevins

There is an assumption that I've seen in code many times that is totally wrong. And this assumption can easily bite you. The assumption is: File.getAbsolutePath and getAbsoluteFile return paths that are not relative. Not true! Sort of. At least not in the way many people would assume. All they do is make sure that the beginning of the path is absolute. The rest of the path can be loaded with relative path elements. What do you think the following code will print? public class Main { public static void main(String[] args) { try { File f = new File("/temp/../temp/../temp/../"); File abs = f.getAbsoluteFile(); File parent = abs.getParentFile(); System.out.println("Exists: " + f.exists()); System.out.println("Absolute Path: " + abs); System.out.println("FileName: " + abs.getName()); System.out.printf("The Parent Directory of %s is %s\n", abs, parent); System.out.printf("The CANONICAL Parent Directory of CANONICAL %s is %s\n", abs, abs.getCanonicalFile().getParent()); System.out.printf("The CANONICAL Parent Directory of ABSOLUTE %s is %s\n", abs, parent.getCanonicalFile()); System.out.println("Canonical Path: " + f.getCanonicalPath()); } catch (IOException ex) { System.out.println("Got an exception: " + ex); } }} Output: Exists: trueAbsolute Path: D:\temp\..\temp\..\temp\..FileName: ..The Parent Directory of D:\temp\..\temp\..\temp\.. is D:\temp\..\temp\..\tempThe CANONICAL Parent Directory of CANONICAL D:\temp\..\temp\..\temp\.. is nullThe CANONICAL Parent Directory of ABSOLUTE D:\temp\..\temp\..\temp\.. is D:\tempCanonical Path: D:\ Notice how it says that the parent of d:\ is d:\temp !!!The file, f, is really the root directory. The parent is supposed to be null. I learned about this the hard way! getParentXXX simply hacks off the final item in the path. You can get totally unexpected results like the above. Easily. I filed a bug on this behavior a few years ago[1]. Recommendations: (1) Use getCanonical instead of getAbsolute. There is a 1:1 mapping of files and canonical filenames. I.e each file has one and only one canonical filename and it will definitely not have relative path elements in it. There are an infinite number of absolute paths for each file. (2) To get the parent file for File f do the following instead of getParentFile: File parent = new File(f, ".."); [1] http://bt2ws.central.sun.com/CrPrint?id=6687287

Read the article

Clustering in GlassFish with DCOM on Windows 7

- by ByronNevins

I've discovered that Windows 7 makes it very difficult to use DCOM and, mainly, the GlassFish clustering commands that rely on DCOM. I spent a few days trying to solve the problems. I don't yet have a cookbook for making DCOM work on Windows 7. But here are a few tips and advice I've found. run asadmin setup-local-dcom -- It now comes automatically with the open source GlassFish 4. It will write some critical registry entries for you. run asadmin validate-dcom to test dcom 3. When I ran validate-dcom on my Windows 7 network I saw the problem below: Successfully resolved host name to: gloin/10.28.51.10 Successfully connected to DCOM Port at port 135 on host gloin. Successfully connected to NetBIOS Session Service at port 139 on host gloin.Successfully connected to Windows Shares at port 445 on host gloin.Can not access the remote file system. Is UAC on? : Access is denied. I discovered the actual problem is that Windows 7 no longer has the "C$" Administrative file share available by default. If "C$" isn't available then nothing will work. Here is how to expose the "C$" share: Registry Change -- this change allows “C$” to be accessed. As soon as I set it -- the file copying started working! [1] regkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System create this key, 32 bit word, with value == 1 LocalAccountTokenFilterPolicy 4. Turn on the Remote Registry Service -- This is critical and it's easy to do. Windows 7 has it turned off by default. MyComputer-right click, manage, services, then turn on Remote Registry Service and set it to start automatically in the fture. 5. Turn off UAC: %systemroot%\system32\UserAccountControlSettings.exe 6. This is where I discovered that McAfee virus scanner blocks all the NetBios shares! It has to be disabled.

Read the article

Tip #15: How To Debug Unit Tests During Maven Builds

- by ByronNevins

It must be really really hard to step through unit tests in a debugger during a maven build. Right? Wrong! Here is how i do it: 1) Set up these environmental variables: MAVEN_OPTS=-Xmx1024m -Xms256m -XX:MaxPermSize=512mMAVEN_OPTS_DEBUG=-Xmx1024m -Xms256m -XX:MaxPermSize=512m -Xdebug (no line break here!!) -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9999MAVEN_OPTS_REG=-Xmx1024m -Xms256m -XX:MaxPermSize=512m 2) create 2 scripts or aliases like so: maveny.bat: set MAVEN_OPTS=%MAVEN_OPTS_DEBUG% mavenn.bat: set MAVEN_OPTS=%MAVEN_OPTS_REG% To debug do this: run maveny.bat run mvn install attach your debugger to port 9999 (set breakpoints of course) When maven gets to the unit test phase it will hit your breakpoint and wait for you. When done debugging simply run mavenn.bat Notes If it takes a while to do the build then you don't really need to set the suspend=y flag. If you set the suspend=n flag then you can just leave it -- but only one maven build can run at a time because of the debug port conflict.

Read the article

Tip #19 Module Private Visibility in OSGi

- by ByronNevins

I hate public and protected methods and classes. It requires so much work to change them in a huge project like GlassFish. Not to mention that you may well have to support those APIs forever. They are highly overused in GlassFish. In fact I'd bet that > 95% of classes are marked as public for no good reason. It's just (bad) habit is my guess. private and default visibility (I call it package-private) is easier to maintain. It is much much easier to change such classes and methods around. If you have ANY public method or public class in GlassFish you'll need to grep through a tremendous amount of source code to find all callers. But even that won't be theoretically reliable. What if a caller is using reflection to access public methods? You may never find such usages. If you have package private methods, it's easy. Simply grep through all the code in that one package. As long as that package compiles ok you're all set. There can' be any compile errors anywhere else. It's a waste of time to even look around or build the "outside" world. So you may be thinking: "Aha! I'll just make my module have one giant package with all the java files. Then I can use the default visibility and maintenance will be much easier. But there's a problem. You are wasting a very nice feature of java -- organizing code into separate packages. It also makes the code much more encapsulated. Unfortunately to share code between the packages you have no choice but to declare public visibility. What happens in practice is that a module ends up having tons of public classes and methods that are used exclusively inside the module. Which finally brings me to the point of this blog: If Only There Was A Module-Private Visibility Available Well, surprise! There is such a mechanism. If your project is running under OSGi that is. Like GlassFish does! With this mechanism you can easily add another level of visibility by telling OSGi exactly which public you want to be exposed outside of the module. You get the best of both worlds: Better encapsulation of your code so that maintenance is easier and productivity is increased. Usage of public visibility inside the module so that you can encapsulate intra-module better with packages. How I do this in GlassFish: Carefully plan out at least one package that will contain "true" publics. This is the package that will be exported by OSGi. I recommend just one package. Here is how to tell OSGi to use it in GlassFish -- edit osgi.bundle like so:-exportcontents: org.glassfish.mymodule.truepublics; version=${project.osgi.version} Now all publics declared in any other packages will be visible module-wide but not outside the module. There is one caveat: Accessing "module-private" items outside of the module is controlled at run-time, not compile-time. The compiler has no clue that a public in a dependent module isn't really public. it will happily compile it. At runtime you will definitely see fireworks. The good news is that you don't have to wait for the code path that tries to use the "module-private" items to fire. OSGi will complain loudly when that module gets loaded. OSGi will refuse to load it. You will see an error like this: remote failure: Error while loading FOO: Exception while adding the new configuration : Error occurred during deployment: Exception while loading the app : org.osgi.framework.BundleException: Unresolved constraint in bundle com.oracle.glassfish.miscreant.code [115]: Unable to resolve 115.0: missing requirement [115.0] osgi.wiring.package; (osgi.wiring.package=org.glassfish.mymodule.unexported). Please see server.log for more details. That is if you accidentally change code in module B to use a public that is really a "module-private" in module A, then you will see the error immediately when you try to test whatever you were changing in module B.

Developer IT