Hi Adam,
Can't an EJB Timer running in your "web" tier do anything your
java.util.TimerTask can, maybe better because it uses container managed
call-backs?
Regards,
Dies
Adam Jenkins wrote:
> I can't use an EJB Timer for this particular problem as it involves
> generating reports, that then get served from a jsp c:import. So it
> generates a range of reports directly into the web directory. This
> is done because the pages are too big to serve directly (large
> reports)...since it's on the web tier not the ejb tier it has to be a
> timer.
>
>
> --- On Mon, 13/7/09, Dies Koper <diesk_at_fast.au.fujitsu.com> wrote:
>
>> From: Dies Koper <diesk_at_fast.au.fujitsu.com> Subject: Re:
>> Dissapointed To: users_at_glassfish.dev.java.net Received: Monday, 13
>> July, 2009, 10:53 AM Hi Adam,
>>
>>> I have two instances, under the management of one node
>> agent...is
>>> that what you mean by 'clusters', or have you set up
>> something else
>>> that I missed...this might be the problem.
>> When I use GlassFish in cluster mode (i.e. with a node agent), I
>> create a cluster with in it an instance ("asadmin create-cluster
>> cl1" followed by "asadmin create-instance -cluster . I've never
>> used "single" instances that are not assigned to a cluster (except
>> for the DAS server of course). But I suppose that should not
>> matter?
>>
>> Also, I'm still wondering about your use of a java.util.Timer
>> instead of an EJB Timer. If you can somehow rewrite your
>> application to use an EJB Timer instead, you'd be using a pattern
>> that more other users would be using, so less risk of running into
>> new bugs. Can't you deploy a simple SLSB with your web application
>> (so in the "web1" instance) with an EJB Timer callback method that
>> polls the application in your "enterprise1" instance?
>>
>> Regards, Dies
>>
>>
>> Adam Jenkins wrote:
>>> Cheers Dies for looking into this. I'll try
>> reducing the timer to
>>> one minute and see what happens.
>>>
>>> A few things that may assist us in a differential
>> diagnosis.
>>> Linux vs Window - I notice you're on windows, I'm on
>> ubuntu...I'm
>>> going to try this on window tonight and see if the
>> problem persists
>>> JMS Remote vs Local -- I tried Remote today and still
>> got the
>>> problem, so that rules out that.
>>>
>>> I have two instances, under the management of one node
>> agent...is
>>> that what you mean by 'clusters', or have you set up
>> something else
>>> that I missed...this might be the problem.
>>>
>>> I still get the error with a timeout down to 60
>> seconds...so I think
>>> it may be one of the above...hopefully it's something
>> as simple as
>>> needing a new version, or windows v linux.
>>>
>>> Thanks for the feedback, it's opened up new avenues
>> for
>>> investigation, hopefully I can stall for a few more
>> days because I'd
>>> really love to go into production with gf.
>>>
>>> --- On Sun, 12/7/09, Dies Koper <diesk_at_fast.au.fujitsu.com>
>> wrote:
>>>> From: Dies Koper <diesk_at_fast.au.fujitsu.com>
>> Subject: Re:
>>>> Dissapointed To: users_at_glassfish.dev.java.net
>> Received: Sunday, 12
>>>> July, 2009, 4:35 PM Hi Adam,
>>>>
>>>> I have deployed the application to the latest
>> promoted build of GF
>>>> V2.1.1, and I did not see any error messages.
>>>>
>>>> This is my environment: -
>>>> glassfish-installer-v2.1.1-b22-windows.jar -
>> JDK1.5 - JMS broker in
>>>> REMOTE mode - used "localhost" for the host name
>> in the corbaname,
>>>> with the same port you used.
>>>>
>>>> I used two different clusters for the two
>> instances. I commented
>>>> out your injection of the jms/PrepareReports into
>> a java.util.Queue
>>>> to get rid of those unrelated error messages.
>>>>
>>>> I wonder whether our fix for issue 8350 is
>> related. https://glassfish.dev.java.net/issues/show_bug.cgi?id=8350
>>
>>>> I hope this information helps you and others
>> pinpoint what could be
>>>> causing the problems you've seen.
>>>>
>>>> I also reduced your timer period to a 1 minute
>> interval, and see no
>>>> IIOP timeouts even after 20 calls. I did see the
>> following IIOP
>>>> warning about a minute before the EJB invocations
>> started:
>>>>
>> [#|2009-07-12T15:59:52.218+1000|WARNING|sun-appserver2.1|javax.enterprise.resource.corba.ee.S1AS-ORB.rpc.transport|_ThreadID=19;_ThreadName=p:
>>
>>>> thread-pool-1; w:
>> 3;6000;7280;;_RequestID=8940ea7e-e092-4d6d-8611-bea52f07358c;|"IOP00410229:
>>
>>>> (COMM_FAILURE) Blocking read failed,
>> expected to read additional
>>>> bytes: max wait time = 6,000ms total time
>> spent waiting = 7,280ms"
>>>>
>> org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 229
>>>> completed: No at
>> com.sun.corba.ee.impl.logging.ORBUtilSystemException.blockingReadTimeout(ORBUtilSystemException.java:3569)
>>
>>>> at
>> com.sun.corba.ee.impl.logging.ORBUtilSystemException.blockingReadTimeout(ORBUtilSystemException.java:3593)
>>
>>>> at
>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.blockingRead(SocketOrChannelConnectionImpl.java:1863)
>>
>>>> at
>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doOptimizedReadStrategy(SocketOrChannelConnectionImpl.java:1733)
>>
>>>> at
>> com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1263)
>>
>>>> at
>> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
>>
>>>> |#]
>>>>
>>>> Regards, Dies
>>>>
>>>>
>>>> Adam Jenkins wrote:
>>>>> The issues are
>>>>>
>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=8589
>>>> and https://glassfish.dev.java.net/issues/show_bug.cgi?id=8590
>>>>> The first one has a netbeans project attached
>> that
>>>> reproduces things.
>>>>> Unfortunately I'm not able to point you at the
>> source
>>>> (glassfish
>>>>> source) as I don't know. It's the
>> weekend here
>>>> at the moment, and I
>>>>> don't have to start moving to JBoss until next
>> week so
>>>> I'm going to
>>>>> have an attempt at checking out the glassfish
>> source
>>>> today and hoping
>>>>> for a miracle :)
>>