Dhiraj Mahapatro

Greenhorn
+ Follow
since Oct 28, 2007
Dhiraj likes ...
Eclipse IDE Spring Tomcat Server
Merit badge: grant badges
For More
New Jersey
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dhiraj Mahapatro

Hi

My question might be a trivial one. Here it is:

We know that we can use Spring Insight or any other profiler plugin to profile a grails application in order to monitor HTTP requests. Particularly talking about Spring Inight, can we profile the grails app for SOAP requests?

I am using Spring WS plugin to produce endpoints in the grails app. I wanted to monitor the performance of the endpoint down Till the JDBC layer. I went through documents related to usage of Spring Insight but in vain, I din't find anything for SOAP requests. My last resort would be to get the development kit and develop my own insight plugin for WS endpoint and see how it goes.

Please let me know if anyone has come across this situation or can throw some insight on Spring Insight.

Grails 2.0.4; STS 2.9.2
10 years ago
Congratulations on your achievement!!!

You are being too generous. That was only a proper communication and successful resource hunt. I will definitely ping you whenever needed to harness your expertise on EJB 3.0.

In the mean time I will suggest you to go through new patterns like DI [Dependency injection], Spring Framework..... which I feel are also interesting and worth spending time with. Its my recent experience.

Hail Java!!Hail OOP!!

vika mishra wrote:

[jar] Building jar: D:\portal\build\jars\portal-ejb-temp-wl10.jar
[java] <Jan 21, 2011 7:42:13 PM IST> <Error> <J2EE> <BEA-160197> <Unable to load descriptor D:\portal\build\jars\portal-ejb-temp-wl10.jar/META-INF/ejb-jar.xml of module portal-ejb-temp-wl10.jar. The error is java.io.IOException



Check the build.xml.

ejb-jar.xml is referred from the jar itself which you are working on/building.
The path D:\portal\build\jars\portal-ejb-temp-wl10.jar would be the out come of the build process.

D:\portal\build\jars\portal-ejb-temp-wl10.jar/META-INF/ejb-jar.xml doesn't seem like a location for the ejb-jar.
Is the listener assigned to one or more consumers of the same session?
I guess Tom is correct.
In addition to that I would suggest to use the ListIterator li wherever possible in place of directly handling the ArrayList in the code.

The basic theory beneath this is "You have your guy [iterator] to do the work for a Customer[arraylist]. you need not contact the customer[arraylist] directly. Route through the guy [iterator]"
If anyone tries to handle both the jobs, you develop a concurrency and hence java.util.ConcurrentModificationException.

The code would look like




Try this way. It should work. Please also look at the recursion.

Thanks.....
Can you please elaborate the scenario and the environment?

Akshay Sahu wrote:Hello Friends,

I was preparing for SCBCD 5 and I was unable to find the following topic:

Identify correct and incorrect statements or examples about the effect of persistence exceptions on transactions and persistence contexts.


Can anyone please tell me the place or the book or a link, where I can find these topics.

Thanking You (in advance)
Akshay Sahu.




Its like searching for Water inside the Well ...

Here is what you can refer......

Look for "Persistence Unit Scope"

Enjoy.....!!!
In case of JBoss: It will try to create a TIMERS table in the datasource it is configured to use (by default this is DefaultDS which points to a HSQL database in the data directory)

Amol Katyare wrote:My experience with using EJB Timerservice wasn't good esp. for the reason it seems to be mandatory calling timer.cancel() each time the server is restarted / server crashes. It is absolutely fine for invoking say some batch process at regular interval of time. But as advised in EJB3 in Action, it is ofcourse not a very good option for implementing some real time services which are triggered by timer service. "Quartz" is one of the best appropriate options.

The problem that I faced was, sometimes when server was restarted, I used to get multiple invocation of timeout method successively ignoring what interval I had set. After some analysis, I found the reason. As timer is persisted (I do not know how it is implemented by container), before the code to create timer is actually run, previously persisted instance gets invoked and it disturbs the whole timer cycle. Once fresh timer is started, then it gets regularised. Workaround available is to check if any timer is already running or not then not to create new timer instead use already running one. OR more elegant way is to cancel timer each time you stop server so that regular cycle would be invoked next time you start it up.

My questions

1. Does any one have idea how timer is persisted by container (may be in some DB managed by application sever)?
2. I know we can have control over when to hit first timeout() by specifying milliseconds in first argument. But it might be the case I do not want to invoke timeout() before my server is started completely. But how to have control over the persited instance of the timer and how to refrain it from hitting timeout() unless server is started?

Thanks,
Amol.



EJB Timer Service, is generally not preferred in real time arenas in Business. When there is an option of customized cron job, people hardly opt for EJB timers.

Coming to your question:

1. Does any one have idea how timer is persisted by container (may be in some DB managed by application sever)?

Ans: If you take into consideration Websphere Application Server, the timer is persisted to a Cloudscape database associated with the server process. The default Data Source JNDi Name is jdbc/DefaultEJBTimerDataSource.
Tables used are TASK, TREG, LMGRand LMPR. A string EJBTIMER_ is prepended to these tables. These tables are created during server start if they do not exist. Multiple independent EJB timer services can share the same database if each instance specifies a different prefix string.



2. I know we can have control over when to hit first timeout() by specifying milliseconds in first argument. But it might be the case I do not want to invoke timeout() before my server is started completely. But how to have control over the persited instance of the timer and how to refrain it from hitting timeout() unless server is started?

Ans: You can also set a poll interval which will specify the server (once started) to poll this Cloudscape database and get the timer information and execute the timeouts.



Hi Tejas

I would suggest you to refer the absolute path for the Remote Interface you are looking up in the Context.

You used:
MyBeanRemote myBean = (MyBeanRemote) ic.lookup("MyBeanName");

Actual:
MyBeanRemote myBean = (MyBeanRemote) ic.lookup("@Project/@Package/MyBeanName");

I hope this would help eliminating the communication exception. In addition, make sure the stubs for EJB1.jar is shared across properly in the second machine where EJB2.jar resides.

Best of Luck!!!
12 years ago