I am trying to get the Remoting appender to work in log4net. I have implemented the method shown in these posts and I see the server object listening on the correct port, but I cannot get the client object to actually make the remoting connection. Client and server are both running on the same machine (my development box) so it should not be a firewall issue. I implemented the TimedRemotingAppender as show in the posts, and I can set a breakpoint on the LogEvents method, and see that it hits the breakpoint whenever I call log4net, but nothing ever appears at the server. I'm pretty sure I have the config files correct.
Any log4net gurus out there, is there a trick to getting this to work?
Thanks,
Peter
OK, I figured out that it is not really a log4net issue. I made a change elsewhere in my code, changing this line of code:
RemotingConfiguration.Configure(null, true);
To this:
RemotingConfiguration.Configure(null, false);
and data started flowing. I'm not sure what extra code I would have to write to get the "secure" version of remoting connections working, but any machine we would do this on is already behind the corporate firewall, so I may not have to fuss with security.
Thanks,
Peter
Related
I am working on an application where I have no choice but to target .NET 2.0. This is a socket application using TcpClient and TcpListener, and I have opened the necessary ports in the Windows Firewall (Win 7.0.) On one end, I use TcpClient.Connect() method to initiate a connection, and the TcpListener.Pending() method at the other end to detect the request.
The problem I am having is that Pending() never returns true at the server end. I have checked to make sure the Start() method has been called, etc., and no errors are returned or exceptions thrown. On the client end, I am using Connect(), Write(), Flush(), and Close() (which are all void return types) in a try/catch, and no exception occurs. So, from the client's perspective, everything looks fine. The problem is that the server never sees the connection request, so the data the client thinks it is sending never appears at the server.
Due to the extremely confidential nature of the work, I cannot post a source listing. I am wondering if, from this description, someone can suggest some possible culprits. As I said, I have opened the ports in the firewall - I was at first getting "No connection could be made because the target machine actively refused it," but, after dealing with the firewall issues, all errors and exceptions went away, but still no data flows.
I know this is a tough one without source listings, but if you have seen this kind of problem before and can suggest places to look, I would much appreciate it.
Thank you.
Maybe there is a "Whitelist" of sorts? Maybe the server needs to "Whitelist" the client?
We have designed an Android and iOS application for a client using their WCF created backend.
We have a method that allows users to checkin for their appointments if they are with in a certain geo location.
Both apps are able to find the server and grab data however the android application only works about 50% of the time (the iOS version works 100%). I have tried on Wifi and Cellular and get the same results.
The biggest issue is I can't even determine if the issue is with the client or server or how should i handle it?
I have read that it could be due to an unclosed httpURLConnection but thats my only real lead at the moment.
Please help!!!
Thanks
Since it works half of the time on android and for iOS always, the problem can be only the network problem by my opinion. It just happens in some network environments and on some of the devices or on some of the device with certain android-java version. I think you will not be able to do anything.
When I started to have those problems, I just always bumped into a simple fact about fallacy of network programming and CAP theorem: Network is reliable. So the fact is that network is NOT reliable and you should consider it in your solutions.
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing
http://en.wikipedia.org/wiki/CAP_theorem
It could be that this problem sometimes gets also into succeeded request but no response problem. Again almost the same network failure problem as above and what you can do is handle the possible timeout exceptions etc. and handle it appropriately on the server and client. So in case of having methods like submittingSomePayment, not use a normal WCF methods, but use enterprise service buses which store the messages into queues and process them and then have additional call that checks the results. See CQRS pattern for example.
http://msdn.microsoft.com/en-us/library/jj591573.aspx
Not very helpful, I know. But a possible answer and my thought about it. Because it annoyed me too. So it could be that you will not be able to do anything about it (except end users handling their network issue by themselves).
I would also log the request in the core beginning of the WCF service method call to exclude any internal WCF behavior (to exclude guessing is a problem in your code). All possible Logging on server and client would be a possible way to go in case you are still convinced the problem is in a code. And also see is this happening on all android devices (LG,... etc.) or only certain with certain java versions.
I am using NDde (http://ndde.codeplex.com/) library to set up a server that receives real-time data through a TCP socket and exposes it through DDE protocol.
It certainly works well, but after a random time (between 2 and 20 minutes) it stops updating the data on DDE clients.
Once it stops responding, I can see int the logs that the TCP data is pushed as expected, and my NDde server calls the Advise method properly. No exceptions are thrown at all.
The problem seems to be in the callback, debugging the library source code seems that ProcessCallback method is not being called anymore.
My system setup is a Windows Server 2012 64 bits
I got the same problem and can't find any solution to fix it. However, for a workaround, I will listen to the update event, and when it is stopped, I will re-initialize the Client object and it should work again.
Not a best solution but it resolves for my problem. Any solution that helps on the root one, will be still really appreciate.
One of the services works fine but the other always throws a Socket Timeout 'forcibly closed' error.
I have portSharingEnabled='true' on both services and the netTcp Port Sharing windows service switched on.
I've done a lot of research on this but am unable to find the cause, any suggestions?
It's not an option to change the port either due to legacy system setup.
Each netTcp Binding looks liks this:
8033:*
Is that right or is the * the issue here? I've run out of ideas as you can tell.
Last point: It definitely isn't a timeout issue as I get the error on the client side instantly each time. All other binding config values are matched on both server/client side and set close to max as suggested by other similar issues here on SO.
Hard to tell for sure. To diagnose the issue further, for the service and the client I would enable WCF Tracing and see if there is an underlying exception. Here's a good blog article on how to create and read the log using the tools included with Visual Studio:
http://www.atulverma.com/2011/10/enable-wcf-tracinglogging-using.html
I have a WCF server hosting clientaccesspolicy.xml (for Silverlight clients) and I was testing access to it using Internet Explorer. When I accessed it using http://localhost/clientaccesspolicy.xml everything worked correctly, but when I used http://machinename/clientaccesspolicy.xml it wasn't retrieved.
I downloaded, installed and ran Fiddler and now the http://machinename/clientaccesspolicy.xml URL works correctly - even without Fiddler running.
Obviously this isn't a scalable solution to the problem so I was wondering if anyone know what Fiddler might have done to fix my issue, or what might have been causing my issue in the first place? Windows Firewall has been disabled throughout my testing.
It turns out our testing systems have Privoxy installed on them incorrectly - it successfully blocked the connection attempts because they weren't whitelisted, but didn't display the error message it should be configured to do so. Fiddler replaced the proxy with its own settings temporarily and hence let it work. Thanks (and an upvote) to Ladislav for the hint.