EJB Timer Service is not available, undeployment failed for context - glassfish

I have the following code:
package ejbs;
import javax.annotation.Resource;
import javax.ejb.Singleton;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerConfig;
import javax.ejb.TimerService;
#Singleton
public class timerbackup {
#Resource
private TimerService timerservice;
#Timeout
public void methodTimeout(Timer timer)
{
System.out.println("timeout");
}
public void settimer(long in)
{
Timer timer=timerservice.createSingleActionTimer(in,new TimerConfig());
}
}
After deploying the application appeared the error message "EJB Timer Service is not available".
To solve the problem i followed these steps:
Access the glash fish admin console (http://localhost:4848)
Go to Configurations->server-config->EJB Container
Select the tab EJB Timer Service
Then fill out Timer Datasource: with your JDBC Resource (i used "jdbc/projecto_final")
Restart the server
As suggested in Set/configure the EJB Timer Service’s DataSource.
This resulted but after sometime the TimerService stopped working. After deploying the application appears the following error messages:
Severe: Exception while loading the app
Severe: Undeployment failed for context /ProjetoEE1
Info: /file:/E:/formacaoJAVA/2moduloJEE/pratica/projecto_final /projfinal2/ProjetoEE1/build/web/WEB-INF/classes/_DEFAULT_PU logout successful
Warning: EJB Timer Service is not available. Timers for application with id 96332697224871936 will not be deleted
The Set/configure the EJB Timer Service’s DataSource also mention this problem, and present a solution in Glassfish DeploymentException: Error in linking security policy for.
The solutions presented in Glassfish DeploymentException: Error in linking security policy for consists basically in delete some files. The answer more voted suggests basically the following:
Stoped the Glassfish server
Deleted all the content from glassfishhome/glassfish/domains/ yourdomainname/generated
Started Glassfish
I have installed the "GlassFish Server 4.1.1", and this doesn´t work.
The second answer more voted suggests the basically the following:
1.All that's needed to fix this problem is delete the entire OSGi cache under $GLASSFISH_HOME/glassfish/domains//osgi-cache
This also doesn´t work.
What i can do? Any help will be very appreciate
Best regards,
Rafael Costa

I have solved the "same" problem in
deleting glassfish/domains/domain-name/generated folder completely
building application again
restarting glassfish application
In my case, I have installed a new version of my application after a Pull/Push operation with GIT and my application has stopped to work. So I know that before this new build my application worked well and that nothing has been changed on Glassfish.
I have found some explanation on another following site
https://dzone.com/articles/solving-ejb-timer-service-not-available-error-in-g-1
The Glassfish application server uses its embedded JAVADB to persist the state of its available EJB timers. Not setting the data resource for the timer service correctly prevents the EJB timers from being restored and eventually from functioning properly. In this case, normally the “EJB timer service not available” error message is returned. This problem prevents any application that uses an EJB timer service from being started or deployed.
There are two procedures available to overcome such blocking situations:
The first solution is to go to JDBC connection pools and double check the health of the Timerpool connection pool by pinging it. If the ping fails then the connection pool needs to be checked or to be redefined.
If pinging the connection pool is successful, then the problem could be the presence of the EJB timer marker file. A marker file is created whenever a problem occurs during the EJB timer service start-up or restore.
Deleting the marker will solve the problem. The marker file "ejb-timer-service-app" located under as-install-parent/glassfish/domains/domain-name/generated/ejb/. Dont forget to restart Glassfish !

Replace
import javax.ejb.Singleton;
With
import javax.inject.Singleton;
It worked for me. I'm using Derby database is it the case for you?

I solved the problem. If i remenber, i created a new JDBC resource and a new JDBC Connection Pool.
The following link explains how to create a JDBC resource and a JDBC Connection Pool.
General Steps for Creating a JDBC Resource
The JDBC resource and the JDBC Connection Pool can be created using the admin console or the asadmin utility.
The following link explains how to use the asadmin utility.Using the asadmin Utility
(I used this utility because in the admin console when i tried to create a JDBC resource and a JDBC Connection Pool appeared an error)
In the admin console, in the created JDBC Resource the field "Pool Name" should equals the name of the created JDBC Connection Pool.
After that i followed these steps:
Configurations->server-config->EJB Container
Select the tab EJB Timer Service
Fill the field Timer Datasource with the name of the JDBC resource.
Restart the server
Any question please feel free.
Best Regards Rafael Santos Costa

Hello I met the same problem if you have glassfish 4.1.1 there is probably an instability in the server with respect to timer.
Solution: update glassfish 4.1 to glassfish 5 and deploy the web application in this new server

Related

Embedded ApacheDS 2.0.0-M16 (on 2nd run only): ERR_250_ENTRY_ALREADY_EXISTS ou=system already exists

Using this example as base, my embedded ApacheDS server runs fine the first time, then, when I stop the JBoss server on which my app runs and start again, and re-deploy, the log returns a load of errors starting with:
'(ERROR [stderr] (MSC service thread 1-1) org.apache.directory.api.ldap.model.exception.LdapEntryAlreadyExistsException: ERR_250_ENTRY_ALREADY_EXISTS ou=system already exists!)'
followed by others that have been accurately identified in this Apache JIRA issue
Every time I stop and start JBoss thereafter, the ApacheDS server starts just fine (same as in the JIRA issue)
The JIRA page states that the issue has been fixed with a little workaround, which I have applied
public EmbeddedADSVerTrunkV2(final File workDir) throws Exception
{
if (!workDir.exists())
{
workDir.mkdirs();
this.initDirectoryService(workDir);
this.service.shutdown();
}
this.initDirectoryService(workDir);
}
but the problem remains for me. The second run always fails before succeeding on the third and subsequent runs.
Are there any new workarounds or fixes that I have missed? Many thanks!
This issue was already fixed, please verify if you have the correct version of the jar file(s).

What can i do when allow_store_upgrade fails?

I'm using neo4j in a glassfish server through a modified version of Alex Smirnov neo4j JCA connector.
My version is available here : https://github.com/Riduidel/neo4j-connector
I'm using this connector with neo4j 1.8.
As a consequence, when i want to use it, i first install the connector in my Glassfish application server, then use this connector in applications wishing to connect to.
It works OK when using it with fresh stores.
But, when using it with stores created with previous version, I encounter weird bugs.
Typically, I got today the following stack
javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#3bbd53b1 from NONE to STOPPED
...
...
.../* JCA internal exception stack */
...
...
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#494b584c from NONE to STOPPED
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1185)
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
... 66 more
Caused by: org.neo4j.kernel.lifecycle.LifecycleException: Failed to transition org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader#494b584c from NONE to STOPPED
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:388)
at org.neo4j.kernel.lifecycle.LifeSupport.init(LifeSupport.java:82)
at org.neo4j.kernel.lifecycle.LifeSupport.start(LifeSupport.java:116)
at org.neo4j.kernel.InternalAbstractGraphDatabase.run(InternalAbstractGraphDatabase.java:227)
at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:79)
at org.neo4j.kernel.EmbeddedGraphDatabase.<init>(EmbeddedGraphDatabase.java:70)
at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:165)
at com.netoprise.neo4j.AbstractNeo4jManagedConnectionFactory.createDatabase(AbstractNeo4jManagedConnectionFactory.java:127)
at com.netoprise.neo4j.Neo4jManagedConnectionFactory.createManagedConnection(Neo4jManagedConnectionFactory.java:163)
at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:160)
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
... 68 more
Caused by: java.lang.AssertionError
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:265)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.cleanWriteLocks(LuceneDataSource.java:260)
at org.neo4j.index.impl.lucene.LuceneDataSource.<init>(LuceneDataSource.java:185)
at org.neo4j.index.lucene.LuceneIndexProvider.load(LuceneIndexProvider.java:72)
at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.loadIndexImplementations(InternalAbstractGraphDatabase.java:1171)
at org.neo4j.kernel.InternalAbstractGraphDatabase$DefaultKernelExtensionLoader.init(InternalAbstractGraphDatabase.java:1143)
at org.neo4j.kernel.lifecycle.LifeSupport$LifecycleInstance.init(LifeSupport.java:382)
... 78 more
A fast inspection reveals that this exception is linked to an undeletable "write.lock" file. My write.lock file can't be deleted because I guess migration is not over.
How can I make sure the migration is done before using it without migrating it outside of Glassfish ?
Is there a way to ahve exclusive store migrations in that context ? And if so, how ?
And is it the solution for my problem ?
EDIT 1 Added exception message.
EDIT 2 All this only happen when loaded graph was previously used with a Neo4j 1.5 and now with a Neo4j 1.8 connector. when graph is created by connector, absolutely no error happens.
EDIT 3 Strangely enough, this happens as long as there is no debugger plugged into that code : as soon as I try to debug it, the issue stop appearing. Which make me thinking there may be a migration cleanup mechanism that remvoe the write lock once migration is done, and this cleanup is not performed when using my neo4j JCA connector. Is it a valid observation ?
I am not too familiar with the JCA connector, but to be sure, I would just write a very small migration java class that opens the database, lets it migrate and shut down. Then try it again with the JCA connector?
After further investigations, truth revealed to not be in multiple calls to the EmbeddedGraphDatabase constructor, but instead to multiple identicail IndexProvider being loaded.
I use neo4j embedded in an open-source JCA connector.
In this connector, the org.neo4j.kernel.Service class is replaced by a custom one which contains a workaround regarding service loading for JBoss non shared libraries.
Unfortunatly, in our context, this workaround implies loading twice the index provider :
once using the EAR classloader
once using the Glassfish library classloader.
Why ?
Because, as our neo4j instance is using for application data AND for authentication, neo4j connector jar is put in ${domain}/lib. As a consequence, due to Classloader delegation in application server, the EAR classloader delegates to the Glassfish library classloader, and find this way the LuceneIndexProvider. Then, the Glassfish library classloader is directly used to load the same LuceneIndexProvider class.
This concludes by us having two LuceneIndexProvider objects, both trying to migrate the lucene index. Which lead to the AssertionError as the write.lock file created by the first object should be deleted by the second one, which can't do that.
I've then changed slightly that very specific class to use JBoss workaround only when default loading mechanism do not return any class (seee commit here). This small change worked like a charm, so I think you can considered this issue as fixed.

