[GLASSFISH-21131] NCLS-CORE-00026: Naming binding already exists Created: 16/Jul/14  Updated: 28/May/15

Status: In Progress
Project: glassfish
Component/s: deployment
Affects Version/s: 4.1_b09
Fix Version/s: None

Type: Bug Priority: Major
Reporter: e1ywka Assignee: Arindam Bandyopadhyay
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MS Windows 7, Oracle JDK 8u5


Tags: fishcat

 Description   

Issue ocures during deploying app packaged as war

web.xml descriptor contains resource declaration:
<env-entry>
<env-entry-name>envEntryName</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>envEntryValue</env-entry-value>
</env-entry>

There is stateless bean, packaged in jar and located in WEB-INF/lib directory. Bean has field annotated with @javax.annotation.Resource.

Exception stacktrace:
[2014-07-16T13:37:42.214+0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=46 _ThreadName=admin-listener(5)] [timeMillis: 1405503462214] [levelValue: 1000] [[
Exception while deploying the app [envEntryTest]]]

[2014-07-16T13:37:42.215+0400] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=46 _ThreadName=admin-listener(5)] [timeMillis: 1405503462215] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.IllegalStateException: Naming binding already exists for envEntryName in namespace

{java:module/env/envEntryName=Env-Prop: envEntryName@Non-Injectable Resource@java.lang.String@@@}

at com.sun.enterprise.deployment.util.EnvEntriesValidator.throwConflictException(EnvEntriesValidator.java:235)
at com.sun.enterprise.deployment.util.EnvEntriesValidator.validateEnvEntry(EnvEntriesValidator.java:153)
at com.sun.enterprise.deployment.util.EnvEntriesValidator.validateSimpleEnvEntries(EnvEntriesValidator.java:115)
at com.sun.enterprise.deployment.util.EnvEntriesValidator.validateEnvEntries(EnvEntriesValidator.java:87)
at com.sun.enterprise.deployment.util.ApplicationValidator.validateEnvEntries(ApplicationValidator.java:517)
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:118)
at com.sun.enterprise.deployment.BundleDescriptor.visit(BundleDescriptor.java:625)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:190)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:203)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:227)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:881)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:821)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
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:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
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:561)
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:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]



 Comments   
Comment by Arindam Bandyopadhyay [ 28/May/15 ]

During the initial analysis I found

Project 1 ---->
Structure -->You have beans under WEB-INF/lib (which has field with @Resource) , don't have WEB-INF/ejb-jar.xml and have <env-entry> defined in the WEB-INF/web.xml .
Deployment Result -->Deployment fails with Naming binding already exists error.(same error as reported by you)
-------------
Project 2 --->
Structure -->You have same structure as Project1 except you have basic WEB-INF/ejb-jar.xml to your project.The <env-entry> still defined in the WEB-INF/web.xml and WEB-INF/ejb-jar.xml have very basic tag like <ejb-jar> <enterprise-beans><session><ejb-name>.
Deployment Result -->Deployment is successful.

Please let me know if you have project structure like Project1. It will help us narrowing down the route cause and fix efficiently .

Comment by e1ywka [ 28/May/15 ]

I have project structure like Project 1. WEB-INF folder contains web.xml I mentioned and it contains beans.xml with empty <beans> tag.





[GLASSFISH-21366] move ejb System Value Classes from ejb-container.jar into their own jar Created: 27/May/15  Updated: 27/May/15

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: phendley Assignee: Jill Sato
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Tags: cts, ejb,, packaging

 Description   

The following EJB System Value Classes of:
javax.ejb.Handle
javax.ejb.HomeHandle
javax.ejb.EJBMetaData
do exist in (glassfish) ejb-container.jar but contrary to spec, the
ejb-container.jar is not easily usable by hosted app servers.

The EJB 3.2 core spec (section 10.5.5) states:
"System value classes are serializable value classes implementing the
javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData, java.util.Enumeration, java.util.Collection, and java.util.Iterator interfaces. These value classes are pro- vided by the EJB container vendor. They must be provided in the form of a JAR file by the container hosting the referenced bean. For interoperability scenarios, if a referencing component would use such system value classes at runtime, the Deployer must ensure that these system value classes provided by the container hosting the referenced bean are available to the referencing component."

