Oops, I hadn't finished my sentence:
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 cl1 cl1-1").
This way, when your instance doesn't perform any better when increasing
the number of threads in your thread pools even when your cpu(s) are not
fully utilised, you can simply add another instance to the cluster, no
need to redeploy.
Regards,
Dies
Dies Koper wrote:
> 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 :)