Problems in WLS 7.0

Hi All,
I have heard the CacheMonitorRuntimeMBeans in the WLS7.0.I have listed the runtime
mbeans in the server but the cache monitor runtime mbeans does not exist in the
server. I wanna access their methods which are mentioned below:
(A) getAccessCount()
(B) getAccessTime()
(C) getCurrentSize()
(D) getCurrentTotalEntries()
(E) getHitCount()
Is the CacheMonitorRuntimeMBeans does not exist in the default server.Is it
neccessary to deploy some components in the Weblogic Server 7.0 to make the CacheMonitorRuntimeMBean
visible.
Any help will be greatly appreciated.
/Bala

Similar Messages

General install and deployment problem with WLS clustering on two boxes

Hi,
I've come across a general installation problem with WLS with a cluster spanning two different physical machines and two Managed Servers, one Managed Server per physical machine.
The problem is, starting from scratch, you install WLS on both physical machines. You can then use the config wizard to create the domain, cluster and managed servers, but this is a manual typing in process.
So we've now got a WLST Script which we run with "java weblogic.WLST domaincreate.py domain.properties". This is good as it creates the domain, cluster, managed servers and JMS modules.
Now the trouble is, it doesn't do anything to the 2nd physical machine which will be running only the 2nd Managed Server.
One dirty way to get around this in order to start the 2nd managed server was to copy the domain directory to the 2nd server, but I'm sure this is bad practice and what you can actually do is improve the WLST script to actually, but the same as the config wizard and dump the nessary information to the 2nd physical machine in order so you don't need to copy the domain directory across so that it will startup straight after running the WLST.
Any help appriecated.
Surfbum.

Hi I think I've found the answer. You can build a managed server template using the pack command.
http://e-docs.bea.com/common/docs90/pack/tasks.html

Apache-soap Problem with WLS 5.1sp9

I have problem with WLS 5.1sp9.
My environment is the following :
jaf-1.0.1
javamail-1.2
soap-2.2
xerces-1.4.4
and I want to call EJB.
So, I write some EJB and deploy it.
And rpcrouter work!!
Success to deploy the Service.
But I run into problem with calling this ejb.
This error is the following.
SOAP-ENV:Server.BadTargetObjectURI
Unable to resolve target object: BC2_BoardSync
please, help me.
here's my example..
ps.
sorry for my poor English..T_T
[ws5.10.zip]
[vb.zip]

I have problem with WLS 5.1sp9.
My environment is the following :
jaf-1.0.1
javamail-1.2
soap-2.2
xerces-1.4.4
and I want to call EJB.
So, I write some EJB and deploy it.
And rpcrouter work!!
Success to deploy the Service.
But I run into problem with calling this ejb.
This error is the following.
SOAP-ENV:Server.BadTargetObjectURI
Unable to resolve target object: BC2_BoardSync
please, help me.
here's my example..
ps.
sorry for my poor English..T_T
[ws5.10.zip]
[vb.zip]

JDBC Type 3 driver problem with WLS 6.1 SP4

We have Oracle 8.1.7.4 client running on WebLogic 6.1 SP4 on Solaris 2.6 connecting to Oracle OPS 8.1.7 running on Solaris 2.6. We are getting core dumps while running stress testing using Load Runner for 100 concurrent users. The performance is very good for a while in the beginning of the test and all of a sudden we see requests for connections queueing up on the WLS and the server crashes. Please send us details of any previous instances any one faced similar problem and the fix applied will be very helpful.
Regards,
Raj

The Member Feedback forum is for suggestions and feedback for OTN Developer Services. This forum is not monitored by Oracle support or product teams and so Oracle product and technology related questions cannot be answered. We recommend that you post this thread to the SQLJ/JDBC forum.
The URL is: http://forums.oracle.com/forums/forum.jsp?forum=99
Thanks, OTN Team

Spring 2.5.5 and EJB 3.0 Deployment problem in WLS 10.3

Hi,
I am attempting to deploy a EAR file that previously ran on SJSAS 9.1 update 1 to WLS 10.3. As part of the deployment I get the following error related to the EJB3 classes.
There are 1 nested errors: weblogic.j2ee.dd.xml.AnnotationProcessException: [EJB:015002]Unable to load class au.edu.cqu.cis.web.ajaxservice.AjaxServicesBean in Jar D:\dev\env\oracle\middleware\jdeveloper\system\system11.1.1.0.31.51.56\DefaultDomain\servers\DefaultServer\tmp\_WL_user\ProgEnrol-ear-3\v540rk\ProgEnrol-ejb-3.0.4-SNAPSHOT.jar : java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
I suspect that this is related to the @Autowired spring annotation in use in the session bean. Either, the server is not finding the Spring JAR correctly or it has a problem with the annotation.
Can anyone point me in the right direction? Do I need to deploy the spring jar as a library?
Thank you.
Regards,
Graeme.

Hi, Graeme.
Seems there is an existing CR on something related from v10.0: CR353213
* WLS 10.0 - EJB 3.0 deployment fails when parsing class for Stateless annotation
According to http://edocs.bea.com/wls/docs103/issues/known_resolved.html, this is not addressed in 10.3
Closely review your classpath, and then (assuming you have access to the source) review the body of your ejb. If it is related to this CR, you may be able to workaround the issue by shortening the body and split large methods into more sub-methods.
I hope this helps,
-Adrian

Enterprise application conversion problem from WLS 10.3.0 to WLS 10.3.2