As an example of the problem scenario, if we try to include the ejb-container.jar on the WebLogic servers
classpath, WebLogic runs into conflucts during startup because it either can not resolve all dependencies specified in the ejb-container.jar file OR it runs into issues with conflicts due to hk2 classes referenced in ejhb-container.jar that are also included in weblogics appserver. Fortunately, weblogic was able to add a switch to allow ignoring hk2 classes from non-weblogic entities. But this points out the problem that the System Value classes SHOULD be pulled out of ejb-container.jar and put into their own separate jar as was intended by the spec.

The priority of this could change if other vendors encounter problems with this issue as it was originally found through cts tests. Fortunately, a workable solution was found by the vendor under test - even though a more appropriate solution should have been addressed by glassfish.






[GLASSFISH-21365] No content from web application without web.xml Created: 27/May/15  Updated: 27/May/15

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

Type: Bug Priority: Blocker
Reporter: petrhejl Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1) download GF 4.1 and unzip it
2) cd glassfish4/glassfish/bin
3) ./asadmin
4) start-domain
5) change-admin-password (configure admin password to glassfish)
6) enable-secure-admin
7) stop-domain
8) start-domain
9) deploy the simplest Java EE 7 app without any descriptor (web.xml) - for example: curl -v --insecure --user admin:glassfish https://127.0.0.1:4848/__asadmin/deploy?DEFAULT=/home/petr/NetBeansProjects/WebApplication1/dist/WebApplication1.war\&force=true\&name=WebApplication1\&contextroot=/WebApplication1
10) Access the aplication: curl -v http://localhost:8080/WebApplication1/
11) No content:
< HTTP/1.1 200 OK

  • Server GlassFish Server Open Source Edition 4.1 is not blacklisted
    < Server: GlassFish Server Open Source Edition 4.1
    < X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1 Java/Oracle Corporation/1.7)
    < Date: Wed, 27 May 2015 12:34:43 GMT
    < Content-Length: 0

In the server log:
WEB9100: No WebSecurityManager found for context WebApplication1/WebApplication1

The issue persists until the deployment of the first app containing web.xml.






[GLASSFISH-21364] Bump eclipselink version to solve jdk8 related issues Created: 27/May/15  Updated: 27/May/15

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1
Fix Version/s: None

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


 Description   

Can we please bump the eclipselink version so that the following bug is solved:

  • IndirectList is missing the new sort method introduced in Java 8

As described here:

http://stackoverflow.com/questions/26816650/java8-collections-sort-sometimes-does-not-sort-jpa-returned-lists

and described here:

http://stackoverflow.com/questions/27935032/foreach-and-sort-dont-work-and-cannot-set-breakpoints-in-blocks

The eclipselink bugs are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=433075
https://bugs.eclipse.org/bugs/show_bug.cgi?id=446236

Target milestone is: 2.7.0

Maybe they will fix it for 2.6 though.

In any case it would be really important for JDK8 users get this into Glassfish 4.2 please.



 Comments   
Comment by rainerschamm [ 27/May/15 ]

Sorry the other bug title is:

  • Stream API gets no results

And I see that its fixed in 2.6. But the list issue is not fixed in a release yet.





[GLASSFISH-18685] X-Forwarded-Proto not honored by glassfish Created: 03/May/12  Updated: 27/May/15  Resolved: 08/Jun/12

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Major
Reporter: galabar Assignee: shreedhar_ganapathy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Attachments: Zip Archive patch-18685-and-18686.zip    
Issue Links:
Relates
relates to GLASSFISH-20842 X-Forwarded-Proto not honored by glas... Resolved

 Description   

I am using a reverse proxy configuration in Apache with mod_proxy_http. I set the X-Forwarded-Proto header to either "http" or "https" depending on how the client accessed Apache.

Glassfish ignores this header and uses the "http" protocol specified in the Apache ProxyPass statement when building URLs (I am using Jersey and UriBuilder to create the URLs).

I was moving over from Jetty where this is supported:

http://wiki.eclipse.org/Jetty/Tutorial/Apache

Is there any way to accomplish this in Glassfish?



 Comments   
Comment by galabar [ 03/May/12 ]

Here are some related issues:

http://home.java.net/forum/topic/glassfish/metro-and-jaxb/handle-x-forwarded-proto-behind-ssl-offloader-and-glassfish?force=465
http://stackoverflow.com/questions/5394912/wsdl-bad-url-generation-behind-nginx-haproxy

Comment by oleksiys [ 08/Jun/12 ]

will be fixed starting from GF 3.1.2 UR 2.

Comment by oleksiys [ 08/Jun/12 ]

patch for Glassfish 3.1.2

