I am currently having an issue with running mule-standalone-3.4.0 on a windows 64 bit machine below is the issue.
*> Launching a JVM... Starting the Mule Container... Wrapper (Version
3.2.3) http://wrapper.tanukisoftware.org Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved.
WARNING - Unable to load the Wrapper's native library because none of
the
following files:
wrapper-windows-x86-64.dll
wrapper.dll
could be located on the following java.library.path:
C:\Users\jdudla\%LD_LIBRARY_PATH%
C:\Mule\mule-standalone-3.4.0\lib\boot
Please see the documentation for the wrapper.java.library.path
configuration property.
System signals will not be handled correctly.*
Has anyone else had this issue and corrected it?
Problem was fixed by installing a 32 bit JVM. Mule Standalone CE only works with 32bit. Mule enterprise works with 64bit...
**> Mule CE ship with community version of the Tanuki Wrapper. The
Community version of Tanuki wrapper does not support windows 64 bit.
http://wrapper.tanukisoftware.org/doc/english/download.jsp#downloadNote2
To run on windows 64 bit you will have to use Mule EE.**
So to run Standalone on a 64bit machine install a 32bit JVM and it will run fine.
You don't have a 64 bit JVM installed. Type java -version from a command line.
c:\> java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
You need to install the a 64 bit JVM or use the 32 bit Mule distro.
Related
I am installing jprofiler on 64bit Scientific Linux release 6.2 (Carbon)
But the installer shows:
---> Package jprofiler.i386 0:8.0.4-1 will be installed
Should I be worried that the Arch is i386?
JProfiler ships with native libraries for 32-bit and 64-bit. They are located in bin/linux-x86 and bin/linux-x64.
The JProfiler GUI is written in Java and uses the appropriate JRE. The selection of the correct native library is only important when adding an -agentpath VM parameter to a start script. The integration wizard has a check box for profiling 64-bit JREs, this changes the library path in the -agentpath VM parameter accordingly.
I have the source code for a 32-bit dll (Windows) that I am trying to re-compile as a 64 bit dll. I have been told that the app "can compile in VC++ 64-bit mode to target AMD64 or Itanium processors running Windows 64 bit Server."
I am trying to decipher this: if it runs on Windows 64 bit server, should it also run on x64 bit Windows?
AMD64 and x64 and x86-64, and Intel64 and EM64T are essentially same thing, with different names.
When I run the 64-bit version of Windbg on a Win7 64-bit machine, it shows the image path of the the clr.dll module to be the 32-bit version of the framework, not the 64-bit.
Is there any way to specify the image path for the clr.dll module in Windbg? Should Windbg 64-bit running on a 64-bit box be grabbing clr.dll from the Framework64 directory?
0:000> lmvm clr
...
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
I have a 64bit w3wp.exe dump that I cannot use SOS on, and I believe it's because of incompatible frameworks, caused by this 32bit clr dll image.
0:000> .loadby sos clr
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos) failed, Win32 error 0n193
"%1 is not a valid Win32 application."
Once again, the dump is from a 64-bit server, I've doubled checked that it has the same CLR version as my Win7 64bit machine I'm debugging on, and I'm running 64bit Windbg.
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
...
Windows 7 Version 7600 MP (4 procs) Free x64
When I run 32-bit Windbg, it loads SOS fine, but then errors when I try to run !threads, with the ubiquitous Failed to load data access DLL, 0x80004005 error.
Can the CLR image be set and if so, how?
This actually sounds like an mscordacwks issue. Take a look at http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx for an excellent guide on resolving this.
Is there a 64bit version out there for 64bit OS? If not, is there a way to install the SAP NetWeaver on a 64bit Windows 7 without using a VM with a 32bit system?
Thanks :)
SAP NetWeaver ABAP Trial 7.02 Win 64-bit Version (SP7) System Requirements:
Operating System Windows 7 64 bit Professional (unsupported platform for Trial Installation) or Windows Server 2008
JRE 1.4.x or JRE 1.5.x (for installation only, JRE 1.6 is not supported)
...
If you're not logged on, you can find it in the SAP Software Download Catalog.
There is this developer verion for windows.
But the requirements state following:
Operating System: Windows XP
Professional (Service Pack 2) or
Windows Server 2003 and Windows Vista
(english)
I did use vm ware with a xp sp 2 image under windows 7 to install the Netweaver server. No problems so far (except for the performance).
64 bit - yes, for example this one. Windows, I don't know...
The latest released trial version is the SAP NetWeaver AS ABAP 7.02 SP6 32-bit Trial.
It's available at http://www.sdn.sap.com/irj/scn/nw-downloads There are no 64bit windows trial versions
You can install the 32bit versions on Windows 7 Professional or better by using XP Mode (you can't install XP Mode on Windows 7 Home or lower). Searvh on "site:microsoft.com Windows XP mode" for how to install xp mode (I can only post 1 link at a time at the moment).
Does a 64-bit CruiseControl.NET exist or do I need to install the 32-bit version? Our CI server is Server2003 64-bit. Currently I have been testing on WinXP Pro and no problems.
If I do need to run cc.net 32-bit on a 64-bit OS, what issues should I expect to encounter? This post mentions a couple, Running 32-bit ASP.NEt 3.5 apps in Windows 2003 64-bit . I would also need to have the .NET 2.0 and 3.5 framework installed. Do I install the 32-bit versions if running cc.net 32-bit? Can 32-bit and 64-bit coexist on the same server?
A quick peek at the source code reveals that CruiseControl.NET is compiled with "Any CPU" platform, so it will (and does) run on either a 32 or 64 bit runtime.
My notebook runs 64 bit O/S and has no problems with CruiseControl.NET server or web dashboard (IIS 7). Just install it as per normal and you should be fine.
Personally I'd be really worried if it needed > 3GB of memory :)
It shouldn't be anything you need to worry about. Cruise control just launches the build, subsequent steps such as compilation can be 64-bit.
I don't think there's much benefit from making CruiseControl 64-bit at the moment. I'm running CruiseControl without issues on a 64-bit machine. The setup was not much different, other than the folder which it was installed into (Program files (x86)).
Generally speaking, all 32bit applications will work on a 64bit OS. I have been doing this with my webapps for some time. You will encounter issues only if you are trying to reference assemblies across the bit boundary, ie. 64bit assembly from 32bit application.
You should be already to run CC on 32bit mode on 64bit OS.
There are no seperate version of CruiseControl for 64-bit. But but you may run into an ASP.NET error if working with Win. Server 2008 and IIS7.
Workaround:
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -i
and
"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe" -i "W3SVC/1/ROOT/ccnet"
NOTE: it is using Framework64 as this would not work for 32-bit.