Hi all,
I'm posting this just to document a problem I had when converting an Enterprise Application from WLS 10.3.0 across to WLS 10.3.2 environment.
Upon deployment of the application I was getting this error:
Caused By: weblogic.descriptor.BeanAlreadyExistsException: Bean already exists: "weblogic.j2ee.descriptor.wl.ApplicationParamBeanImpl@b720894d(/ApplicationParams[webapp.encoding.default])"
 at weblogic.descriptor.internal.ReferenceManager.registerBean(ReferenceManager.java:227)
 at weblogic.j2ee.descriptor.wl.WeblogicApplicationBeanImpl.setApplicationParams(WeblogicApplicationBeanImpl.java:560)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at com.bea.staxb.runtime.internal.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:48)
 at com.bea.staxb.runtime.internal.RuntimeBindingType$BeanRuntimeProperty.setValue(RuntimeBindingType.java:536)
 at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType$QNameRuntimeProperty.fillCollection(AttributeRuntimeBindingType.java:381)
 at com.bea.staxb.runtime.internal.MultiIntermediary.getFinalValue(MultiIntermediary.java:52)
 at com.bea.staxb.runtime.internal.AttributeRuntimeBindingType.getFinalObjectFromIntermediary(AttributeRuntimeBindingType.java:140)
 at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalBindingType(UnmarshalResult.java:200)
 at com.bea.staxb.runtime.internal.UnmarshalResult.unmarshalDocument(UnmarshalResult.java:169)
 at com.bea.staxb.runtime.internal.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:65)
 at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:150)
 at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:323)
 at weblogic.application.descriptor.AbstractDescriptorLoader2.getDescriptorBeanFromReader(AbstractDescriptorLoader2.java:788)
 at weblogic.application.descriptor.AbstractDescriptorLoader2.createDescriptorBean(AbstractDescriptorLoader2.java:409)
 at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBeanWithoutPlan(AbstractDescriptorLoader2.java:759)
 at weblogic.application.descriptor.AbstractDescriptorLoader2.loadDescriptorBean(AbstractDescriptorLoader2.java:768)
 at weblogic.application.ApplicationDescriptor.getWeblogicApplicationDescriptor(ApplicationDescriptor.java:329)
 at weblogic.application.internal.EarDeploymentFactory.findOrCreateComponentMBeans(EarDeploymentFactory.java:181)
 at weblogic.application.internal.MBeanFactoryImpl.findOrCreateComponentMBeans(MBeanFactoryImpl.java:48)
 at weblogic.application.internal.MBeanFactoryImpl.createComponentMBeans(MBeanFactoryImpl.java:110)
 at weblogic.application.internal.MBeanFactoryImpl.initializeMBeans(MBeanFactoryImpl.java:76)
 at weblogic.management.deploy.internal.MBeanConverter.createApplicationMBean(MBeanConverter.java:88)
 at weblogic.management.deploy.internal.MBeanConverter.createApplicationForAppDeployment(MBeanConverter.java:66)
 at weblogic.management.deploy.internal.MBeanConverter.setupNew81MBean(MBeanConverter.java:314)
 at weblogic.deploy.internal.targetserver.operations.ActivateOperation.compatibilityProcessor(ActivateOperation.java:81)
 at weblogic.deploy.internal.targetserver.operations.AbstractOperation.setupPrepare(AbstractOperation.java:295)
 at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:97)
 at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
 at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
 at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
 at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
 at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157)
 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12)
 at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:516)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
It turns out this was an issue with the META-INF/weblogic-application.xml having duplicate entries for the "webapp.encoding.default" parameter.
This obviously got duplicated when my app was re-imported into the Eclipse OPEP environment for WLS 10.3.2
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd">


<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>
<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>
</wls:weblogic-application>
Removing the duplicate entry resolved this problem.
I hope this helps anyone else that experiences this issue.
Regards,
Paul

Below link might be helpful.
http://kr.forums.oracle.com/forums/thread.jspa?threadID=1049509&tstart=0
Regards,
Anandraj
http://weblogic-wonders.com/

Oracle XA driver problem with WLS 7.0.1.0, Oracle 9.0.1

We are using simplified chinese, after swith to bea jdriver, it messed up
all the encoding. So we cannot display Chinese character correctly.
We are using WLS 7.0.1.0, Oracle 9.0.1 on both Windows and Solaris 8
environment, BEA supplied JDK 1.3.1_03.
We have many diffrent problems with oracle drivers:
1. We want to use XA driver to support distributed transaction, However:
* bea jdriver xa messes up with encoding
* when using oracle 901 driver, everything works fince except webservices.
Workshop application access the ejb, then the workshp application sets
isolation level, but oracle driver does not support it and gives error. Is
there a way to turn off isolation level in workshop? I tried manually edit
weblogic-ejb-jar.xml, however,workshop cannot redeploy it after that.
2. When not using XA, oracle thin driver works fine. But we lost XA
capability.
Any work around?

I did try to change the value in this config file as well, but did not help.
In fact, the installation default setting is with
'<transaction-isolation-level>' commented out.
And when I use bea oracle jdriver, it somehow messed up with database
character set encoding, so our Chinese characters could not be retrieved
correctly. And I try to set the encoding of jdriver to 'GBK', it did not
work.
"Anurag Pareek" <[email protected]> Ð´ÈëÏûÏ¢ÐÂÎÅ
:[email protected]..
Hello Ma,
The transaction isolation level value for EJBs backing the JWS files is
specified in the <transaction-isolation-level> tag in the
WEB-INF/weblogic-jws-config.xml file of a Workshop project. You can
manipulate this value to serve your purpose.
Please do let me know how it goes.
Regards,
Anurag
Workshop Support
"Ma Jie" <[email protected]> wrote in message
news:[email protected]..
We are using simplified chinese, after swith to bea jdriver, it messed
up
all the encoding. So we cannot display Chinese character correctly.
We are using WLS 7.0.1.0, Oracle 9.0.1 on both Windows and Solaris 8
environment, BEA supplied JDK 1.3.1_03.
We have many diffrent problems with oracle drivers:
1. We want to use XA driver to support distributed transaction, However:
* bea jdriver xa messes up with encoding
* when using oracle 901 driver, everything works fince exceptwebservices.
Workshop application access the ejb, then the workshp application sets
isolation level, but oracle driver does not support it and gives error.Is
there a way to turn off isolation level in workshop? I tried manuallyedit
weblogic-ejb-jar.xml, however,workshop cannot redeploy it after that.
2. When not using XA, oracle thin driver works fine. But we lost XA
capability.
Any work around?

Clustering Problems with WLS 4.5.1

Hi!
          I'm trying to configure a WebLogic 4.5.1 cluster (named "cluster1", on two
          WinNT4 SP5 servers (instances WLS "server A" and "server B")
          When I start each WLS instance in each server, both create a cluster where I
          can only find one WLS server, not two! So I have on each NT server, one
          cluster which contain one WLS server!!!
          To see that, I use the WLS console on the 2 servers, and I see that in each
          server, there is a cluster "cluster1" and only one server ("server A" in the
          first NT Server, and "server B" in the second one).
          The two server are identical, same OS, same SP, same WLS version, same WLS
          Service Pack, same IP Multicast address, same TCP port (7001), and there is
          no multihoming.
          I can't see how to put the two WLS servers in the same cluster!
          Do someone have a clue?
          Best regards,
          Jean-Michel Gautreau
          [email protected]