fixes issue 18685 + 18686

  • to specify HTTP request header name, whose value would be mapped to protocol scheme, use attribute scheme-mapping like (in the domain.xml file):

<http default-virtual-server="server" max-connections="250" scheme-mapping="X-Forwared-Proto">

  • to specify HTTP request header name, whose value would be mapped to remote-user, use attribute remote-user-mapping like (in the domain.xml file):

<http default-virtual-server="server" max-connections="250" remote-user-mapping="X-Forwarded-User">

Comment by dazed [ 27/May/15 ]

For anyone following - slight typo in the last (sorry oleksiys) - "+d" missing in "X-Forwared-Proto" to "X-Forwarded-Proto" - copy and paste caught me out

<http default-virtual-server="server" max-connections="250" scheme-mapping="X-Forwarded-Proto">





[GLASSFISH-21360] JK connector configuration file not populating Created: 19/May/15  Updated: 26/May/15

Status: Open
Project: glassfish
Component/s: load_balancer
Affects Version/s: 4.1
Fix Version/s: None

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

RHEL 6.6
Glassfish 4.1 build 13



 Description   

After configuring a cluster with a JK connector and setting the jk-configuration-file to a valid location, the jk-configuration-file does not get created or populated. I have restarted the DAS and the cluster to no avail. The appropriate line in the domain.config file is as such:
<network-listener protocol="http-listener-1" jk-enabled="true" port="$

{AJP_PORT}

" name="ajp-listener-1" thread-pool="http-thread-pool" jk-configuration-file="$

{com.sun.aas.instanceRoot}

/config/glassfish-jk.properties" transport="tcp"></network-listener>

No error is reported in the logs. The JK port is open and available.



 Comments   
Comment by jliedy [ 26/May/15 ]

Nevermind. Close the ticket. Sorry.





[GLASSFISH-21266] Start domain does not follow savelogin/savemasterpassword rules Created: 09/Dec/14  Updated: 26/May/15

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

Type: Bug Priority: Major
Reporter: ender01 Assignee: Joe Di Pol
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

OS X 10.10.1 (14B25)


Tags: asadmin, password, start-domain

 Description   

Created a domain with following:
./bin/asadmin --passwordfile ./PASS_FILE --user admin create-domain --portbase 9000 --savemasterpassword --savelogin domain2

PASS_FILE:
AS_ADMIN_PASSWORD=password
AS_ADMIN_MASTERPASSWORD=password

Starting the domain now asks for the password:
./bin/asadmin start-domain domain2
Enter master password (3) attempt(s) remain)>

If I enter the password, all other asadmin commands work as expected, including stop-domain, with out having to enter the password. Even enable-secure-admin worked fine.

It seems odd that saving the password information doesn't work for the start-domain command.



 Comments   
Comment by ender01 [ 09/Dec/14 ]

Output of the create-domain command:

Using port 9048 for Admin.
Using port 9080 for HTTP Instance.
Using port 9076 for JMS.
Using port 9037 for IIOP.
Using port 9081 for HTTP_SSL.
Using port 9038 for IIOP_SSL.
Using port 9039 for IIOP_MUTUALAUTH.
Using port 9086 for JMX_ADMIN.
Using port 9066 for OSGI_SHELL.
Using port 9009 for JAVA_DEBUGGER.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=rohan.local,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=rohan.local-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Domain domain2 created.
Domain domain2 admin port is 9048.
Domain domain2 admin user is "admin".
Admin login information for host [localhost] and port [9048]
is being overwritten with credentials provided because the
--savelogin option was used during the create-domain command.
Login information relevant to admin user name [admin]
for this domain [domain2] stored at
[/Users/nick/.gfclient/pass] successfully.
Make sure that this file remains protected.
Information stored in this file will be used by
administration commands to manage this domain.
Command create-domain executed successfully.

Comment by rdelaplante [ 05/May/15 ]

I also have the same issue. The create-domain command does not save a master-password file in the new domain's directory:

/opt/glassfish/bin/asadmin create-domain --savemasterpassword=true --domainproperties domain.adminPort=4865:domain.instancePort=8097:http.ssl.port=8197 mydomain

I've tried --savemasterpassword=true and --savemasterpassword but neither work. When I try to start the service created with the create-service command, it tells me:

The Master Password is required to start the domain. No console, no prompting possible. You should either create the domain with --savemasterpassword=true or provide a password file with the --passwordfile option.
Command start-domain failed.

