[GLASSFISH-21710] Web container availability service save is creating one more availability-service element instead of updating the existing element. Created: 27/Mar/17  Updated: 27/Mar/17

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sumasri Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In GUI,
1)Install the server
2)check for availability-service element existence in domain.xml under default-config.
3)click on default-config->availability-service->web container availability page and change something and then save button.
4)again, check for the availability service element existence in domain.xml under default-config. You would see one more <availbility-service> empty element along with the existing one, which is not correct.

It should typically update the existing element, instead of creating a new one.



 Comments   
Comment by sumasri [ 27/Mar/17 ]

same problem with EJB container availability page too.





[GLASSFISH-21709] New Network config protocol throws run time exception in GUI. Created: 27/Mar/17  Updated: 27/Mar/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sumasri Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In GUI, click on default-config->network config->protocols->New Button. It is throwing run time exception .
In server log, exception seen is

[2017-03-27T16:41:45.855+0530] [glassfish 5.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=55 _ThreadName=admin-listener(5)] [timeMillis: 1490613105855] [levelValue: 1000] [[
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event262'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:425)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:557)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:261)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:133)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:201)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:670)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1580)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:338)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:250)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:652)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:596)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 46 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.handlers.UtilHandlers.mapPut(UtilHandlers.java:314)
... 51 more






[GLASSFISH-21708] Implement SERVLET_SPEC-171 Created: 24/Mar/17  Updated: 24/Mar/17  Resolved: 24/Mar/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 4 Sprint 2

 Description   

Implementation issue for SERVLET_SPEC-171.



 Comments   
Comment by Shing Wai Chan [ 24/Mar/17 ]

Sending appserver/web/web-core/src/main/java/org/apache/catalina/core/ApplicationPushBuilder.java
Sending appserver/web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Transmitting file data ..
Committed revision 64876.





[GLASSFISH-21707] Dead lock occurs when both HttpSession#invalidate() and HttpServletRequest#getAttribute(String) are called at the same time. Created: 23/Mar/17  Updated: 23/Mar/17

Status: Open
Project: glassfish
Component/s: cdi, web_container
Affects Version/s: 3.1.2.2, 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: ankur.kathuria
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Dead lock occurs when both HttpSession#invalidate() and HttpServletRequest#getAttribute(String) are called at the same time.

This is a reproducible application.

TestServlet.java
package test.session.deadlock;

import java.io.IOException;

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

@WebServlet(urlPatterns={"/test"})
public class TestServlet extends HttpServlet {
    static int counter = 0;
    
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException {
        HttpSession session = req.getSession();

        boolean invalidate = Boolean.valueOf((String) req.getParameter("invalidate"));
        if(invalidate) {
            session.invalidate();
        }
        
        Integer id = null;
        synchronized(TestListener.lock) {
            id = (Integer)session.getAttribute("id");
        }
        
        if(id == null) {
            id = ++counter;
            session.setAttribute("id", counter);
            session.setMaxInactiveInterval(60);
        }
        
        res.getWriter().println("id="+id);
    }
}
TestListener.java
package test.session.deadlock;

import javax.servlet.annotation.WebListener;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

@WebListener
public class TestListener implements HttpSessionListener {
    static final Object lock = new Object(); 
    
    @Override
    public void sessionCreated(HttpSessionEvent event) {
    }

    @Override
    public void sessionDestroyed(HttpSessionEvent event) {
        synchronized(lock) {
            System.out.println("sessionDestroyed called");
        }
    }

}

Servlet calls HttpSession#getAttribute() in synchronized block.
In getAttribute method, session object is locked in order to check foreground session lock.

StandardSession.java
    public boolean isForegroundLocked() {
        //in this case we are not using locks
        //so just return false
        if(_sessionLock == null)
            return false;        
        synchronized(this) {
            return _sessionLock.isForegroundLocked();
        } 
    }  

Moreover, HttpSessionListener#sessionDestroyed() uses synchronized block.
HttpSessionListener#sessionDestroyed() is called after locking session object.

StandardSession.java
    public void expire(boolean notify, boolean persistentRemove) {

        // Mark this session as "being expired" if needed
        if (expiring)
            return;

        synchronized (this) {

            if (manager == null)
                return;

            expiring = true;
        
            // Notify interested application event listeners
            // FIXME - Assumes we call listeners in reverse order

            // The call to expire() may not have been triggered by the webapp.
            // Make sure the webapp's class loader is set when calling the
            // listeners
            ClassLoader oldTccl = null;
            if (context.getLoader() != null &&
                    context.getLoader().getClassLoader() != null) {
                oldTccl = Thread.currentThread().getContextClassLoader();
                if (Globals.IS_SECURITY_ENABLED) {
                    PrivilegedAction<Void> pa = new PrivilegedSetTccl(
                            context.getLoader().getClassLoader());
                    AccessController.doPrivileged(pa);
                } else {
                    Thread.currentThread().setContextClassLoader(
                            context.getLoader().getClassLoader());
                }
            }
            try {
                List<HttpSessionListener> listeners = context.getSessionListeners();
                if (notify && !listeners.isEmpty()) {
                    HttpSessionEvent event = new HttpSessionEvent(getSession());
                    int len = listeners.size();
                    for (int i = 0; i < len; i++) {
                        // Invoke in reverse order of declaration
                        HttpSessionListener listener = listeners.get((len - 1) - i);
                        try {
                            fireContainerEvent(context,
                                               "beforeSessionDestroyed",
                                               listener);
                            listener.sessionDestroyed(event);
                            fireContainerEvent(context,
                                               "afterSessionDestroyed",
                                               listener);
                        } catch (Throwable t) {
                            try {
                                fireContainerEvent(context,
                                                   "afterSessionDestroyed",
                                                   listener);
                            } catch (Exception e) {
                                // Ignore
                            }
                            // FIXME - should we do anything besides log these?
                            log(rb.getString(SESSION_EVENT_LISTENER_EXCEPTION), t);
                        }
                    }
                }
            } finally {
                if (oldTccl != null) {
                    if (Globals.IS_SECURITY_ENABLED) {
                        PrivilegedAction<Void> pa =
                            new PrivilegedSetTccl(oldTccl);
                        AccessController.doPrivileged(pa);
                    } else {
                        Thread.currentThread().setContextClassLoader(oldTccl);
                    }
                }
            }

This is the thread dump for dead lock.

Found one Java-level deadlock:
=============================
"ContainerBackgroundProcessor[StandardEngine[glassfish-web].StandardHost[server].StandardContext[/sessiondeadlock]]":
  waiting to lock monitor 0x000000005add7ee8 (object 0x00000000f6484960, a org.apache.catalina.session.StandardSession),
  which is held by "http-listener-1(8)"
"http-listener-1(8)":
  waiting to lock monitor 0x00000000527deb48 (object 0x00000000f60af8c8, a java.lang.Object),
  which is held by "http-listener-1(2)"
"http-listener-1(2)":
  waiting to lock monitor 0x000000005add7ee8 (object 0x00000000f6484960, a org.apache.catalina.session.StandardSession),
  which is held by "http-listener-1(8)"

Java stack information for the threads listed above:
===================================================
"http-listener-1(8)":
	at test.session.deadlock.TestListener.sessionDestroyed(TestListener.java:18)
	- waiting to lock <0x00000000f60af8c8> (a java.lang.Object)
	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
	- locked <0x00000000f6484960> (a org.apache.catalina.session.StandardSession)
	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
	at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
	at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
	at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
	at test.session.deadlock.TestServlet.doGet(TestServlet.java:20)
"http-listener-1(2)":
	at org.apache.catalina.session.StandardSession.isForegroundLocked(StandardSession.java:1480)
	- waiting to lock <0x00000000f6484960> (a org.apache.catalina.session.StandardSession)
	at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:756)
	at org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:1354)
	at org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:152)
	at test.session.deadlock.TestServlet.doGet(TestServlet.java:25)
	- locked <0x00000000f60af8c8> (a java.lang.Object)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)

