f.haeder.net

Search

Items tagged with: Payara

Maybe I need to explain more about my program. On initialization of the backing bean (means when an instance is being created and the web container is creating a wrapper class around it) I load the entire table rows from the EJB to into the controller to cache it there (see #JCache #JS107 ).

This gives great performance improvement due to not with every request (POST/GET) data is not being loaded from database but taken from cache. This is what I call asynchronous loading of data, most PHP applications however are synchronous, means with every click data is fetched from database and scripts are loaded and parsed (OpCache is maybe a bit improving here) and are being "forgotten" after the request was finished.

But with a JSF application, the "controller" (backing bean) remains instanced (and wrapped) in the web container's heap until you redeploy the application or restart the web container.

So sure I want to use that advantage of having all loaded at "all" (not at the beginning, but you can implement a ServletContextListener interface where you can "hook" on the initialization phase) times. Still this issue is there.

As you can see, not on every request these SQL queries are performed (which is very good for overall performance) but still they are really a lot. Just imagine 1,000 users on your web server (you may need a cluster then) and several 10,000 records.

Sure, when you cache them all in RAM, then you need a lot RAM. The #Payara application server uses here #Hazelcast ( https://hazelcast.com/ ) for having a distributed heap (cluster members contribute their heap to the cluster) and JCache (JSR107).

So what now? I still found this a bit to much. Currently I use eager fetch-mode, I could switch to lazy but that only delays the problem as foreign entities are being lazyless (on getter invocation) loaded.
 

JPA causes tons of SQL queries

I'm currently developing (free time project) a Java Server Faces application which uses the #JPA (very common to do so) over EJBs (Enterprise Java Beans). When I turned on logging of SQL queries, I thought I didn't see it right. For each entity ("row" in database table) a distinct query has been issued. Means, when I have 1,000 rows, the same amount of queries are being issued.

This can become a nightmare when "only" 100 users are on the server. Does someone know how to reconfigure the JPA (I use #Payara ) to issue only one SQL query per table?

Surely I have used JPQL (Java Persistence Query Language) and no WHERE was used there. So normally the whole table should be fetched. But this is not the case for linked tables (e.g. with @OneToOne) where each such referenced entity is being fetched distinctly.

So is there a way to prevent this from happening? RAM is not a issue here. 16 GB are installed and data will not grow so much.
 
Just deploy it (here with #Payara, maybe Micro works?) and unselect all, then select "None selected".
 
In case of you downloaded #payara 173 full and you get an ezception and payara doesn't start, you have delete 3 jars starting with microprofile*.
 

Why I don't like payed support #2

I currently face a #bug in #Payara that doesn't allow TABLE_PER_CLASS and I cannot change the database layout (as then the main program needs to be changed which involves a lot risky work).

I have filled out a bug report ...
https://github.com/payara/Payara/issues/966

... But they don't want to handle it. I guess I'm not alone with this bug. I don't like such "payment model" where paying customers are priotized. I for my projects provide unpriotized support for any one, unpayed and in my free time: My View - Mailer-Project Bug-Tracker
What do you think about such payment models? Good or bad?

2nd submit: better preview before test.
 

The class does not have a descriptor, or a descriptor that does not use inheritance or uses a ClassExtractor for inheritance

The mentioned message still comes when you have @Inheritance (strategy = InheritanceType.TABLE_PER_CLASS) in your abstract (not-persisted) with latest version of #Payara / #Glassfish which both contains #EclipseLink by default.

Strange that they did not yet fix it. And unfortunally migrating to e.g. #WilfFly (which uses other #JPA) seems not so easy as you may think.

Currently I have no idea how to fix it and sadly I need the strategy as this #JavaEE application is written for an existing database layout.

Someone may have to raise a support ticket mentioning that the #bug is still there.

Reposted with #public visibility. Sorry for double message.
 

Glasfish / Payara sometimes throw ClassCastException

I sometimes get this error message after I have redeployed (also with in-place deployment) a WAR project and have tried to use a JSF form:
Warnung: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:150)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:352)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:482)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:201)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
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:498)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:421)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:527)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:487)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at de.chotime.jreports.beans.contact.ReportsContactWebSessionBean.<init>(ReportsContactWebSessionBean.java:237)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:119)
at org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:92)
at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:116)
at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:180)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.util.bean.IsolatedForwardingBean.create(IsolatedForwardingBean.java:45)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76)
at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:67)
at org.jboss.weld.event.ObserverMethodImpl.getReceiver(ObserverMethodImpl.java:339)
at org.jboss.weld.event.ObserverMethodImpl.getReceiverIfExists(ObserverMethodImpl.java:326)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:284)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:271)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:260)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89)
at de.chotime.jreports.beans.login.ReportsUserLoginWebSessionBean.doUserLogin(ReportsUserLoginWebSessionBean.java:170)
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:498)
at javax.el.ELUtil.invokeMethod(ELUtil.java:332)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:537)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
at com.sun.el.parser.AstValue.invoke(AstValue.java:283)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304)
at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40)
at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
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:526)
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:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)


My previous #JavaEE trainer said it is a bug in #Glassfish / #Payara but it starts to become more anoying. Does someone know something to prevent this from happening?

Yes, filling out a bug report may help. :-) But maybe there is a trick or so?

The most "outter" exception says:
javax.servlet.ServletException: javax.faces.view.facelets.FaceletException: javax.naming.NamingException: Lookup failed for 'java:global/jreports-ejb/contact!org.mxchange.jcontacts.contact.ContactSessionBeanRemote' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfaceorg.mxchange.jcontacts.contact.ContactSessionBeanRemote [Root exception is java.lang.ClassCastException]]


The interface in question (see the JNDI string end) "ContactSessionBeanRemote" is annotated with @Remote (javax.ejb.Remote) and not java.rmi.Remote as the exception says.

It is declared as following:
public interface ContactSessionBeanRemote extends Serializable {
...
}
 
@netmackan well, since #Payara is based on #Glassfish, I guess I will face the same problems when I try to use #Hibernate (as it does an UPDATE and not as #EclipseLink does an INSERT on updating referenced entities).
 
@roland Have you tried #Payara maybe they have fixed the #GlassFish issue.

Payara Home

Payara Server - Derived from GlassFish with 24/7 Support
 
Later posts Earlier posts