Comment by rdelaplante [ 05/May/15 ]

I forgot to mention that this is GlassFish 4.1 running on Debian Linux and JDK 8. Earlier I had GlassFish 3.1.1.2 and JDK 7 installed on the same machine and never had a problem with --savemasterpassword=true not working. The problem started with GlassFish 4.1 (I don't know about 4.0)

Comment by rdelaplante [ 05/May/15 ]

My workaround is to use the following command to create the master-password file after the domain has been created:

/opt/glassfish/bin/asadmin change-master-password --savemasterpassword=true mydomain

The domain should be stopped when you run this command.

Comment by Tobb [ 06/May/15 ]

Same issue here, --savemasterpassword doesn't seem to work. I am able to start the domain if I supply the --passwordfile parameter along with the start-domain command. Running Windows Server 2008 R2 Enterprise.

Comment by francisco_cpg [ 26/May/15 ]

Same problem here.
Using same workaround proposed by rdelaplante.
Why this issue is stopped?

Comment by rdelaplante [ 26/May/15 ]

Deliberate sabotage by the WebLogic group? jk





[GLASSFISH-21363] Deadlock in JavaEEExtender between deploy and undeploy Created: 26/May/15  Updated: 26/May/15

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1, 4.1
Fix Version/s: None

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


 Description   

We have a significant number of OSGi bundles with EJB content. When redeploying a bundle and a dependency of that bundle (simply touching the files) we get a deadlock between the deploy and undeploy in JavaEEExtender.

Here's the two threads, one has the Felix global bundle lock and one is trying to obtain it, while the other has a lock on the JavaEEExtender and one is trying to obtain that.

"pool-15-thread-1" #113 prio=5 os_prio=0 tid=0x00007f147c00e800 nid=0x8a4 in Object.wait() [0x00007f14563eb000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:5039)
	- locked <0x0000000721bfb720> (a [Ljava.lang.Object;)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:1866)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
	at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)
	- locked <0x0000000721346de0> (a org.jvnet.hk2.osgiadapter.OSGiModuleImpl)
	at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:2058)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:413)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:2120)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.access$900(ServiceLocatorImpl.java:119)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1063)
	at org.jvnet.hk2.internal.ServiceLocatorImpl$8.compute(ServiceLocatorImpl.java:1058)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:115)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture$1.call(LRUHybridCache.java:111)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache$OriginThreadAwareFuture.run(LRUHybridCache.java:173)
	at org.glassfish.hk2.utilities.cache.LRUHybridCache.compute(LRUHybridCache.java:292)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:1147)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1395)
	at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:1384)
	at com.sun.enterprise.v3.server.ContainerStarter.startContainer(ContainerStarter.java:112)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainer(ApplicationLifecycle.java:997)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:702)
	- locked <0x000000072068a430> (a org.glassfish.internal.data.ContainerRegistry)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
	- locked <0x000000072ade0e90> (a org.glassfish.osgijavaeebase.OSGiContainer)
	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
	- locked <0x000000072ade0e70> (a org.glassfish.osgijavaeebase.JavaEEExtender)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

And this one

"FelixFrameworkWiring" #369 daemon prio=5 os_prio=0 tid=0x00007f14682cb000 nid=0x1296 waiting for monitor entry [0x00007f1474a59000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.glassfish.osgijavaeebase.JavaEEExtender.undeploy(JavaEEExtender.java:122)
	- waiting to lock <0x000000072ade0e70> (a org.glassfish.osgijavaeebase.JavaEEExtender)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$600(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer.removedBundle(JavaEEExtender.java:206)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:491)
	at org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved(BundleTracker.java:414)
	at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341)
	at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:449)
	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)
	at org.apache.felix.framework.Felix.stopBundle(Felix.java:2520)
	at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4792)
	at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4104)
	at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:178)
	at java.lang.Thread.run(Thread.java:745)

It seems like the JavaEEExtender class has two problems. 1) One is that deploy and undeploy are synchronized although comments indicate that synchronization is to prevent deploys and undeploys while the class is starting and stopping. A ReadWriteLock could be used to accomplish the goal without making deploy and undeploy mutually exclusive. 2) More importantly, undeploy isn't done in a separate thread like deploy so you can get into this deadlock situation because the felix global lock is held when undeploy is called. Moving undeploy into its own thread should solve that problem (and avoid kicking the deadlock problem down the road to the highly synchronized OSGiContainer).






