<< Back to previous view
launch link in web app ignore virtual server (GLASSFISH-2918)

[GLASSFISH-19495] Parent issue is not resolved in GF-3.1.2.2 Created: 06/Jan/13  Updated: 06/Jan/13

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2.2
Fix Version/s: 9.1pe

Type: Sub-task Priority: Major
Reporter: mahairod Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF developer profile


Tags: admin-gui regression virtual_server
Participants: Anissa Lam and mahairod

 Description   

Parent issue is not resolved in GF-3.1.2.2. While using multiple virtual servers and deploying just tto particular ones it's not availbale to launch application normally through admin gui






[GLASSFISH-2018] amx:j2eeType=X-WebModuleVirtualServerMonitor Created: 11/Jan/07  Updated: 20/Feb/11

Status: Reopened
Project: glassfish
Component/s: amx
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Minor
Reporter: llc Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,018
Tags:
Participants: gfbugbridge, km, llc, naman_mehta, prasads and sirajg

 Description   

AMX unit tests detect inconcistencey problems:

.getAllMonitoringStats, 25 MBeans: 58ms
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:
{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCoun t,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}
via introspection:
{ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCount,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}}
via introspection:

{ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}

Ran test method checkStatsClassSuppliesAllStatistics on 25 candidates in 306ms



 Comments   
Comment by gfbugbridge [ 17/Jan/07 05:29 PM ]

<BT>

Comment by gfbugbridge [ 17/Jan/07 05:34 PM ]

<BT6514375>

Comment by km [ 01/Feb/07 10:45 PM ]

Monitoring.

Comment by sirajg [ 15/Feb/07 03:17 PM ]

Some stats appear to be missing - need to add the missing stats

Comment by sirajg [ 23/Feb/07 02:09 PM ]

The difference in the 2 lists described in the bug report are the follo statistics :
CachedSessionsCurrent
ContainerLatency
PassivatedSessionsCurrent
SessionSize

These are all exposed to the user through the admin infrastructure in EE. There
may have been something wrong with the test that generated these results.

Comment by llc [ 27/Feb/07 03:53 PM ]

The error message is correct: the names do not match what is actually in the Stats object.

Comment by sirajg [ 12/Apr/07 02:24 PM ]

All the relevant monitoring statistics are exposed in admin interfaces.

Comment by llc [ 13/Apr/07 09:29 AM ]

The unit test is still failing. Looks like all the problems have been rectified except one: the Statistic
"PassivatedSessionsCurrent" is supplied from getStatistics(), but is not supplied in getStatisticNames():

checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/web1,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError,
msg = Statistic names for "amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/
web1,X-ApplicationMonitor=null,X-ServerRootMonitor=server" obtained via Statistic names do not
match those obtained via introspection:

via names:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

via introspection:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
PassivatedSessionsCurrent, **** NOT OK ***
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

1) testStatsClassSuppliesAllStatistics(com.sun.enterprise.management.monitor.MonitorTest)
java.lang.AssertionError
at com.sun.enterprise.management.AMXTestBase.testAll(AMXTestBase.java:562)
at com.sun.enterprise.management.monitor.MonitorTest.testStatsClassSuppliesAllStatistics
(MonitorTest.java:513)

Comment by sirajg [ 23/May/07 02:13 PM ]
      • Issue 3036 has been marked as a duplicate of this issue. ***
Comment by llc [ 25/May/07 03:15 PM ]

Statistic names come from other module classes. Not sure which exact piece of code to look at, but I think
it should be somewhere in
appser-core-ee\com.sun.enterprise.ee.web.stats.EEWebModuleStatsImpl or
appserv-core\com.sun.enterprise.web.stats.WebModuleStatsImpl

Comment by prasads [ 20/Feb/11 08:03 AM ]

Assigning issues to Naman





[GLASSFISH-3121] race condition in NssStore.java Created: 04/Jun/07  Updated: 13/Jun/07

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Minor
Reporter: kumarjayanti Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,121
Tags:
Participants: dpatil, gfbugbridge, kumarjayanti and rameshm

 Description   

> Could you please forward this bug reported from Sanjeev Krishnan's
> code analysis tool.
>
> thanks, Larry White