Here is a console screendump, taken after the two WLS servers' boot.
          I forgot to tell we have installed WLBS on both NT servers, before
          installing WebLogic 4.5.1. Is there a problem in the communication between
          the two servers? I'm not sure but I feel it is a network problem, the two NT
          servers don't seem to communicate correctly through WLBS with the WLS
          cluster?
          Any hint?
          [dump.bmp]

Problems with WLS 4.5.1 and F5 Big IP HA+ Switch

Hello. We're having problems with our F5 Big IP HA+ switch and pool of WLS
          4.5.1 servers (two in the pool currently). At seemly random intervals the
          Big IP believes the one or both of the servers are not responding, so they
          are removed from the pool. We have a growing body of anecdotal evidence to
          suggest that the servers are actually on-line and available during the
          event. Either the switch is confused or the WLS servers aren't always
          responding correctly to the HTTP requests sent by the switch for polling.
          We're having problems catching the problem with the right diagnostics.
          Has anyone out there observed similar behavior with these components?
          Thanks.
          - Sean McRae


Sort of,
          I use iplanet between the 2, so I havent had this problem, but I have had
          several problems with clustering, here is what I recomend doing:
          write a simple java program (or whatever your prefered language) to do a HTTP
          ping on your distinct weblogic servers every X seconds/minutes where X is less
          than Big IPs death tolerance. Time how long/or if ever each of your pings take.
          turn on verbose gc.
          My guess is its one of 3 things:
          1.) your have a big gc going on and your server isnt responding quick enough
          and big ip is marking it dead
          2.) you have thread contention that is causing your server not to respond quick
          enough
          3.) your network has some issues and the packets arent making it there, or not
          quick enough.
          the ping program will prove/disprove #2 and lead you to or away from 3. Verbose
          gc will prove/disprove #1.
          hope this helps
          -Joel
          Sean wrote:
          > Hello. We're having problems with our F5 Big IP HA+ switch and pool of WLS
          > 4.5.1 servers (two in the pool currently). At seemly random intervals the
          > Big IP believes the one or both of the servers are not responding, so they
          > are removed from the pool. We have a growing body of anecdotal evidence to
          > suggest that the servers are actually on-line and available during the
          > event. Either the switch is confused or the WLS servers aren't always
          > responding correctly to the HTTP requests sent by the switch for polling.
          > We're having problems catching the problem with the right diagnostics.
          >
          > Has anyone out there observed similar behavior with these components?
          >
          > Thanks.
          >
          > - Sean McRae

ConnectionPool problems with WLS 7.0 and Oracle 9.2

Hi,
We are using WLS 7.0 SP4, and Oracle 9 and the Oracle thin driver type 4. In our
application on the productive system (and only there) we constantly encounter
a whole set of SQLExceptions which have all in common that the Connection from
the pool is not valid any more when the application tries to use it.
Typical, recurring error messages are:
- Exhausted ResultSet
- Connection has already been closed
- Closed Statement
- Transaction is no longer active - status committing
- NullPointerException at
weblogic.jdbc.pool.Connection.prepareStatement()
There are no special Statements which create these errors. They are spread at
random across practically every query the application creates, and the same queries
sometimes succeed and sometimes fail.
I double and triple checked that all Connections, Statements and ResultSets are
closed immediately after use. As an example, I attached a code snippet and a resulting
StackTrace which.
The problem also seems to occur only with an (unknown) minimum of concurrent usern,
since in the approval tests on an almost identical test system these errors never
occurred.
I also followed the advice from Oracle and installed the latest Oracle JDBC driver
(Oracle 10g) - to no avail.
What else can I do?
Another question: Is it correct that my Oracle JDBC driver is in the application
classpath (via a reference in the Manifest file of the application jar), not in
the system classpath? There has never been a problem with that, but in a Newsgroup
answer from Nov 10, 2003 (subject: "ResultSet closes prematurely"), Joe Weinstein
suggested to "get it listed at the
front of the -classpath argument that the startWebLogic script creates for the
java line that starts the server".
I hesitate to do so, since the driver is in a standard WebApp- directory, WEB-INF/lib.
Is it possible and safe to add a jar located there to the system classpath? If
it is possible, why is it necessary?
Best regards,
Andreas Zehrt
[CodeSnippetsAndStackTraceForConnectionPoolProblem.txt]