Because the order of acquiring lock object is different between two threads,
dead lock occurs.

Moreover, the latest weld implementation (2.4.2 or 3.0.0) has the same structure.
So the same dead lock will occur if GF5.0 is released with the latest weld implementation.

When I replace weld of GF4.1.1(2.2.13) by newer version,
following dead lock occurs.

Daemon Thread [http-listener-1(40)] (Suspended)	
	owns: Collections$SynchronizedMap<K,V>  (id=180)	
		waited by: Daemon Thread [http-listener-1(7)] (Suspended)	
	waiting for: StandardSession  (id=179)	
		owned by: Daemon Thread [http-listener-1(7)] (Suspended)	
	StandardSession.isForegroundLocked() line: 1479	         *****lock of StandardSession
	StandardSession.isValid() line: 756	
	StandardSession.getAttribute(String) line: 1354	
	StandardSessionFacade.getAttribute(String) line: 152	
	EagerSessionBeanStore(AbstractSessionBeanStore).getAttribute(String) line: 88	
	EagerSessionBeanStore(AttributeBeanStore).attach() line: 98	
	LazyHttpConversationContextImpl(AbstractConversationContext<R,S>).destroyConversation(S, String) line: 403	
	LazyHttpConversationContextImpl(AbstractConversationContext<R,S>).cleanUpConversationMap() line: 322	             *****lock of Conversations Map of weld)
	LazyHttpConversationContextImpl(AbstractConversationContext<R,S>).deactivate() line: 306	
	LazyHttpConversationContextImpl.deactivate() line: 98	
	ConversationContextActivator.deactivateConversationContext(HttpServletRequest) line: 166	
	HttpContextLifecycle.requestDestroyed(HttpServletRequest) line: 276	
	WeldListener(WeldInitialListener).requestDestroyed(ServletRequestEvent) line: 150	
	WebModule(StandardContext).fireRequestDestroyedEvent(ServletRequest) line: 5294	
	StandardHostValve.postInvoke(Request, Response) line: 255	