>
> NssStore
> Race Condition
> read/write to _password not adequately synchronized
>
> 093 public static String getNssDbPassword()
> 094 {
> 095 if (_password == null) { > 096 _password = System.getProperty(SystemPropertyConstants.NSS_DB_PASSWORD_PROPERTY); > Race Condition : Write / read to static field NssStore._password is NOT adequately synchronized. > 097 }
> 098 return _password;
> 099 }



 Comments   
Comment by kumarjayanti [ 04/Jun/07 05:03 AM ]

The fix for the reported race condition is ready. However there needs to be an
investigation on why a SYSTEM property is being used at all :

System.getProperty(SystemPropertyConstants.NSS_DB_PASSWORD_PROPERTY);

Comment by gfbugbridge [ 04/Jun/07 05:01 PM ]

<BT6565526>

Comment by kumarjayanti [ 06/Jun/07 03:27 AM ]

Fixed the race condition.
May file another issue after discussion with RON on whether or not the System
Property should have been used.

Comment by dpatil [ 06/Jun/07 12:14 PM ]

Broke enterprise profile after this change, so reverted the checkin.

Comment by rameshm [ 13/Jun/07 03:02 PM ]

As per agreement in bugscum meeting, changing the priority to P4. Bugswat team felt
that, this is not a must fix for AS 9.1 and may be risky to attempt to fix at
this time in AS 9.1.





[GLASSFISH-3186] support beforeCompletion and afterCompletion callbacks running in different threads Created: 14/Jun/07  Updated: 25/Nov/10

Status: Reopened
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Minor
Reporter: elmooney Assignee: tware
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-3867 Call to commit() does not return, whe... Open
Issuezilla Id: 3,186
Status Whiteboard:

HIGH

Tags:
Participants: elmooney, gyorke, Joe Fialli, marina vatkina and tware

 Description   

The WS-Atomic Transactions two-phase commit handshake executes the
beforeCompletion callback as part of its prepare phase and the afterCompletion
callback as part of its commit phase. While it's common for those callbacks to
run in different threads (when accessing an EJB web service from a Windows
Communication Foundation web client, e.g.), TopLink Essentials doesn't support
that functionality. This causes our WS-AT functional tests to fail. Analysis by
jfialli:

The scenario is a WS-AT enabled MS web service client is
accessing a transacted (WS-AT enabled) EJB web service that is
accessing an EJB 3.0 Entity bean. The Enitity bean is accessed
via three potentially different threads for one JTA transaction
(or by happenstance, all 3 phases could run on same thread). The
way we have constructed our test, Task 1 definitely must be a
different thread than task 2 and 3. (Task 1 is on http-listener
and Task 2 and 3 MUST be executed on https-listener thread)

Task 1: The thread used to execute the transacted EJB web
service method. (These methods read and either create or
deletes a row from Derby database.) The flowed WS-AT
transaction is mapped to a JTA transaction using the
Java Connector API 1.5 (JCA) recreate/release methods.

Task 2: The Microsoft WS-Atomic Transaction Coordinator sends a
WS-AT protocol message called "prepare" to Sun WS-AT
coordinator. This thread eventually calls JCA 1.5
XATerminator.prepare(Xid xid). The Toplink callback for
beforeCompletion gets called on this thread. The Sun
WS-AT implementation maps the WS-AT transaction to
correct JTA xid.

Task 3: MS WS-AT Coordinator sends WS-AT protocol message
"commit" to Sun WS-AT Coordinator. Thread eventually
calls JCA 1.5 XATerminator.commit(Xid xid). The Toplink
callback for afterCompletion gets called on this thread.

The failure we are seeing is a failure to release an outstanding
lock. I fear this is because the lock was aqquired by one
thread during Task 2 and Task 3 happens to be running on a
different thread, thus is unable to release the lock acquired by
Task 2. Below is the stack trace that I am observing. (typed
from Netbeans) I doubt that the Toplink code was written with
requirement that the "beforeCompletion" callback could be called
on a different thread than the "afterCompletion" callback. I
was seeking confirmation on this from someone more familar with
code than myself.

Here is stack trace where we are hanging:

ATSubCoordinator$DurableParticipant.commit: 268 // Tango WS-AT
Subordinate Coordinator.
// Method is invoked
based on Microsoft
// WS-Atomic Txn coordinator
// deciding that all
participants in WS-Atomic
// Transaction have been
"prepared".
XATerminatorImpl.commit:156 // AS 9.1 code
TopCoordinator:commit:2173 // Begin AS 9.1 JTS code
TopCoordinator:afterCompletion:2581
RegisteredSyncs.distributeAfter:208
SynchronizedImpl.after_completion:154
AbstractSynchronizationListener.afterCompletion:170
UnitOfWorkImpl:afterTransaction:1836 // Begin Toplink
Essentials code
WriteLocalManager:releaseAllAcquiredLocks:399
HardCacheWeakIdentityMap:remote:117
FullidentityMap.remove:199
CacheKey.acquire:117
ConcurrentyManager:acquire:111
Object.wait:474

We have successfully run the same code when the Tango initator client
is on same Glassfish instance as EJB web service accessing the EJB 3.0
entity. This proves the code is written correctly for Toplink when the
client and service are running on same Glassfish VM. (That code path
does not use JCA 1.5 at all. Using that code path the application
method, beforeCompletion and afterCompletion always run in same
thread.)

Our tests succeed with Hibernate.



 Comments   
Comment by elmooney [ 14/Jun/07 06:40 AM ]

adding mvatkina, jfialli

Comment by gyorke [ 14/Jun/07 07:43 AM ]

It is unusual to have different threads used in the seperate JTA callbacks but
TopLink specific configuration is available to support this usecase. Setting
the TopLink cache isolation level through a customizer will aleviate this issue.

[u]Persistence.xml entry:[/u]
[code]<property name="toplink.session.customizer"
value="mypackage.ConverterCustomizer"/>[/code]

[u]Customizer Class :[/u]
[code]
package mypackage;
import oracle.toplink.essentials.sessions.Session;
import oracle.toplink.essentials.sessions.DatasourceLogin;

/**

  • PUBLIC:
  • This interface is to allow extra customization on a TopLink Session
    */
    public class ConverterCustomizer extends SessionCustomizer {
    public void customize(Session session) throws Exception { session.getLogin().setCacheTransactionIsolation(DatasourceLogin.SYNCRONIZED_OBJECT_LEVEL_READ_WRITE); }
    }
    [/code]
Comment by elmooney [ 14/Jun/07 01:14 PM ]

That works great. Thank you! For the record, your class needs to implement
SessionCustomizer, which is in the
oracle.toplink.essentials.tools.sessionconfiguration package. Thanks again!

Comment by gyorke [ 14/Jun/07 01:23 PM ]

The suggested customization is a workaround. TopLink should be able to release
all acquired connections with a different thread in the afterCompletion callback.

Comment by marina vatkina [ 15/Jun/07 10:30 AM ]

Do you want to keep it as an enhancement?

Comment by gyorke [ 15/Jun/07 10:40 AM ]

It really is one of those issues that sits in the middle but lets call it a bug.

Comment by Joe Fialli [ 15/Jun/07 12:04 PM ]

Clarification from original Description of use case involved.

Task 1 is an application level web service request with a WS-Atomic Transaction
flowed across with it. This WS-Atomic Transaction is mapped to a JTA transaction
within Glassfish v9.1 environment.

Task 2 and 3 from initial description are middleware protocol messages
implementing two phase commit for WS-Atomic Transaction implementation.

Tango WS-Atomic Transaction implements the following specification.
(see http://specs.xmlsoap.org/ws/2004/10/wsat/wsat.pdf)
The 2 phase commit protocol described in the above document is
performed by SOAP over https. Thus, the ws-at prepare web service request will
typically be on a different thread than ws-at commit web service request.

The Tango implementation of WS-AT protocol uses Java Connector API 1.5 Transaction
inflow contract. Thus, the ws-at prepare is calling XATerminator.prepare(xid)
And the ws-at commit web service request is ultimately mapped to
XATerminator(xid). The JTA 1.1 beforeCompletion callback are started in
XATerminatorImpl.prepare in glassfish implementation of JTA 1.1/JCA 1.5.

See pages 29 and 30 in following presentation for a high level diagram
of the web service invocations between applications and WS-Atomic Txn
Coordinators on Microsoft and Glassfish platform.
http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-1603.pdf





Generated at Fri Apr 25 04:20:18 UTC 2014 using JIRA 4.0.2#472.