Andreas Zehrt wrote:
Hi Joe,
Your hint that there is a threading problem was right:
On further investigation of the code I found out that the class that passes the
Connection to the DAO not only stores it as a member at some point (which is not
a good idea anyway) but is also a singleton - then, of course, it's no surprise
that the Connection gets invalid in a incalculable way when concurrent threads
share it.
The singleton instantiation was not so obvious because the way of instantiation
is controlled by a configuration parameter that can be overridden at different
levels.
I changed it and the productive logfiles indicate that the SQLExceptions related
to that class have disappeared.I am happy to have helped.
So, thanks a lot for the advice.
But I am still wondering why this code has worked for so long a time with WLS
5.1 and Oracle 8 (the system has been productive for over 2 years). Even in the
approval tests with WLS 7.0 and Oracle 9, we did not run into problems, although
it was multi-user environment.Mo idea.
I still believe that there is a difference between WLS 5.1 and 7.0 in the way
it treats pooled Oracle JDBC Connections. I wished both Oracle and Bea could be
a little more explicit about those changes and possible version incompatabilities
beyond the general advice "use the latest thin driver".Though I can think of no change to our pooling which would have had any material
effect in this case, I will certainly do what I can to see that our documentation
is explicit about changes.
Joe
Best regards, Andreas
Joe Weinstein <[email protected]> wrote:
Hi Andreas.
Andreas Zehrt wrote:
Hi,
We are using WLS 7.0 SP4, and Oracle 9 and the Oracle thin driver type4. In our
application on the productive system (and only there) we constantlyencounter
a whole set of SQLExceptions which have all in common that the Connectionfrom
the pool is not valid any more when the application tries to use it.
Typical, recurring error messages are:
- Exhausted ResultSetThat is typically if the statement that created it is either re-executed
or closed.
- Connection has already been closedAs described. If you give a stacktrace, we could make a debug patch which
would show
where it was originally closed.
- Closed Statementsame as above.
- Transaction is no longer active - status committingThat implies your code is obtaining a connection from a transactional
datasource,
and then later trying to use it after the transaction which it was associated
with,
is finished.
- NullPointerException at
weblogic.jdbc.pool.Connection.prepareStatement()Maybe any of the above.
There are no special Statements which create these errors. They arespread at
random across practically every query the application creates, andthe same queries
sometimes succeed and sometimes fail.
I double and triple checked that all Connections, Statements and ResultSetsare
closed immediately after use. As an example, I attached a code snippetand a resulting
StackTrace which.
The problem also seems to occur only with an (unknown) minimum of concurrentusern,
since in the approval tests on an almost identical test system theseerrors never
occurred.
I also followed the advice from Oracle and installed the latest OracleJDBC driver
(Oracle 10g) - to no avail.
What else can I do?
Another question: Is it correct that my Oracle JDBC driver is in theapplication
classpath (via a reference in the Manifest file of the applicationjar), not in
the system classpath? There has never been a problem with that, butin a Newsgroup
answer from Nov 10, 2003 (subject: "ResultSet closes prematurely"),Joe Weinstein
suggested to "get it listed at the
front of the -classpath argument that the startWebLogic script createsfor the
java line that starts the server".
I hesitate to do so, since the driver is in a standard WebApp- directory,WEB-INF/lib.
Is it possible and safe to add a jar located there to the system classpath?If
it is possible, why is it necessary?I was only concerned to ensure we know which driver we are working with.
We also ship
an oracle thin driver, which becomes obsolete soon...
I am concerned that your code creates pool connections to be used later.
The problems
can arise if more than one thread ever gets the same connection, or if
the connection
is used in the same thread, spanning transactions. It does also seem
that there may
be a threading issue, because if two threads each call the code to create
a connection,
and two connections are made, but one over-writes the other, the two
threads can
end up using the same connection, and closing it. The over-written one
never gets closed,
resulting in that leak message you got...
Joe
The Connection parameter is opened by a business component class, ComaServiceProviderClassicImpl.It is propagated through
several classes in the business layer, but not used, until the DAOtakes it to make the query.
So, the Connection is closed where it was opened, not in the DAO class.
public class ConcernDAOImpl extends BaseDAO {
 public Collection getConcernsForIncidents(Connection conn, Collectionincidents)
throws DataAccessException, ConstraintException, ComaParseException{>
sqlMessage.append(")");
String sqlStmt = sqlMessage.toString();
PreparedStatement pstmt = null;
ResultSet rs = null;
try {
pstmt = conn.prepareStatement(sqlStmt);
rs = pstmt.executeQuery();
while (rs != null && rs.next()) {
final Concern concern =
new Concern(DAOUtil.getComaOID(rs, ComaDBNames.KDANR));
concern.setIncidentOID(DAOUtil.getComaOID(rs, ComaDBNames.KDAVGENR));
return concerns;
} catch (SQLException sqle) {
// Wrapps real SQL exception
String[] message = new String[]{sqle.getMessage(), sqlStmt};
throw new DataAccessException(ExpCode.S_ORACLE_SQL, message,
sqle);
} finally {
closeAll(rs, pstmt);
_logger.exitDebug(method);
Here, the Connection is acquired and finally closed
public class ComaServiceProviderClassicImpl {
 public void updateComplaint(
final Request updateRequest,
final ResponseSingleElement response,
final Principal principal)
throws SystemException {
try {
logger.info("updateComplaint", "store incident");
// store the incident in the database
incidentManager.storeIncident(getConnection(), updateIncident);
// reload the incident from Cache and / or the databaseto get the ContactReferences.
Incident returnIncident = incidentManager.loadIncident(//IncidentManager passes the Connection to the DAO
getConnection(), updateIncident.getOID());
} catch (RemoteException rex) {
// remote exceptions
rollbackIfNecessary();
CoreUtils.unwrapRemoteException(rex, logger);
} catch (SystemException e) {
// all other exceptions --> rollback if necessary and rethrow
rollbackIfNecessary();
throw e;
} finally {
removeConnection();
logger.exitDebug("updateComplaint");
This is the resulting StackTrace:
sql exception: [Closed Statement: next] - sql statement: [select *
 at de.deutschepost.ubbrief.coma.persistence.dao.ConcernDAOImpl.getConcernsForIncidents(ConcernDAOImpl.java:363)
 at de.deutschepost.ubbrief.coma.persistence.dao.CachingConcernDAOImpl.getConcernsForIncidents(CachingConcernDAOImpl.java:129)
 at de.deutschepost.ubbrief.coma.persistence.incidentmanager.IncidentManagerImpl.loadConcernStructuresIntoIncidents(IncidentManagerImpl.java:1067)
 at de.deutschepost.ubbrief.coma.persistence.incidentmanager.IncidentManagerImpl.loadStructureForIncident(IncidentManagerImpl.java:320)
 at de.deutschepost.ubbrief.coma.persistence.incidentmanager.IncidentManagerImpl.loadIncidents(IncidentManagerImpl.java:264)
 at de.deutschepost.ubbrief.coma.persistence.taskmanager.TaskManagerImpl.selectTasksForUser(TaskManagerImpl.java:299)
 at de.deutschepost.ubbrief.coma.service.z2.ComaServiceProviderZ2Impl.getTaskList(ComaServiceProviderZ2Impl.java:113)
 at de.deutschepost.ubbrief.coma.service.z2.ComaServiceProviderZ2Bean_1dhrj7_EOImpl.getTaskList(ComaServiceProviderZ2Bean_1dhrj7_EOImpl.java:154)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList.runServiceMethod(CMPGetTaskList.java:64)
 at de.deutschepost.ubbrief.coma.sbbx.sp.BasicMethodProvider.execute(BasicMethodProvider.java:145)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl.execute(CMPGetTaskList_9b9mv5_EOImpl.java:46)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl_WLSkel.invoke(UnknownSource)
 at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:159)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:263)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:230)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl_WLStub.execute(UnknownSource)
 at de.deutschepost.ubbrief.backbone.jazz.impl.core.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:115)
 at de.deutschepost.ubbrief.backbone.common.impl.core.rpc.server.ServerKernelImpl.handleTransportMessage(ServerKernelImpl.java:270)
 at de.deutschepost.ubbrief.backbone.common.impl.core.messaging.MessageTransport.handleMessage(MessageTransport.java:454)
 at de.deutschepost.ubbrief.backbone.common.impl.core.KernelFacade.handleMessage(KernelFacade.java:209)
 at de.deutschepost.ubbrief.backbone.jazz.impl.backbone.BackboneBean.messageArrived(BackboneBean.java:637)
 at de.deutschepost.ubbrief.backbone.jazz.impl.backbone.BackboneBean_ina9d7_ELOImpl.messageArrived(BackboneBean_ina9d7_ELOImpl.java:105)
 at de.deutschepost.ubbrief.backbone.jazz.impl.transport.receive.LocalQueueReceiveBean.deliverMessage(LocalQueueReceiveBean.java:43)
 at de.deutschepost.ubbrief.backbone.jazz.impl.transport.receive.AbstractMessageReceiveBean.onMessage(AbstractMessageReceiveBean.java:127)
 at weblogic.ejb20.internal.MDListener.execute(MDListener.java:377)
 at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:311)
 at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:286)
 at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2351)
 at weblogic.jms.client.JMSSession.execute(JMSSession.java:2267)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)
