Can we configure datasources in weblogic 10 such that any error from that datasource does not stop starting the server in RUNNING mode? As of now when the datasource fails, the server starts in Admin mode.
I know I can do Resume from admin console in such situation. But I would want it to be autmoatic.
My application does not need that datasource to be up. It will impact only a specific module if this datasource fails.
Set the initial number of connection to open as 0 then it will skip the datasource at startup. It will create connection when your application module demands it at runtime.
Related
Goal:
In picture I want to change app name only "app" strong text
Question:
Can I change or update deployed weblogic application name without stop managed server?
Additional information after a while. If you want to change application name in weblogic wlst console, it takes error message.
This shows us weblogic ApplicationName property is a read only property.
No. You cannot change the name even if you stop managed server. You have to redeploy the application specifying the name you want or manipulate config.xml and restart all server(Not recommended as it can cause issues if not done correctly).
I have Report Builder 3.0 installed on my local PC. I am creating a new report and adding an embedded data source to a SQL Server Analysis Services database.
When I build the connection string of the data source, choosing the server name and the database name, I click 'Test Connection' and receive a message saying "Test connection succeeded". So far, so good.
I close the connection properties with the OK button, and on the Data Source Properties window I click the 'Test Connection' button. This time I get an error saying "The connection either timed out or was lost".
If I ignore the error then I can successfully add a dataset to my report and add data from the dataset in to the report design, but when I try to run the report (on my local PC) I again get an error connecting to the data source.
My best guess is that the connection that succeeded is running under my credentials, whereas the connection that fails is running as some other credential and so needs to use Kerberos delegation to pass my credentials along, but that is only a guess and even if I am correct I am at a loss to understand how to fix the issue - I don't know what other credentials may be being used and I have already set SPN's for the Analysis Services service account.
So it turns out that it was a Kerberos issue as I suspected, and I was also correct that Report Builder was testing the connection using some process running under another authentication context.
It turns out that when setting up Report Builder (and I had forgotten it) that you specify a default SSRS Report Server (see screenshot). It must be that when testing data sources or running reports that it connects to that default Report Server and does the work from there - I was assuming that everything was running locally!
Once I figured that out it was just a case of finding a good guide on how to configure SSRS for Kerberos and everything started working. In my case the only bit that I hadn't already done was to add the <RSWindowsNegotiate/> setting to the AuthenticationTypes in the rsreportserver.config file
I am trying to port an application from WebLogic to JBoss EAP 6.2.
When running the standalone server in JBoss, in the admin console there is a button and in the command line interface there is a command line option to check the data source connection.
/subsystem=datasources/data-source=myds:test-connection-in-pool
These options do not appear to exist in either place when running the "domain" server. Am I missing something? Is there some further setting I must make to enable it? I tried a technique which is sometimes an analog in the domain server and it doesn't work here.
/profile=full/subsystem=datasources/data-source=myds:test-connection-in-pool
JBoss docs are much weaker for "domain" model than for "standalone".
You are absolutely correct that while running the standalone server in JBoss, in the admin console there is a button and in the command line interface there is a command line option to check the data source connection butThese options do not appear to exist in either place when running the "domain" server.
You still can use the command line of jboss-eap-6.x to test the configured data source connection in domain server. You need to navigate to $JBOSS_HOME/bin/ and execute script: jboss-cli.sh
Connect to the domain server controller with: connect :PORT_NO and execute the following commands:
For XA-DataSource:
/host=$Host_Controller_Name/server=$Server_Name/subsystem=datasources/xa-data-source=DataSource_JNDI_Name:test-connection-in-pool
For Non-XA-DataSource:
/host=$Host_Controller_Name/server=$Server_Name/subsystem=datasources/data-source=DataSource_JNDI_Name:test-connection-in-pool
When I try to start up a websphere portal server, it hangs at the line :
Server WebSphere_Portal open for e-business
and although it means that the server started up successfully, it is not...because in the progress bar, i stll see 'Starting.....' I have tried deleting the wstemp and temp directories but beyond that I am not sure what I can do to debug the problem.
The server with the same profile starts up great from another workspace, but when I come to this workspace, it just hangs at
Server WebSphere_Portal open for e-business
I am using RAD 7 and portal 6.1
Kaushik,
Try and change the connection type between RAD and WebSphere Portal.Switch it between SOAP and RMI and see if that makes a difference.
Double click the server and in the property editor you can specify the connection method.
Check this link out
http://www-01.ibm.com/support/docview.wss?uid=swg21207553
HTH
Manglu
why this error comes?
I am using windows authentication. But i am getting error
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
can any one help me in this how to solve this problem?
Most likely it means you're trying to connect from an impersonated context and you did not set up constrained delegation. See Manage Kerberos Authentication Issues in a Reporting Services Environment for details and troubleshooting.
First of all, I always prefer to use the 'impersonation' settings in the ISS configuration that do not set the user/password in the web.config. Everything was fine in the QA environment, but then I passed to the production environment and some options of the web site in production started to show the 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error.
The issue was that I copied the web-site configuration from the QA server, using the 'Save configuration to a file' option in IIS6 while creating a brand new Application Pool in the production server.
After several hours trying to solve this error, I just deleted the Application Pool, and used the 'Save configuration to a file' option to copy the Application Pool configuration and then restored it to the new server.
If you copy the web-site configuration, also copy the Application Pool configuration. That solved my problem, without changing anything about the authentication method, the database or the web-site itself.
Reporting Setup:
I had a report accessing datasource A, with a subreport which accessed datasource B.
The report connections were set to use Integrated Security.
From my development machine:
The "main" report would run perfectly fine from my development environment (as it was running everything as me.)
From the server:
I was able to execute the subreport directly, with no problem.
The main report would run, with the text "Error: Subreport could not be shown."
Actual Problem:
The subreport was executing under the NTAUTH\ANON user, because it was the Reporting Services code which was calling the sub-report. This error was in the SSRS Logs:
System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Solution:
Set up the sub-report data connection to execute using a SQL User login.
Only grant that user execute on the particular procedure you're calling for the report.
This allowed me to get the report working without involving other departments that controlled the application servers (modifying web.configs or IIS configurations)