I have a 32 bits xp machine that has been building our builds for a year now without much problem, now we have a new demand on our environment. The consultancy firm involved have some software that only thrives on 64bit 2008 webserver. So I set up a slave buildserver on the webserver so that their integration tests would work.
Now I have it up and running - we had trouble with useraccounts, having logfiles in the program files folder, and other stuff but it is running now and builds when a change is detected.
BUT:
I can´t administrate the slave from cctray - when I click force build on a project I get this message:
and I have no clue as to why, the webdashboard is a bit more informative:
ThoughtWorks.CruiseControl.Remote.CommunicationsException: Request processing has failed on the remote server: Key cannot be null. Parameter name: key at ThoughtWorks.CruiseControl.Remote.CruiseServerClient.ValidateResponse(Response response) at ThoughtWorks.CruiseControl.Remote.CruiseServerClient.ListBuildParameters(String projectName) at ThoughtWorks.CruiseControl.WebDashboard.ServerConnection.ServerAggregatingCruiseManagerWrapper.ListBuildParameters(IProjectSpecifier projectSpecifier, String sessionToken) at ThoughtWorks.CruiseControl.WebDashboard.Dashboard.ProjectParametersAction.Execute(ICruiseRequest cruiseRequest) at ThoughtWorks.CruiseControl.WebDashboard.MVC.Cruise.CruiseActionProxyAction.Execute(IRequest request) at ThoughtWorks.CruiseControl.WebDashboard.MVC.Cruise.ExceptionCatchingActionProxy.Execute(IRequest request)
:(
there is some kind of bug i ccnet on 64-bits clients- you can get it to work more or less but not as beautifully as on 32...
but thats the price of progress I guess
Related
I'm trying to debug Azure Function scripts locally, in conjunction with Unity, but getting Timeout errors every time.
I have a few things here, and I'm not sure which one is actually causing the problem... It might be a settings on Windows, as oppose to one of the softwares.
I'm building in Unity 2019.4, and and using PlayFab and it's ability to use Azure Functions. When I try to execute scripts from the Azure servers, it functions correctly. But when I try to run it with Local Debugging, I get WebException: The request timed out System.Net.HttpWebRequest.GetRequestStream (See full error below).
Here's what I'm doing to setup:
Set PlayFab to Local Debugging (via VS Code Extension)(and confirming the json file is made in the temp folder)
Install Azure Functions Core Tools from Here
Start Azure Functions debugging from VS Code (terminal output shows that the the localhost is running it correctly)
Timeout error references the correct address http://localhost:7071/api/CloudScript/ExecuteFunction as confirmed in the VS Code Terminal when the AzFunc debugging is started.
When I clone the project to my MacBook Pro, everything runs smoothly in local debugging.
So, because of this, I've tried checking to make sure ports aren't blocked via PowerShell: netsh firewall show state,and told Windows Defender to not block anything from Unity or Code. When I run Netstat -ab in PowerShell/CMD, I do get:
Can not obtain ownership information
TCP 0.0.0.0:7071 DESKTOP-COMPUTER:0 LISTENING
[func.exe]
TCP 0.0.0.0:7680 DESKTOP-COMPUTER:0 LISTENING
I don't know if this is a problem, or normal...
I don't even know what else to check for. This problem is beyond me. If anyone knows the solution, or can point me in right direction, I'd be very grateful!
Below are the two errors from the Unity log whenever I execute an Azure Function script through PlayFab while local debugging:
WebException: The request timed out
System.Net.HttpWebRequest.GetRequestStream () (at <14e3453b740b4bd690e8d4e5a013a715>:0)
PlayFab.Internal.PlayFabWebRequest.Post (PlayFab.Internal.CallRequestContainer reqContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:319)
Rethrow as WebException: Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:LogException(Exception)
PlayFab.Internal.PlayFabWebRequest:Post(CallRequestContainer) (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:332)
PlayFab.Internal.PlayFabWebRequest:WorkerThreadMainLoop() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:252)
System.Threading.ThreadHelper:ThreadStart()
Timeout: WebException making http request to: http://localhost:7071/api/CloudScript/ExecuteFunction
UnityEngine.Debug:Log(Object)
DemoScript:onPlayFabError(PlayFabError) (at Assets/PlayFabPartySDK/Examples/DemoScript.cs:264)
PlayFab.Internal.<>c__DisplayClass30_0:<QueueRequestError>b__0() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:395)
PlayFab.Internal.PlayFabWebRequest:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabWebRequest.cs:480)
PlayFab.Internal.PlayFabHttp:Update() (at Assets/PlayFabSDK/Shared/Internal/PlayFabHttp/PlayFabHTTP.cs:364)
Okay, TLDR: The answer to the problem is that not everything was updated. So, update everything if you're experiencing the same problem.
More specifically in my case, the "Visual Studio Code Editor" asset in Unity's Package Manager.
I just wanted throw this out there in case anyone has a problem like this in the future. It may not be the same specific thing that needs upgrading, but search around for everything involved and make sure it's updated. Not just the big, obvious things (like Unity or your IDE). Thankfully for me in this case, the update was starting to cause other problems, and after much headbanging trying to solve those, I came across it.
Good luck, future fellow idiots!
We are running a Kubuntu Server, It has been running without any problems for a long time.
However, When attempting to login to the server through the GUI it throws the following error message:
lnusertemp failed (temporary directories full ?). Check your installation
We have much free room on the drives and cannot figure out the cause of this issue. We are able to login through a remote cli application (using putty).
To my knowledge, we haven't updated or modified any core files or settings to this server, so its sudden change in operation has given us with some concern. This server is an important unit to our working process.
I know this question has been asked several times around the internet, but I have spent about a week trying to solve this problem with little luck.
I am trying to install JavaCommAPI (an archived Java package to allow communication with rs232) on a remote linux Ubuntu 11.0, 32-bit server in order to deploy a web project which I have developed on a local apache server on my windows PC.
The thing that puzzles me is, I am able to get the .war web project to deploy on a local apache server on a separate 32-bit LinuxMint16 PC by correctly placing the javax.comm.properties, comm.jar, and libSerialParallel.so files in their respective places.
I use System.getProperty("java.library.path"); in order to find the correct library path in order to install correct files.
On my LinuxMint16:
javax.comm.properties -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib
comm.jar -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib/ext
libSerialParallel.so -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386
....works!
On my remote Ubuntu server I did the exact same for its reported library path
(for example: /usr/local/jdk/jdk1.7.0_45/jre/lib/javax.comm.properties ;
/usr/local/jdk/jdk1.7.0_45/jre/lib/ext/comm.jar ;
/usr/local/jdk/jdk1.7.0_45/jre/lib/i386/libSerialParallel.so)
...fails =(
Things of note: I added the needed apache jars and comm.jar to my libraries in Eclipse using the BuildPath wizard (right click on project --> Build Path-->add external jars) which points to local files on my PC which I obviously cannot use for a remote server which I am only accessing through command line. May this is affecting it somehow?
I tried to get error output (System.err) from the Java Console printed to a separate file for my remote server as that feedback was very helpful in getting all the files sorted on my LinuxMint PC.
PrintStream ps = new PrintStream(pathName);
System.setOut(ps);
System.setErr(ps);
Which again, is oddly working beautifully to print the stream to a local .txt file on my LinuxMintPC but not to the one I designate on my remote ubuntu server.
I am really at a wits end here!! Am I mixing and matching appropriate versions of Systems prohibiting things to run smoothly? I am not sure how to proceed from here, if anyone has any insights I would die of happiness. Thanks
I needed to install OPEN JDK7 on my ubuntu, put files in appropriate library paths (as described above) and now it works.
We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.
I really hope someone who is a CC.NET expert can help with this, because this problem is painful!
I have a remote build machine with CruiseControl.NET and CCTray running (version 1.5.7256.1)
On the local machine I have CCtray connecting through HTTP not .NET remoting.
When I configure the projects, I add a server through HTTP and use the following URL:
http://localhost/ccnet
If I leave [Set to pre-1.5.0 server] UNCHECKED, then it fails to connect with this error:
Failed to connect to server: The remote server returned an error: (500) Internal Server Error.
If I set to [Set to pre-1.5.0. server] CHECKED, then it succeeds and I can kick builds off from CCtray on the local machine fine.
Now, if I go back to another machine which I want to connect remotely, I follow same steps. Again, only pre-1.5.0 setting works. WHY?! CruiseControl.NET and CCTray are at 1.5.7256.1?!?
The 2nd problem and main problem which I think may be related to the previous; if I then use the pre-1.5.0 setting the pojects show up but when I force a build I now get this error:
An unexpected error has occurred while trying to force a build.
The method or operation is not implemented.
What am I doing wrong, I'm really struggling with this. I previously was using 1.4 versions and this worked fine, so has something broken? I'm using IIS7 too so don't know if this could be something to do with it.
I had a look at the tray app's source code for the 1.5 release (as well as the current trunk.) When connected to a pre-1.5 server, regardless of whether you specified the connection as remoting or HTTP, you will receive the unimplemented exception message when attempting to force build a project.
Looks like your options at the moment are to wait for a new release or pull down the code and modify (and I have no idea how easy backwards compatibility was maintained between versions...)
It sounds like you may have configuration options that are part of a breaking change perhaps? can you post more of your configuration so we can check it?
Also after you save changes have you looked at the server log? it often has information about what broke. Especially the part that happens right after you change a config file and save.
I'd be interested in seeing log file information. Also, why are you using http rather than remoting? Perhaps show us some of your settings in ccnet.exe.config? here's my remoting setup which I believe is the default:
<system.runtime.remoting>
<application>
<channels>
<channel ref="tcp" port="21234">
<serverProviders>
<formatter ref="binary" typeFilterLevel="Full"/>
</serverProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>
also you may want to check security issues and firewall settings on that server. (windows event log for security audit failures, etc...)