####<May 26, 2004 12:18:43 PM CEST> <Warning> <JDBC> <S0048016> <REMA20Z><Finalizer> <kernel identity> <> <001074> <A JDBC pool connection leak
was detected. A Connection leak occurs when a connection obtained from
the pool was not closed explicitly by calling close() and then was disposed
by the garbage collector and returned to the connection pool. The following
stack trace at create shows where the leaked connection was created.
Stack trace at connection create:
 at weblogic.jdbc.pool.Connection.<init>(Connection.java:66)
 at weblogic.jdbc.pool.Driver.allocateConnection(Driver.java:294)
 at weblogic.jdbc.pool.Driver.connect(Driver.java:210)
 at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:373)
 at weblogic.jdbc.jts.Driver.connect(Driver.java:129)
 at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:287)
 at de.deutschepost.ubbrief.coma.core.ComaComponentImpl.getConnectionFromPool(ComaComponentImpl.java:163)
 at de.deutschepost.ubbrief.coma.core.ComaComponentImpl.getConnectionInternal(ComaComponentImpl.java:135)
 at de.deutschepost.ubbrief.coma.core.ComaComponentImpl.getConnection(ComaComponentImpl.java:99)
 at de.deutschepost.ubbrief.coma.persistence.customermanager.CurryCustomerManagerImpl.findCustomers(CurryCustomerManagerImpl.java:73)
 at de.deutschepost.ubbrief.coma.service.z2.ComaServiceProviderZ2BaseImpl.resolveCustomerInstances(ComaServiceProviderZ2BaseImpl.java:808)
 at de.deutschepost.ubbrief.coma.service.z2.ComaServiceProviderZ2Impl.getTaskList(ComaServiceProviderZ2Impl.java:213)
 at de.deutschepost.ubbrief.coma.service.z2.ComaServiceProviderZ2Bean_1dhrj7_EOImpl.getTaskList(ComaServiceProviderZ2Bean_1dhrj7_EOImpl.java:154)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList.runServiceMethod(CMPGetTaskList.java:64)
 at de.deutschepost.ubbrief.coma.sbbx.sp.BasicMethodProvider.execute(BasicMethodProvider.java:145)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl.execute(CMPGetTaskList_9b9mv5_EOImpl.java:46)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl_WLSkel.invoke(UnknownSource)
 at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:159)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:263)
 at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:230)
 at de.deutschepost.ubbrief.coma.sbba.z2.CMPGetTaskList_9b9mv5_EOImpl_WLStub.execute(UnknownSource)
 at de.deutschepost.ubbrief.backbone.jazz.impl.core.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:115)
 at de.deutschepost.ubbrief.backbone.common.impl.core.rpc.server.ServerKernelImpl.handleTransportMessage(ServerKernelImpl.java:270)
 at de.deutschepost.ubbrief.backbone.common.impl.core.messaging.MessageTransport.handleMessage(MessageTransport.java:454)
 at de.deutschepost.ubbrief.backbone.common.impl.core.KernelFacade.handleMessage(KernelFacade.java:209)
 at de.deutschepost.ubbrief.backbone.jazz.impl.backbone.BackboneBean.messageArrived(BackboneBean.java:637)
 at de.deutschepost.ubbrief.backbone.jazz.impl.backbone.BackboneBean_ina9d7_ELOImpl.messageArrived(BackboneBean_ina9d7_ELOImpl.java:105)
 at de.deutschepost.ubbrief.backbone.jazz.impl.transport.receive.LocalQueueReceiveBean.deliverMessage(LocalQueueReceiveBean.java:43)
 at de.deutschepost.ubbrief.backbone.jazz.impl.transport.receive.AbstractMessageReceiveBean.onMessage(AbstractMessageReceiveBean.java:127)
 at weblogic.ejb20.internal.MDListener.execute(MDListener.java:377)
 at weblogic.ejb20.internal.MDListener.transactionalOnMessage(MDListener.java:311)
 at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:286)
 at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2351)
 at weblogic.jms.client.JMSSession.execute(JMSSession.java:2267)
 at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234)
 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)

Clustering Problem on WLS 5.1 sp 2/3

