stalled/blocked request
Hi, My short topology: client browser->F5->IIS servers I have a .Net web application. Randomly some request is in stalled/blocked state in browser. For example: I can see a request that spend 7 minutes in stalled state and then it is processed less than 1 second. I can't see high cpu, memory, connection load at this time. The peak connection is 4k, but I think it is not too high. At same time I can see lot of success request also. I think the request is waiting for something on my F5, but I don't know for what. Could anyone help me how can I detect the reason? My opinion is that I reached the connection limit but I can see any error message in log about it. How can I check it? Thanks.
Nginx is only redirecting to port 8080
I have a .net 8 solution multiple APIs and I'm using docker and Nginx to host the application. please find below the full details: Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base WORKDIR /app EXPOSE 8080 FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build ARG BUILD_CONFIGURATION=Release ... FROM build AS publish ARG BUILD_CONFIGURATION=Release RUN dotnet publish "xxx.Api/xxx.Api.csproj" -c Release -o /app/publish /p:UseAppHost=false FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "xxx.Api.dll"] launchsettings.json "Docker": { "commandName": "Docker", "launchBrowser": true, "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}/swagger", "publishAllPorts": true, "useSSL": true, "sslPort": 4430, "httpPort": 8080 } nginx.conf worker_processes auto; events { worker_connections 1024; } http{ server { listen 80; server_name domain; port_in_redirect off; location /api1 { rewrite /api1(.*) $1 break; proxy_pass http://api1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } location /api2 { rewrite /api2(.*) $1 break; proxy_pass http://api2:8081; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } } docker-compose version: '3.4' services: nginx: image: nginx ports: - 80:80 volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro depends_on: - api1 - api2 api1: image: ${DOCKER_REGISTRY-}api1:latest container_name: api1 build: context: . dockerfile: api1.Api/Dockerfile ports: - "8080:8080" api2: image: ${DOCKER_REGISTRY-}api2:latest container_name: api2 build: context: . dockerfile: api2.API/Dockerfile ports: - "8081:8081" API1 that uses port 8080 loads normally but API2 that uses 8081 get error 502 gateway error. If I switch the port on those same projects than API2 loads normally and API1 stops loading. I've been trying all kinds of stuff over last 2 days and nothing seems to work. Those same projects with the same configuration were working perfectly when I was using .net 6 with the same nginx version, but when I upgraded the project to .net 8 it broke. I need your help and suggestions. Anything will be helpfull.
Serialization error calling get_statistics_by_virtual
Using iControl for .NET v11.3 with LTM 12.1.2, I am attempting to use get_statistics_by_virtual for a Client SSL Profile using the iControl for Microsoft.NET. Is this a WSDL definition issue for .NET? I am calling a number of methods that take jagged arrays, but this is the only one where I construct the arrays rather than passing in one I received from another iControl method, and the only one defined as String[][]. Note: f5Cp acquired earlier as LocalLBProfileClientSSL var pArray = new string[1]; var pVsArray = new string[1][]; pArray[0] = pName; pVsArray[0] = new string[1]; pVsArray[0][0] = vsName; var profileClientSslStatistics = f5Cp.get_statistics_by_virtual(pArray, pVsArray); .. stack trace and exception information mostly removed as this site kept identifying that as SPAM Message=There is an error in XML document (13, 2). Message=The specified type was not recognized: name='Array', namespace='http://schemas.xmlsoap.org/soap/encoding/', at .How to get sync information with .Net API
I apologize if this question doesn't make sense or if I'm not posting in the correct location. I am a .Net developer and never even heard of F5 until I was tasked with developing a web interface for controlling our devices. From what I was told, we have a device group of two devices that are set up as a failover. I need to determine if the devices are in sync. I have the name of the device group and the names of both devices. Determine if devices are in sync: This code works, but I'm not sure it makes sense because I would expect to be connecting to the device group, not one of the devices. However, this is the only way I could find to get the sync state. This code returns iControl.ManagementDeviceGroupMemberState.MEMBER_STATE_IN_SYNC. The reason it doesn't make sense to me is because what if the device I'm connecting to is down and the other device is now the active one? In that case, I would not be able to connect, right? Interfaces m_interfaces = new Interfaces(); m_interfaces.initialize("Device1Name", 443, userName, password); dg.SyncStatus = m_interfaces.ManagementDeviceGroup.get_sync_status_overview().member_state;Exporting ASM Policies in C#?
I am exploring the .NET API, and as a test case I'd like to use the export_policy_xml method to export a policy and save the output file to my desktop. I've looked at code samples and read through the API documentation but I haven't found anything that will get me going in the right direction. I am able to connect to our f5 and return bits of information here and there, but I've hit a roadblock trying to export the policy. Thoughts, comments, or suggestions? Thanks!Set Secure and HttpOnly attributes on all Cookies with validation on v10.2.4
I'm on my third round of testing various iRules on DevCentral that would set the secure and httponly attributes. Trying to get an iRule to: 1. Check to see if the HttpOnly atribute is set on all cookies 2. If not, set the HttpOnly and Secure attributes. iRules I'm working with on the next round of testing: when HTTP_RESPONSE { set ck [HTTP::header values "Set-Cookie"] HTTP::header remove "Set-Cookie" foreach acookie $ck { if {![$acookie contains "HttpOnly"]}{ HTTP::header insert "Set-Cookie" "${acookie}; Secure; HttpOnly" } else { HTTP::header insert "Set-Cookie" "${acookie}; Secure" } } } Cookies observed in Fiddler traces at various points (Default i.e. No iRule): 1. First Cookie: Set-Cookie: ASP.NET_SessionId=qub2sxy2hvk155fx1bh3j3ab; path=/; HttpOnly Note: I believe this cookie is being set by the Web tier instance of ASP.NET Second Cookie: Set-Cookie: DBAuth=EFA95F4186FE337A41E80408320FE488F4900985459FBECBF6C06C749C76B8162577371E82BD8B34B13C1B972690A72F9025ED09C74D5BF274CF03E1DAA5B8FAA78914B512FC2ADE50F079C8FF1F2AE7; path=/ Note: I believe this cookie is being set by the App Tier instance of ASP.NET Third Cookie: DBAuthtsy=EFA95F4186FE337A41E80408320FE488F4900985459FBECBF6C06C749C76B8162577371E82BD8B34B13C1B972690A72F9025ED09C74D5BF274CF03E1DAA5B8FAA78914B512FC2ADE50F079C8FF1F2AE7; path=/ Note: I believe this cookie is also being set by the App Tier instance of ASP.NET. This cookie is observed being sent with the Second Cookie. Also the first portion of the cookie, DBAuth stays consistent; however the characters after will vary from site to site, example DBAuthtsy, DBAuthrsy.Is PaaS Just Outsourced Application Server Platforms?
There’s a growing focus on PaaS (Platform as a Service), particularly as Microsoft has been rolling out Azure and VMware continues to push forward with its SpringSource acquisition. Amazon, though generally labeled as IaaS (Infrastructure as a Service) is also a “player” with its SimpleDB and SQS (Simple Queue Service) and more recently, its SNS (Simple Notification Service). But there’s also Force.com, the SaaS (Software as a Service) giant Salesforce.com’s incarnation of a “platform” as well as Google’s App Engine. As is the case with “cloud” in general, the definition of PaaS is varied and depends entirely on to whom you’re speaking at the moment. What’s interesting about SpringSource and Azure and many other PaaS offerings is that as far as the customer is concerned they’re very much like an application server platform. The biggest difference being, of course, that the customer need not concern themselves with the underlying management and scalability. The application however, is still the customer’s problem. That’s not that dissimilar from what enterprise-class organizations build out in their own data centers using traditional application server platforms like .NET and JavaEE. The application server platform is, well, a platform, in which multiple applications are deployed in their own cozy little isolated containers. You might even recall that JavaEE containers are called, yeah, “virtual machines.” And even though Force.com and Google App Engine are proprietary platforms (and generally unavailable for deployment elsewhere) they still bear many of the characteristic marks of an application server platform.How AJAX can make a more agile enterprise
In general, we talk a lot about the benefits of SOA in terms of agility, aligning IT with the business, and risk mitigation. Then we talk about WOA (web oriented architecture) separately from SOA (service oriented architecture) but go on to discuss how the two architectures can be blended to create a giant application architecture milkshake that not only tastes good, but looks good. AJAX (Asynchronous JavaScript and XML) gets lumped under the umbrella of "Web 2.0" technologies. It's neither WOA nor SOA, being capable of participating in both architectural models easily. Some might argue that AJAX, being bound to the browser and therefore the web, is WOA. But WOA and SOA are both architectural models, and AJAX can participate in both - it is neither one or the other. It's seen as a tool; a means to an end, rather than as an enabling facet of either architectural model. It's seen as a mechanism for building interactive and more responsive user interfaces, as a cool tool to implement interesting tricks in the browser, and as yet another cross-browser incompatible scripting technology that makes developer's lives miserable. But AJAX, when used to build enterprise applications, can actually enable and encourage a more agile application environment. When AJAX is applied to user-interface elements to manipulate corporate data the applications or scripts on the server-side that interact with the GUI are often distilled into discrete blocks of functionality that can be reused in other applications and scripts in which that particular functionality is required. And thus services are born. Services that are themselves agile and thus enable broader agility within the application architecture. They aren't SOA services, at least that's what purists would say, but they are services, empowered with the same characteristics of their SOA-based cousins: reusable and granular. The problem is that AJAX is still seen as an allen wrench in an architecture that requires screwdrivers. It's often viewed only in terms of building a user interface, and the services it creates or takes advantage of on the back-end as being unequal to those specifically architected for inclusion in the enterprise SOA. Because AJAX drives the development of discrete services on the server-side, it can be a valued assistant in decomposing applications into its composite services. It can force you to think about the services and the operations required because AJAX necessarily interacts with granular functions of a service in a singular fashion. If we force AJAX development to focus on the user-interface, we lose some of the benefits we can derive from the design and development process by ignoring how well AJAX fits into the service-oriented paradigm. We lose the time and effort that goes into defining the discrete services that will be used by an AJAX-enabled component in the user-interface, and the possibility of reusing those services in the broader SOA. An SOA necessarily compels us to ignore platform and language and concentrate on the service. Services deployed on a web server utilizing PHP or ASP or Ruby as their implementation language are no different than those deployed on heavy application servers using JSP or Java or .NET. They can and should be included in the architectural design process to ensure they can be reused when possible. AJAX forces you to think in a service-oriented way. The services required by an AJAX-enabled user-interface should be consistent with the enterprise's architectural model and incorporated into that architecture whenever possible in order to derive agility and reuse from those services. AJAX is inherently an agile technology. Recognizing that early and incorporating the services required by AJAX-enabled components can help build a more agile, more consistent, more SOA-like application infrastructure.