WebLogic Portal VCR IllegalMonitorStateException connection to JSR-170 Repository

We have recently upgraded from WebLogic Portal 9.2.3 to 10.3.5. We have a JackRabbit repository connected through the Day Software JSR-170 VCR-JCR provider. This has all worked perfectly fine on 9.2.3, but on 10.3.5 we are getting a IllegalMonitorStateException when we try to retrieve content. We have out own facade on top of JackRabbit, that implements the JCR-170. Here is the debug out from the server:
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2b70161: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2bf2311: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: (re)initializing all repo sessions for username: <anonymous>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():801] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: no session found for repoName=indhold; need to connect
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():821] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connect write lock acquired for repoName=indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository():875] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connecting to repositoryName= indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass():1503] invoking Class.forName(repoClassName)
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository():1403] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: Ticket authentication error for: indhold java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1317)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass(RepositoryManagerDelegate.java:1537)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository(RepositoryManagerDelegate.java:1327)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository(RepositoryManagerDelegate.java:893)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository(RepositoryManagerDelegate.java:832)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connect(RepositoryManagerDelegate.java:1160)
at com.bea.content.federated.internal.delegate.RepositoryHelper.checkCapability(RepositoryHelper.java:759)
at com.bea.content.federated.internal.CapabilityManagerImpl.checkRepositoryCapability(CapabilityManagerImpl.java:57)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.checkCapability(ManagerImplCapabilityHelper.java:80)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.verifyCapability(ManagerImplCapabilityHelper.java:54)
at com.bea.content.federated.internal.NodeManagerImpl.getNode(NodeManagerImpl.java:432)
at dk.skat.portal.front.helper.ContentHelper.getNode(ContentHelper.java:1591)
It seems that authenticationn fails, but if I try to set a break-point in the login methods in the repository (our Facade, which doesn't do any authentication challenge, but just wraps JackRabbit, and logs in the same user - "default" - for all access), we are never getting called. Setting the username and password on the Manage Repositories page, doesn't seem to have any effect.
If I on the other hand go to Portal Administration Console, and try to manage or browse the repository, everything works fine, and the login methods are actually called, and the server connects fine to the repository.
This seems very strange. In cetain cases (that happens to happen randomly, we can get the server to all of a sudden get to the repository, but on restart of the server, it is again back to failing).
I've tried to set username/password for the repository to the weblogic user, but that doesn't seem to have any effect, I still get the error.
Furthermore when I've been into the PAC, and logs out, closes the browser, reopen the browser or a completely different browser, the entering of PAC seems to activate the repository to become online (though this is not stable or desired).
Please advice, if there is a bug in WebLogic (it seems it tries to unlock() the ReadLock too many times, resulting in the mentioned exception - should it at all fail on that exception??, Should the lock-count be checked before unlocking?), or if w are doing anything wrong? I can read that there is a known bug in the eclipse tooling for 10.3.5 about exactly this error.
Furthermore, we didn't seem to have any trouble in 9.2.3, what changed in 10.3.5?
Had same issue, found solution here https://forums.oracle.com/forums/thread.jspa?messageID=10984645
In short, it is a product bug, request following patch from Oracle:
WLP Version: 10.3.5
Patch Name/Patch Number/Bug Number: 14377862
Smart Update Patch ID: HPV8

Weblogic 10 Managed servers running, but I get a 404 error

I have migrated an application from WL 8 to WL 10 and set up my managed servers. They indicate that they are running, but when I try to access the site it throws a 404. This is my first time deploying anything on 10 so I could be missing something. Any ideas? Please let me know what additional information could be helpful. edit: I had this working, added a db connection and now it fails.
Here is my error:
weblogic.management.DeploymentException: Exception occured while downloading files
at weblogic.deploy.internal.targetserver.datamanagement.AppDataUpdate.doDownload(AppDataUpdate.java:43)
at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.download(DataUpdate.java:56)
at weblogic.deploy.internal.targetserver.datamanagement.Data.prepareDataUpdate(Data.java:98)
at weblogic.deploy.internal.targetserver.BasicDeployment.prepareDataUpdate(BasicDeployment.java:670)
at weblogic.deploy.internal.targetserver.BasicDeployment.stageFilesForStatic(BasicDeployment.java:713)
at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:100)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
java.io.IOException: [DeploymentService:290066]Error occurred while downloading files from admin server for deployment request "0". Underlying error is: "[DeploymentService:290065]Deployment service servlet encountered an Exception while handling the deployment datatransfer message for request id "0" from server "TEST01". Exception is: "weblogic.management.configuration.JDBCSystemResourceMBeanImpl"."
at weblogic.deploy.service.datatransferhandlers.HttpDataTransferHandler.getDataAsStream(HttpDataTransferHandler.java:86)
at weblogic.deploy.service.datatransferhandlers.DataHandlerManager$RemoteDataTransferHandler.getDataAsStream(DataHandlerManager.java:153)
at weblogic.deploy.internal.targetserver.datamanagement.AppDataUpdate.doDownload(AppDataUpdate.java:39)
at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.download(DataUpdate.java:56)
at weblogic.deploy.internal.targetserver.datamanagement.Data.prepareDataUpdate(Data.java:98)
at weblogic.deploy.internal.targetserver.BasicDeployment.prepareDataUpdate(BasicDeployment.java:670)
at weblogic.deploy.internal.targetserver.BasicDeployment.stageFilesForStatic(BasicDeployment.java:713)
at weblogic.deploy.internal.targetserver.AppDeployment.prepare(AppDeployment.java:100)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doPrepare(DeploymentAdapter.java:39)
at weblogic.management.deploy.internal.DeploymentAdapter.prepare(DeploymentAdapter.java:187)
at weblogic.management.deploy.internal.AppTransition$1.transitionApp(AppTransition.java:21)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.prepare(ConfiguredDeployments.java:165)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:122)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
You got a weblogic.management.DeploymentException and this means that something went wrong in some server even if everything seems OK from the console.
Underlying error is from weblogic.management.configuration.JDBCSystemResourceMBeanImpl so I would review datasource config is appropiate for every target in your environment. Also check that datasource targets are the same as web application targets and JDBC drivers are available at managed servers classpath as well.
Try to log to the WebLogic Admin console and see what is the status of your application.
You can use the 'Testing' tab of your deployment to see the URL that the application has been deployed to. This will assist you in the troubleshooting process.
If you don't see anything here to test there are a few possible reasons, including the following:
The application failed to deploy and/or is not 'Active'
You are using a cluster and no managed servers are running
You have managed servers running but they are not in a 'RUNNING' state

how to fix Javax. Naming.exception: nameNotFoundException <my_JNDI_name> not found

I got this exception while trying to deploy ejb-jar file on a glassfish 2.1 :
Javax. Naming.exception: nameNotFoundException not found.
This drive me to be crazy !!!
I don't know why i got this exception while when i launch the hole application (ear) using Netbeans 6.7.1 with integrated glassfish 2.1 it work like magic !
But when i try to deploy it manually under another glassfish in an other pc it does not work
And i am having this exception when i try to deploy it
So i think that the ejb module does not find out how to link to the database
So it must be something that the netbeans do and i am not, when deploying the ejb-jar
Any help ?
I realise this is a bit old, but having just worked through this, I thought I may as well document it here.
For me the issue was the database connection. In your project you should have a persistence.xml file (mine was in the EJB project), which details the database connection parameters. I was using a localhost URL, but when I ran the database project, I noticed in my Services tab under Glassfish that no database connection was being registered.
Here's what I did:
Create a new database connection (right click in Services, Java DB node)
In Services, right click Java DB connection, Properties, check that the pool it's registered to is in the Glassfish JDBC Connection Pools and is the correct one, if not, make sure your database connection is correct, update persistence.xml
Clean the project before running again
This worked for me, hope it's helpful for someone else.