I've set up a multihomed machine running four instances of WLS 5.1 sp2 on
 solaris 7. When I initially added them to a cluster and tested them for
 serving JSPs everything seemed fine. I've since tried deploying an EJB
 (which works in a non clustered server) and I'm suddenly getting the
 following errors:
 stdout:
 ... <E> <MutlicastSocket> Multicast socket receive error:
 java.lang.runtimeException: I/O error opening JAR file from
 file:/export/home0/weblogic/cluster1/serverclasses
 stderr:
 java.util.zip.ZipException: error in opening zip file
 at java.util.zip.ZipFile.open(Native Method)
 at java.util.zip.ZipFile.open(Compiled Code)
 at java.util.zip.ZipFile.<init>(Compiled Code)
 at java.util.zip.ZipFile.<init>(Compiled Code)
 at
 weblogic.boot.ServerClassLoader.deploy(ServerClassLoader.java:141)
 at
 weblogic.cluster.AnnotatedServiceOffer.expandClassPath(AnnotatedServiceOffer
 .java:74)
 at weblogic.cluster.AnnotatedServiceOffer.readObject(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readPublicSerializable(Comp
 iled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readLeftover(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObjectBody(Compiled
 Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObject(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObjectWL(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readArrayList(Compiled
 Code)
 at weblogic.cluster.Announcement.readObject(Announcement.java:73)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readPublicSerializable(Comp
 iled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readLeftover(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObjectBody(Compiled
 Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObject(Compiled Code)
 at
 weblogic.common.internal.WLObjectInputStreamBase.readObjectWL(Compiled Code)
 at weblogic.cluster.TMSocket.execute(Compiled Code)
 at weblogic.kernel.ExecuteThread.run(Compiled Code)
 (My EJB is deployed it its expanded directory form, which worked in a single
 server, this error happens repeatedly, regardless of accessing the EJB. The
 weblogic log says that the EJB deployed successfully)
 I've also tried upgrading to sp3, now it cannot even serve jsps, I get the
 following error:
 Wed Jun 14 10:36:06 GMT+01:00 2000: <ServletContext-General> file: init
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: init
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 verbose initialized to: true
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 packagePrefix initialized to: jsp_servlet
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 compileCommand initialized to: /usr/java1.2/bin/javac
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 srcCompiler initialized to weblogic.jspc
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 superclass initialized to null
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 workingDir initialized to: /export/home0/weblogic/cluster1/classfiles
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp: param
 pageCheckSeconds initialized to: 1
 Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 initialization complete
 Wed Jun 14 10:36:24 GMT+01:00 2000:<E> <ServletContext-General> Servlet
 failed with Exception
 java.lang.NullPointerException
 at
 weblogic.servlet.internal.session.ReplicatedSession.setMaxInactiveInterval(R
 eplicatedSession.java:339)
 at
 weblogic.servlet.internal.session.SessionContext.getNewSessionInstance(Sessi
 onContext.java:322)
 at
 weblogic.servlet.internal.ServletRequestImpl.getNewSession(ServletRequestImp
 l.java:1104)
 at
 weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
 ava:1007)
 at
 weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
 ava:981)
 at
 weblogic.servlet.jsp.PageContextImpl.initialize(PageContextImpl.java:47)
 at
 weblogic.servlet.jsp.PageContextImpl.<init>(PageContextImpl.java:64)
 at
 weblogic.servlet.jsp.JspFactoryImpl.getPageContext(JspFactoryImpl.java:31)
 at jsp_servlet.simpleSession._jspService(simpleSession.java:64)
 at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
 at
 weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
 :123)
 at
 weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
 :141)
 at
 weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
 l.java:744)
 at
 weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
 l.java:692)
 at
 weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
 Manager.java:251)
 at
 weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:363)
 at
 weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:263)
 at weblogic.kernel.ExecuteThread.run(Compiled Code)
 Thanks in advance, tell me if you need more info
 Loz (ECsoft/MyNet)


I got that working. Never mind.
 Amit Bhutra <[email protected]> wrote in message
 news:[email protected]...
 > I am getting same error. How did you resolved it?
 > Weblogic creates a jar file in mycluster/tmp_deployment directory.
 >
 > Do i need to include this jar file in my weblogic.properties?
 >
 > Loz <[email protected]> wrote in message
 > news:[email protected]...
 > > OK, I got rid of the EJB problem by deploying as a jar, how about the
 sp3
 > > problem?
 > >
 > > Loz
 > >
 > > "Loz" <[email protected]> wrote in message
 > > news:[email protected]...
 > > > I've set up a multihomed machine running four instances of WLS 5.1 sp2
 > on
 > > > solaris 7. When I initially added them to a cluster and tested them
 for
 > > > serving JSPs everything seemed fine. I've since tried deploying an EJB
 > > > (which works in a non clustered server) and I'm suddenly getting the
 > > > following errors:
 > > >
 > > > stdout:
 > > > ... <E> <MutlicastSocket> Multicast socket receive error:
 > > > java.lang.runtimeException: I/O error opening JAR file from
 > > > file:/export/home0/weblogic/cluster1/serverclasses
 > > >
 > > > stderr:
 > > > java.util.zip.ZipException: error in opening zip file
 > > > at java.util.zip.ZipFile.open(Native Method)
 > > > at java.util.zip.ZipFile.open(Compiled Code)
 > > > at java.util.zip.ZipFile.<init>(Compiled Code)
 > > > at java.util.zip.ZipFile.<init>(Compiled Code)
 > > > at
 > > > weblogic.boot.ServerClassLoader.deploy(ServerClassLoader.java:141)
 > > > at
 > > >
 > >
 >
 weblogic.cluster.AnnotatedServiceOffer.expandClassPath(AnnotatedServiceOffer
 > > > .java:74)
 > > > at weblogic.cluster.AnnotatedServiceOffer.readObject(Compiled
 > > Code)
 > > > at
 > > >
 > >
 >
 weblogic.common.internal.WLObjectInputStreamBase.readPublicSerializable(Comp
 > > > iled Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readLeftover(Compiled
 > > Code)
 > > > at
 > > >
 weblogic.common.internal.WLObjectInputStreamBase.readObjectBody(Compiled
 > > > Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readObject(Compiled
 > Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readObjectWL(Compiled
 > > Code)
 > > > at
 > > >
 weblogic.common.internal.WLObjectInputStreamBase.readArrayList(Compiled
 > > > Code)
 > > > at
 > weblogic.cluster.Announcement.readObject(Announcement.java:73)
 > > > at
 > > >
 > >
 >
 weblogic.common.internal.WLObjectInputStreamBase.readPublicSerializable(Comp
 > > > iled Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readLeftover(Compiled
 > > Code)
 > > > at
 > > >
 weblogic.common.internal.WLObjectInputStreamBase.readObjectBody(Compiled
 > > > Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readObject(Compiled
 > Code)
 > > > at
 > > > weblogic.common.internal.WLObjectInputStreamBase.readObjectWL(Compiled
 > > Code)
 > > > at weblogic.cluster.TMSocket.execute(Compiled Code)
 > > > at weblogic.kernel.ExecuteThread.run(Compiled Code)
 > > >
 > > > (My EJB is deployed it its expanded directory form, which worked in a
 > > single
 > > > server, this error happens repeatedly, regardless of accessing the
 EJB.
 > > The
 > > > weblogic log says that the EJB deployed successfully)
 > > >
 > > > I've also tried upgrading to sp3, now it cannot even serve jsps, I get
 > the
 > > > following error:
 > > >
 > > > Wed Jun 14 10:36:06 GMT+01:00 2000: <ServletContext-General> file:
 > init
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > init
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > verbose initialized to: true
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > packagePrefix initialized to: jsp_servlet
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > compileCommand initialized to: /usr/java1.2/bin/javac
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > srcCompiler initialized to weblogic.jspc
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > superclass initialized to null
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > workingDir initialized to: /export/home0/weblogic/cluster1/classfiles
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > param
 > > > pageCheckSeconds initialized to: 1
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000: <ServletContext-General> *.jsp:
 > > > initialization complete
 > > > Wed Jun 14 10:36:24 GMT+01:00 2000:<E> <ServletContext-General>
 Servlet
 > > > failed with Exception
 > > > java.lang.NullPointerException
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.session.ReplicatedSession.setMaxInactiveInterval(R
 > > > eplicatedSession.java:339)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.session.SessionContext.getNewSessionInstance(Sessi
 > > > onContext.java:322)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletRequestImpl.getNewSession(ServletRequestImp
 > > > l.java:1104)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
 > > > ava:1007)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.j
 > > > ava:981)
 > > > at
 > > >
 weblogic.servlet.jsp.PageContextImpl.initialize(PageContextImpl.java:47)
 > > > at
 > > > weblogic.servlet.jsp.PageContextImpl.<init>(PageContextImpl.java:64)
 > > > at
 > > >
 > weblogic.servlet.jsp.JspFactoryImpl.getPageContext(JspFactoryImpl.java:31)
 > > > at
 jsp_servlet.simpleSession._jspService(simpleSession.java:64)
 > > > at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
 > > > :123)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
 > > > :141)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
 > > > l.java:744)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImp
 > > > l.java:692)
 > > > at
 > > >
 > >
 >
 weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContext
 > > > Manager.java:251)
 > > > at
 > > >
 > >
 >
 weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:363)
 > > > at
 > > > weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:263)
 > > > at weblogic.kernel.ExecuteThread.run(Compiled Code)
 > > >
 > > > Thanks in advance, tell me if you need more info
 > > >
 > > > Loz (ECsoft/MyNet)
 > > >
 > > >
 > >
 > >
 >
 >