Daemon Thread [http-listener-1(7)] (Suspended)	
	owns: StandardSession  (id=179)	
		waited by: Daemon Thread [http-listener-1(40)] (Suspended)	
		waited by: Daemon Thread [http-listener-1(33)] (Running)	
		waited by: Daemon Thread [http-listener-1(31)] (Running)	
		waited by: Daemon Thread [http-listener-1(18)] (Running)	
		waited by: Daemon Thread [ContainerBackgroundProcessor[StandardEngine[glassfish-web].StandardHost[server].StandardContext[/apl]]] (Suspended)	
		waited by: Daemon Thread [http-listener-1(10)] (Running)	
		waited by: Daemon Thread [http-listener-1(9)] (Running)	
		waited by: Daemon Thread [http-listener-1(1)] (Running)	
	waiting for: Collections$SynchronizedMap<K,V>  (id=180)	
		owned by: Daemon Thread [http-listener-1(40)] (Suspended)	
	LazyHttpConversationContextImpl(AbstractConversationContext<R,S>).destroy(S) line: 366	          *****lock of Conversations Map of weld
	LazyHttpConversationContextImpl.destroy(HttpSession) line: 116	
	HttpSessionContextImpl.destroy(HttpSession) line: 63	
	HttpContextLifecycle.sessionDestroyed(HttpSession) line: 154	
	WeldListener(WeldInitialListener).sessionDestroyed(HttpSessionEvent) line: 144	
	StandardSession.expire(boolean, boolean) line: 910	*****lock of StandardSession
	StandardSession.expire(boolean) line: 854	
	StandardSession.expire() line: 842	
	StandardSession.invalidate() line: 1603	
	StandardSessionFacade.invalidate() line: 204	
	CDIServlet.doGet(HttpServletRequest, HttpServletResponse) line: 59	


 Comments   
Comment by yama0428 [ 23/Mar/17 ]

Sorry, the title is incorrect.
The correct title is following.

Dead lock occurs when both HttpSession#invalidate() and HttpSession#getAttribute(String) are called at the same time.





[GLASSFISH-21706] Deployment is slow and gets timed out after 240 seconds Created: 22/Mar/17  Updated: 22/Mar/17  Resolved: 22/Mar/17

Status: Closed
Project: glassfish
Component/s: deployment
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anajosep Assignee: Vinay Vishal
Resolution: Complete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File jsf_resource_webapproot_web.war    

 Description   

The JSF war file used for CTS tests takes more than 240 seconds to get deployed. The tests use 240 seconds as the time out value and hence these tests fail.
The following war file in the JavaEE CTS bundle takes more than 240 seconds to get deployed. It takes around 300-360 seconds to get deployed.
javaeetck/dist/com/sun/ts/tests/jsf/spec/resource/packaging/webapproot.
Attaching the war used for the test.



 Comments   
Comment by anajosep [ 22/Mar/17 ]

This issue is tracked in BugDB. Closing this issue.





Generated at Mon Mar 27 23:00:43 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.