users@glassfish.java.net

Re: Dissapointed

From: Dies Koper <diesk_at_fast.au.fujitsu.com>
Date: Mon, 13 Jul 2009 14:20:07 +1000

Please do let us know if you can reproduce the issue on GFv2.1 + Windows
and GFv2.1.1 (latest build) on Ubuntu.

Adam Jenkins wrote:
> Technically you could run an SSB in your web tier, but that causes
> two problems
>
> 1) Seperation of concerns would be violated...from a design point of
> view that's not great...I mean, if I was going to bleed between
> layers like that I might as well drop EJBs all together and just pull
> directly from the database into objects.
>
> 2) You're not supposed to write to a file from an SSB (good 'ol
> fashioned EJB specification constraints), since it's a distributed
> system.
>
> The closest you could come (and still not violate the spec) is to
> have your EJB call a web service which then generated the includes,
> but that's just a complete cludge and pretty messy. Ultimately, this
> isn't a problem with using a timer, even if I went to something like
> Quartz I'd still have the same problem. This is a problem with
> RMI/IIOP between a web/ejb tier. This same error happens from
> ServletContextListeners, HttpSessionListeners...it's not related to
> the timer at all
>
>
> --- 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, 1:47 PM 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 :)