Problem starting WLS 5.1 in RH Linux

I have RH Linux 6.2 and just downloaded Sun JDK1.3 and BEA WLS 5.1. There
were a couple of problems with the install:
1) The case statemement in startWebLogic.sh did not pick up Linux using
uname -s, but I fixed that by commenting out all the other Unixes and the
case and esac. And LD_LIBRARY_PATH was defined as
/home/wlogic/weblogic/lib/linux
2) The second problem I have not been able to resolve. This is the
stackdump:
LD_LIBRARY_PATH=/home/wlogic/weblogic/lib/linux
Exception in thread "main" java.security.AccessControlException: access
denied (
java.lang.RuntimePermission createSecurityManager)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.lang.SecurityManager.<init>(SecurityManager.java:301)
at
weblogic.boot.ServerSecurityManager.<init>(ServerSecurityManager.java:11)
at weblogic.Server.main(Server.java:59)
at weblogic.Server.main(Server.java:55)
Comments pls someone. Many thanks.
Kenny

Try modifying your weblogic.polic file so that the paths in that file
match your environment.
John
Kenny Kon wrote:
>
I have RH Linux 6.2 and just downloaded Sun JDK1.3 and BEA WLS 5.1. There
were a couple of problems with the install:
1) The case statemement in startWebLogic.sh did not pick up Linux using
uname -s, but I fixed that by commenting out all the other Unixes and the
case and esac. And LD_LIBRARY_PATH was defined as
/home/wlogic/weblogic/lib/linux
2) The second problem I have not been able to resolve. This is the
stackdump:
LD_LIBRARY_PATH=/home/wlogic/weblogic/lib/linux
Exception in thread "main" java.security.AccessControlException: access
denied (
java.lang.RuntimePermission createSecurityManager)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.lang.SecurityManager.<init>(SecurityManager.java:301)
at
weblogic.boot.ServerSecurityManager.<init>(ServerSecurityManager.java:11)
at weblogic.Server.main(Server.java:59)
at weblogic.Server.main(Server.java:55)
Comments pls someone. Many thanks.
Kenny--
Jesus M. Salvo, Jr.
Senior Consultant
PowerServe Pty Ltd
Level 2, 116 Miller Street
North Sydney 2060
New South Wales, Australia
Ph: (61-2) 9492 4800
Direct (61-2) 9492 4853
Fax: (61-2) 9492 4899
http://www.powerserve.com.au
Email: [email protected]
This email is from PowerServe Pty Limited (ACN 069 037 056)
The information contained in this email (including any attached files)
may be privileged and confidential intended for the use of the
person/persons named above. If you are not the intended recipient, you
are advised that any use, distribution or copying of the information is
strictly prohibited. If you have received this transmission in error,
please notify PowerServe Pty Limited immediately on (61 3) 9618 1222 or
reply by email to the sender.
PowerServe Pty Limited does not represent or warrant that this email or
any attached files are free from computer viruses or other defects. Any
attached files are provided, and may only be used, on the basis that the
user assumes all responsibility for

Database Connection problem in WLS 7.0 Service Pack 7

Hi Guys,
I am a newbie in this forum. Currently, I tested running application using WLS 7.0 Service Pack 7 in Development environment. And for database I used Oracle 9i Release 2 v9.2.0.6 which is running on AIX OS. After WLS started, I had some error in connecting to database. This is the error that I found from log file :
java.sql.SQLException: Bigger type length than Maximum
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:124)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:161)
at oracle.jdbc.driver.DatabaseError.check_error(DatabaseError.java:884)
at oracle.jdbc.driver.T4CMAREngine.buffer2Value(T4CMAREngine.java:2230)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB2(T4CMAREngine.java:1047)
at oracle.jdbc.driver.T4CTTIdcb.receiveCommon(T4CTTIdcb.java:111)
at oracle.jdbc.driver.T4CTTIdcb.receiveFromRefCursor(T4CTTIdcb.java:103)
at oracle.jdbc.driver.T4CResultSetAccessor.unmarshalOneRow(T4CResultSetAccessor.java:165)
at oracle.jdbc.driver.T4CTTIrxd.unmarshal(T4CTTIrxd.java:787)
at oracle.jdbc.driver.T4CTTIrxd.unmarshal(T4CTTIrxd.java:704)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:526)
at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:179)
at oracle.jdbc.driver.T4CCallableStatement.execute_for_rows(T4CCallableStatement.java:782)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1027)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2887)
at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:2978)
at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4102)
at weblogic.jdbc.pool.Statement.execute(Statement.java:298)
at EJB.Engine.EAIManagerBean.mtdRequest(EAIManagerBean.java:204)
at EJB.Engine.EAIManagerBean_lt8oqo_EOImpl.mtdRequest(EAIManagerBean_lt8oqo_EOImpl.java:46)
So, I need someone to solve my problem. Thanks...

