I have a an admin and a managed server. A JMS server is targeting the admin server. The JMS Module which contains the Queue and the Connection Factory is targetting both the admin and the managed server.
When my application is deployed on the admin server everything works. But when is deployed on the managed server i get the following excpetion
Caused by: javax.naming.NameNotFoundException: Unable to resolve 'CONNECTION_F'. Resolved ''; remaining name 'CONNECTION_F'
I can see from the JNDI tree of the managed that CONNECTION_F is not present...
Am I missing something? Something wrong configured on the domain?
I am using Weblogic 11g.
Please configure your JMS server on the managed server too.
Related
Our infrastructure team has worked to configure a site-to-site Azure VPN connection between our Azure subscription and our on-prem firewall, essentially following these steps. To test this, we've created a simple Azure web app that makes a query against a SQL Server that is located on-prem behind the firewall.
This web app works locally with no issues. Furthermore, the same code and connection string, when compiled as a console application and run on an Azure virtual machine, works correctly as well. But when deployed to the web app in Azure, the connection to the SQL Server fails:
[Win32Exception (0x80004005): The wait operation timed out]
[SqlException (0x80131904): A network-related or instance-specific
error occurred while establishing a connection to SQL Server. The
server was not found or was not accessible. Verify that the instance
name is correct and that SQL Server is configured to allow remote
connections. (provider: TCP Provider, error: 0 - The wait operation
timed out.)]
Both the Azure VM and web app are configured to point to the Azure VNet. It seems like something is preventing the web app from communicating with the SQL Server on its default port (1433). If I open up the web app's debug console and do a tcpping at the SQL Server with the default port (80), it returns successfully. But a tcpping to port 1433 times out.
It doesn't appear that the Azure Network Security Group is blocking that port:
The only solutions I've found that are relevant to our specific setup basically boil down to "use Azure Hybrid Connections instead", which would not be our first choice.
After working with Microsoft's support, the following changes were made and the VNet integration is working now. I apologize for the lack of detail on some of these, but our infrastructure team did most of the troubleshooting. Hopefully, some of these items will help point someone else the direction of a solution for their setup:
Initially, the connection was being made through public internet and not the VNET Integration and VPN. We identified that the VNET integration was failing due to the tunnel type being used. Azure App Service has a requirement that the tunnel type is SSTP. Once we changed it and synced the network, we were able to tcpping the SQL Server through its private IP.
We noticed it had to allow on the on-premises Network the point-to-site address pool. As a workaround, we decided to use the New VNET Integration (Preview). We created an empty subnet and were able to use this new feature.
We noticed then the App Service was not using the custom DNS. To resolve this, we added the DNS on the Virtual Network and also in the App Settings ("WEBSITE_DNS_SERVER") for the web app.
I am not able to connect to my aws-rds instance from asp.net application
I have been trying to connect my asp.net application with my aws-rds instance i have tried using connection strings setting, its doesn't work, but i am also able to connect to my aws-rds database from sql management studio
i also tried to use migration but when i do update-database from console it create a new database in local db
i have also try to provide all required setting and data and then publish my application with aws toolkit but when opening my site link it gives a error -An error occurred while processing your request.
so any can help me with this issue or provide me the proper steps
Check Inbound and outbound rules for instance.
try to connect it with your instance IP.
refer enter link description here
I’m having a very specific issue with Azure and I couldn’t find any solution on the web.
So, we are little by little migrating our client’s infrastructure to Azure and we are starting with our Workers (webjobs).
These webjobs need to consume data present on a AWS SQL Server instance.
We already have checked that the App Service Plan’s Outbound IPs are whitelisted and that the SQL server is listening on TCP port 1433.
An evidence of that is the fact that we are able to communicate with the SQL Server instance through the Azure Debug Console:
But when we run the WebApp, the worker cannot find and connect to the same DB:
Does anyone have a clue of how I can solve this issue? It would be very appreciated!
Well, as you demonstrated by the first image, the SQL Server instance is configured correctly.
The worker Outbound IP address is definetely the same as the App Service Plan's machine.
Based on that, can you then please check if the Connection string you are setting have 'tcp:' before the IP Address?
Sometimes you need to force it, otherwise IIS can choose other ways to connect to your SQL server (like UDP for instance).
I've a hawtio 1.4.45 running in Jetty Server A where my camel application is also deployed. There is another camel application and jolokia web agent running on Jetty Server B. I'm able to get basic camel MBean details from both Server A and Server B. However I get to see the logs of only Server A and NOT Server B's. Is there any JMX settings to bring up the logs of Server B to hawtio Dashboard?
I am using Hawt.io to monitor my Apache Camel java app, but I have found that if I let it run I cannot use jvisualvm (and similar tools) to profile my app. It seems Hawt.io is using the connector that Camel exposes so jvisualvm cannot connect to the jvm.
What can I do to have Hawt.io and still be able to use jvisualvm?
Thank you!
Can JConsole connect to your JVM too?
Hawtio just connects to Jolokia on the server side; which just exposes JMX over HTTP/JSON; so the hawtio console doesn't itself change JMX in any way.
Incidentally are you using Local connector to connect from the hawtio web app into a separate JVM? Only that approach does add a jolokia agent dynamically to the JVM you are trying to connect to. If thats whats causing the issue - don't use it - and just configure your own Jolokia agent in your JVM?