[GLASSFISH-21238] Response code 400 on a DELETE request with a body Created: 21/Oct/14  Updated: 22/May/15

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ganichev Assignee: oleksiys
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Same behavior on linux x64, windows 7 x64. jdk1.8.0_20



 Description   

When a browser sends a request with a method DELETE and some body, glassfish replies with the response code 400. No corresponding filters or a servlet are called.

When a DELETE request contains no body, then servlet's methods are called as usual.

Glassfish 4.0 has no such problem.

Th sample request is:

DELETE /struct/StructureElement/3751?_dc=1413865817878 HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 11
Origin: http://localhost:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36
Content-Type: application/json
Accept: */*
Referer: http://localhost:8080/struct-client/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ru;q=0.6
Cookie: BPMSESSIONID=8aMBU61U7xn1RFSObP1slBhkvMCC; JSESSIONID=d116d19d27d9a381eef12b5acacd; treeForm_tree-hi=treeForm:tree:resources:JDBC:connectionPoolResources:ypool

{"id":3751}


 Comments   
Comment by timuralp [ 22/May/15 ]

This comes up when attempting to implement OpenStack Swift, as the Bulk Delete operation specifies the DELETE verb with an entity containing the list of (container, object) pairs to remove – http://docs.openstack.org/kilo/config-reference/content/object-storage-bulk-delete.html





[GLASSFISH-21359] Issue with the glassfish jvm Created: 15/May/15  Updated: 22/May/15

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

Type: Bug Priority: Major
Reporter: tejas.pathak Assignee: Joe Fialli
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Issue with the glassfish jvm , Glassfish jvm went down with the following error as seen in the jvm logs :
snippet of error :
[#|2015-05-13T09:41:20.233-0400|WARNING|oracle-glassfish3.1.2|ShoalLogger|_ThreadID=87;_ThreadName=Thread-2;|GMS1078: NetworkUtility.deserialized current objects: thread=GMS-McastMsgProcessor-Group-cluster1-thread-8 messages=

{LMWID=39, targetPeerId=10.1.2.109:9195:228.9.213.46:22325:cluster1:instance1}

failed while deserializing name=HM|#]

[#|2015-05-13T09:41:20.233-0400|WARNING|oracle-glassfish3.1.2|ShoalLogger|_ThreadID=87;_ThreadName=Thread-2;|GMS1071: damaged multicast packet discarded
com.sun.enterprise.mgmt.transport.MessageIOException: failed to deserialize a message : name = HM
at com.sun.enterprise.mgmt.transport.MessageImpl.readMessagesInputStream(MessageImpl.java:349)
at com.sun.enterprise.mgmt.transport.MessageImpl.parseMessage(MessageImpl.java:239)
at com.sun.enterprise.mgmt.transport.BlockingIOMulticastSender$MessageProcessTask.run(BlockingIOMulticastSender.java:350)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2015-05-13T09:41:20.265-0400|WARNING|oracle-glassfish3.1.2|ShoalLogger|_ThreadID=84;_ThreadName=Thread-2;|GMS1078: NetworkUtility.deserialized current objects: thread=GMS-McastMsgProcessor-Group-cluster1-thread-9 messages=

{LMWID=39, targetPeerId=10.1.2.109:9195:228.9.213.46:22325:cluster1:instance1}

failed while deserializing name=HM|#]

[#|2015-05-13T09:41:20.265-0400|WARNING|oracle-glassfish3.1.2|ShoalLogger|_ThreadID=84;_ThreadName=Thread-2;|GMS1071: damaged multicast packet discarded
com.sun.enterprise.mgmt.transport.MessageIOException: failed to deserialize a message : name = HM
at com.sun.enterprise.mgmt.transport.MessageImpl.readMessagesInputStream(MessageImpl.java:349)
at com.sun.enterprise.mgmt.transport.MessageImpl.parseMessage(MessageImpl.java:239)
at com.sun.enterprise.mgmt.transport.BlockingIOMulticastSender$MessageProcessTask.run(BlockingIOMulticastSender.java:350)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

#]

Following are the versions of the software :
Operating System : Windows server 2012
Jdk version : jdk1.6.0_45
Glassfish version : Oracle GlassFish Server 3.1.2.2 (build 5)



 Comments   
Comment by tejas.pathak [ 19/May/15 ]

Any update regarding this issue ?

Comment by tejas.pathak [ 22/May/15 ]

Any update regarding this issue ?





Generated at Fri May 29 11:40:55 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.