WAS 6.1 ND Security CORBA.NO_PERMISSION vmcid: 0x49424000 minor code: 309

Hi All,

we are running 3 physical WAS6.1 ND with 3 servers on every machine.

By time (environment was running without problems before) we always get on the same server the following Exception:

        >>    org.omg.CORBA.NO_PERMISSION: handleStatefulContext > MessageInContext  vmcid: 0x49424000  minor code: 309  completed: No
        >>         at com.ibm.ISecurityLocalObjectBaseL13Impl.CSIServerRIBase.handleStatefulContext(CSIServerRIBase.java:1764)
        >>         at com.ibm.ISecurityLocalObjectBaseL13Impl.CSIServerRI.receive_request(CSIServerRI.java:489)
        >>         at com.ibm.rmi.pi.InterceptorManager.invokeInterceptor(InterceptorManager.java:631)
        >>         at com.ibm.rmi.pi.InterceptorManager.iterateServerInterceptors(InterceptorManager.java:535)
        >>         at com.ibm.rmi.pi.InterceptorManager.iterateReceiveRequest(InterceptorManager.java:777)
        >>         at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:616)
        >>         at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:480)
        >>         at com.ibm.rmi.iiop.ORB.process(ORB.java:512)
        >>         at com.ibm.CORBA.iiop.ORB.process(ORB.java:1571)
        >>         at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2717)
        >>         at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2582)
        >>         at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
        >>         at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
        >>         at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

The minor code says that the on the server already exists with the context-id but the information by the client provided is different from the original information provided.

Now my question:

Does anybody have a hint what the reason could be that this error pops up?

with kind regards
Who is Participating?
If you see Credential token expired then following apar will match. This kind of problem occured during load test or heavy load  and intermitent problem. I fixed the problem by applying the apar PK96506. WebSphere Application Server fails to retry requests causing Credential token expired error.


additional continuation apar if the above doesn't fix

HonorGodSoftware EngineerCommented:
Does this describe your situation accurately?

HonorGodSoftware EngineerCommented:
If this is the case, the fix is described here:


and is available in

The latest fix level for 6.1 is


If you need help with understanding how to get, and install the fix, let me know.
Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

uniquareAuthor Commented:
Hi HonorGod,

thanks for your reply.

The situation described is not the situation at all, as i have understood the situation you posted occurs immediatley after a nodeagent had been restarted, and the application servers had been running all the time.

In my case, the error occurs after some time (in the current case 12 hours after the restart of all nodeagents and application servers).
As i have described above the minor code (309 instead of 300) says the server already had been registered after the restart, and are reregistering with another information.

Our current Fixpack installed on the Servers is so the Fix had been provided.

with kind regards
HonorGodSoftware EngineerCommented:
uniquare - Thanks for the clarification!  Let me look around, and see what I can find.
uniquareAuthor Commented:
Hi AdminRAM,

thanks for your answers, all your answers and links are looking very good, but i am a always a little bit confused about the different minor codes.

Our Credential token isn't expired, as far as i know. Can you provide me an Information how i can check fast if the token is expired? Is this possible to do in a running productive system without influence on the performance?

As in your link above i already thought my next step should be to disable stateful CSIv2 sessions to suppress this error, but this would only suppress it and i would have no clue if this error is resulting from our application or it is an error which occurs through a wrong configuration of the WAS 6.1.

The next step we will try now is to install the current fix-pack and will look if the error occurs one more time :)

how i can check fast if the token is expired?

Generally in exception stack you will see this message

Caused by: org.omg.CORBA.NO_PERMISSION: JSAS0202E: [{0}]
Credential token expired.

com.ibm.ISecurityLocalObjectCSIv2UtilityImpl.SessionManager.retry(SessionManager.java(Compiled Code))

Is this possible to do in a running productive system without influence on the performance?

I heared if fix also fixed other minor code but for only  Credential token expired However t you might need to check with IBM.

PM13384 is not yet released. it is tearget on v6.1.0.35 you might need to check with ibm for ifix...:-)
Kevin CrossChief Technology OfficerCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.