First thing, most of BEA's forums are terrible as people rarely reply. I noticed your post through google searching for the same fix. You have likely done the same things as me and have learned that your Oracle JDBC Client driver has some bugs interacting with certain version of Oracle Server. For us, this problem occured when we migrated from Solaris to AIX. We were able to fix this by downloading the latest version of ojdbc14.zip from oracle's site. You can either replace the current ojdbc14 file in the bea installation or make sure it is visible in the classpath for WLS before the old version.
Here is a good link which describes the problem, good luck.
http://www.dbtalk.net/comp-databases-oracle-server/java-sql-sqlexception-bigger-type-289015.html

Problems starting WLS 6.1 on solaris...

I have installed WLS in the sun solaris machine and have problems starting up a mydomain
test server. I am getting:
weblogic.management.configuration.ConfigurationException: - with nested exception:
[weblogic.security.internal.FileUtilsException: couldn't create temporary file for
SerializedSystemIni.dat, .new, /config/mydomain - with nested exception:
[java.io.IOException: No such file or directory]]
I am suspecting the problem might be that we have installed it as root and then change
the rights to weblogic. Any pointers are greatly appreciated.
Thanks.

I'm guess you changed owner of config/mydomain to weblogic? To
confirm - try touching/create a test file in config/mydomain,
i.e. touch mytest.perm;ls -l mytest.perm;rm mytest.perm
You could start weblogic with truss:
truss -t open -o /tmp/truss.out -f "your start command"
Then examine /tmp/truss.out
"Dariusz" <[email protected]> wrote in message news:<3d08b130$[email protected]>...
I have installed WLS in the sun solaris machine and have problems starting up a mydomain
test server. I am getting:
weblogic.management.configuration.ConfigurationException: - with nested exception:
[weblogic.security.internal.FileUtilsException: couldn't create temporary file for
SerializedSystemIni.dat, .new, /config/mydomain - with nested exception:
[java.io.IOException: No such file or directory]]
I am suspecting the problem might be that we have installed it as root and then change
the rights to weblogic. Any pointers are greatly appreciated.
Thanks.

Problems starting WLS on XP - Unable to bind to port

Hi
I recently changed my development environment from W2000 to XP.
Apparently everything works as before.
However, when I start WLS again shortly after stopping it (either by console or
CTRL^C) I get the following error
<01-10-2003 14:48:40 CEST> <Emergency> <WebLogicServer> <BEA-000351> <Unable to
create a server socket on Channel Default for port: 28041. j
ava.net.BindException: Address in use Perhaps another process is using port 28041.>
<01-10-2003 14:48:40 CEST> <Emergency> <Security> <BEA-090085> <Server failed
to bind to the configured port. The port may already be used b
y another process.>
<01-10-2003 14:48:40 CEST> <Emergency> <WebLogicServer> <BEA-000342> <Unable to
initialize the server: Server failed to bind to the requeste
d port. See preceeding log message for details.>
This situation times out after an unpredictable delay (5-20 min) - and I can restart
my WLS.
Does anybody know how to resolve this problem.
Regards
Peter

Hi Werner,
SYSLOG is UDP port 514. Normally this means that some other program is running and using port 514.
Some of the TFTP servers are also SYSLOG servers and will "listen" on this port.
You can see if port 514 is listening with Fabric Manager not running.
To find out what is using port 514:
(a) Open a command prompt window. From Start / Run enter: cmd
(b) From the command prompt enter: netstat -ano
(c) Note the PID (process identifier) associated with the ports you are concerned about. (Also note the Local Address, Foreign Address, Protocol and State.)
(d) Then do ctrl-alt-del to bring up the Windows Task Manager.
(e) In Windows Task Manager, select the Processes tab.
(f) Look for the PID you noted when you did the netstat in step (c). Look to left to the image name and that tells you which process has that PID.
- If you dont see a PID column, click on View / Select Columns. Make sure PID is selected. Click OK.
- Make sure Show processes from all users is selected.
Now you can see what process is using port 514. FM would be listed as javaw.exe ( java exec without a console window ).
Best regards,
Jim

Problem starting WLS server in Oracle VM Viirtualbox

Hi,
I am new to Oracle SOASuite.I am trying my hands on with Oracle VM Viirtualbox to which I have imported theoracle soa suite/bpm appliances and I am successful with it.The problem arises when I try to start the WLS server.It failed to start and gave the following exception in logs:
<Failed to initialize the application 'soademoDatabase' due to error weblogic.application.ModuleException: .
weblogic.application.ModuleException:
 at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:327)
 at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
 at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:518)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
 Truncated. see log file for complete stacktrace
Caused By: weblogic.common.ResourceException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
 at weblogic.jdbc.common.internal.XAConnectionEnvFactory.makeConnection(XAConnectionEnvFactory.java:500)
 at weblogic.jdbc.common.internal.XAConnectionEnvFactory.createResource(XAConnectionEnvFactory.java:177)
 at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1310)
 at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1227)
 at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.java:250)
 Truncated. see log file for complete stacktrace
>
<Jul 2, 2012 4:49:20 AM PDT> <Error> <Deployer> <BEA-149205> <Failed to initialize the application 'wlsbjmsrpDataSource' due to error weblogic.application.ModuleException: .
weblogic.application.ModuleException:
 at weblogic.jdbc.module.JDBCModule.prepare(JDBCModule.java:327)
 at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:199)
 at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:518)
 at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
 at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:159)
 Truncated. see log file for complete stacktrace
Caused By: weblogic.common.ResourceException: weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
 at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:283)
 at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1310)
 at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1227)
 at weblogic.common.resourcepool.ResourcePoolImpl.start(ResourcePoolImpl.java:250)
 at weblogic.jdbc.common.internal.ConnectionPool.doStart(ConnectionPool.java:1330)
 Truncated. see log file for complete stacktrace
Please help me debug the issue.
Edited by: DivyaHabin on Jul 2, 2012 10:04 PM

Thanks for the reply Eric.
Initially I didn't start db server before starting Admin server.But now as per your reply, I started db and then started the server.It got started.So does that mean I should start the Oracle Database first and then start server?
The exception are still there in log.
Exception1:<Failed to initialize the application 'soademoDatabase' due to error weblogic.application.ModuleException: .
Exception2: <Failed to initialize the application 'wlsbjmsrpDataSource' due to error weblogic.application.ModuleException: .
Edited by: DivyaHabin on Jul 3, 2012 1:18 AM

Problems in WLS 7.0

Similar Messages

Maybe you are looking for